First, my apologies for not writing sooner. We have been absolutely slammed for the last several months. One of the most interesting projects
we've been working on has to do with changing Domino Domains for a major international client.
Bear with me for a moment, this is actually more interesting than it sounds. Honest.
Here's a quick synopsis of the situation: This client started out as a single billion-or-so-dollar company. Its Notes Domain, for the sake of this discussion, was Acme. All the users were certified with /Acme but also with two other OUs...one for their location, one for their country (yes, I know you can have a Country component your Notes name but this client did it as an OU).
So, people were named names like Scott Good/Columbus/US/Acme.
Over the last several years, this company has been on a merger and acquisition binge and has now pulled together 8 or 10 companies into a new company which is no longer called Acme. They have added servers and people and locations. And a new Organizational certifier, too, /Global, which has been used for all the new people.
But not for the original Acme people, nor for any of the servers.
So, now there are 8,000 or so users, of which 2,400 are /Acme and 5,600 are /Global. There are 70+ servers which area all /Acme. And, there are two sets of OUs for each location, depending on Certifier; there's /Columbus/US for /Acme, and there's /COL/US for /Global. Oh, and just to keep things interesting, there are more than two thousand custom Notes applications out there floating around the organization.
The continued existence of /Acme and of e-mail addresses for key executives ending in @acme.com has become a point of embarrassment for the folks at the top, so we were brought in to convert all the people and all the servers to the new /Global domain.
Really, when you say it like that it really doesn't sound all that difficult. But the devil is in the details and what we've found is the simple directive, "move everybody to the new Domain," is an awful lot more complicated than you might think.
I'm writing this story to give you a sense of the kinds of things you'll need to consider if you happen to be heading down this particular road.
At first, it sounds easy. You say to yourself, "no problem; I'll just use AdminP and rename the user. Piece of cake." Well, kinda. Which is a nice way of saying, um, not exactly.
AdminP is good for a lot of things, but it has a number of problems when trying to do a project like this. Among them:
- To minimize Admin4 problems, it is best to avoid changing the server names until after the user renames have been completed. Our plan called for doing the servers first and then the clients. This approach prevents individual-client issues from delaying the server renaming. Using AdminP, these processes--renaming users and renaming servers--are consecutive, not parallel, tasks; one has to be fully completed before the next can begin.
- With no common trusted root between the old certificate and the new, the client will be prompted to create a local cross-certificate from any workstations they log into. That cross-certificate will be stored in their Personal Address Book as /Acme. Once the user is moved to the newly-named servers they won't need the cross certificates (but they will still be in the local directories unless you send out code to delete them). While our approach will also create the /Acme cross-certificate, by doing the server changes first our user ID update code can remove the /Acme cross-certificate minutes after it is created by the user accessing the new server for the first time.
- With AdminP, there is no direct and easy means of monitoring which users have and which haven't completed the update process except accessing the Admin4 database on each server and seeing what's in the log. If any user does not complete his/her update after 21 days (or however many days you choose) or if the client doesn't log-in within the specified time, then the rename has to be monitored in Admin4 and reinitiated. If the user doesn't accept the name change for 21 days, or doesn't log in or has set their local client not to automatically accept rename updates, and the server is prior to 6.0.5/6.5.4 the name change will revert back at that time.
- The effectiveness of the entire process is dependent to a great degree on AdminP on each server and more significantly the client version and client configuration. There are issues with the update completing in the early client versions up to about 6.5.4.
- For AdminP to work properly, the AdminP process and settings in every mail file and application database have to be configured correctly and working perfectly. Client settings need to be set correctly to accept renames automatically; application databases must all have Administration Servers defined (and, of course, they need to be pointed to servers that are running AdminP). Any databases missing an Administration Server definition will be ignored by AdminP, meaning none of their documents' Authors, Readers, or Names fields will be updated.
- Any documents in users' Personal Address Books that are locked "for user"--Locations, for example--will not be updated and will no longer work unless they are manually updated by the user. AdminP will not solve issues with updating the client desktop...bookmarks, connections and locations. One of the benefits of AdminP is we would save time on the ID roll-out / update process. That time savings, however, is offset by a need to budget more on the support side. Our assumption from the beginning is this project needed to be done with no use of internal resources, including the Help Desk, and that time was of the essence.
Then there are the issues with the applications. AdminP updates Author, Reader and Names-type fields, along with ACLs and Address Book entries. But it doesn't look at other kinds of fields. Many applications, including our workflow tool, ProcessIt, use Text fields to contain critical user and/or workflow information. AdminP won't touch these and, as a result, the applications will fail.
Further complicating matters, not only are servers being renamed but also database paths are being changed. Many of the applications used throughout the old company were in folders cascaded beneath a top-level AcmeCorp folder. In the effort to get "Acme" out of everything, these applications are being moved to new places. And, of course, it would be too simple to just move them all to the same new place--so you could just write a little code to fix all the links--they are being moved to a variety of new places.
And, it just keeps going. There are mission-critical Notes applications going through an extensive and formal remediation process to make sure they don't break after all the people and servers and database paths are changed.
There is encrypted mail to deal with. Actually, it's not the encrypted mail so much as the attachments inside encrypted messages. They have to be decrypted and detached with the user's old ID and then reattached and re-encrypted with the new ID.
And, there are resources and reservations and free time and Quickr, Sametime and BlackBerry servers to deal with. And workspace icons, which will all be pointing to servers (and paths) which no longer exist.
It all sounds so simple: Let's consolidate the Organizations and Domains for our Notes users. As it turns out, this is very do-able but it's not for the timid. If you or your clients are considering such a change, you might want to give us a call. There are a lot of things to consider and, frankly, a lot of things that can go wrong if you haven't been extraordinarily thorough in your planning and project management.
Anyway, that's why you haven't heard a lot from me lately.
1. Raoul Phillips03/21/2008 12:20:18 PM
Scott,
Hi. I assume you got through the /ACME merge in good shape. My name is Raoul and I am faced with pretty much the same situation as you were with /ACME, needing to do a merger and recertification for 4000 users in a 6.5 environment. Do you know where I could possibly obtain a domain merge and user recertification plan that I could use to model for what I need to do? I have seen a couple of IBM documents that are out there but we were talking about the need to send out encrypted e-mail to users to verify existing certificates, verifying/setting administrative servers in application databases and converting person docs for sytems usage to mail-in databases etc.
Any help would be greatly appreciated.
Really like your SMRT racing team. Haven't been to Mid-Ohio but have been to Road America many many times to see what was the Champ Car series.
Regards,
Raoul
2. Scott Good03/25/2008 08:40:26 AM
Homepage: http://www.scottgood.com
Hi Raoul,
Thanks for your note. Give me a call (614-457-7100 x200) and let's talk about how we might be able to work together on your project.
Thanks,
Scott




















