Before you begin any of the phases, document your migration process in its entirety and run through it in the lab multiple times, each time improving your documentation and your process. Restore backups of the actual servers you're going to migrate into your lab environment, which you should set up to resemble your live environment as closely as possible. If you don't have a lab environment, build one. Rehearse to the point of actually walking into the live server rooms; many projects have come apart because the key to a crucial rack isn't available at the right time. Preparation time will reward you tenfold by producing fewer unpleasant surprises during the actual migration.
In addition to practicing for migration, you need to prepare users for it. As we said at the beginning of this article, merging domains disrupts users without providing much visible benefit. Thus, you need to explain the reasons behind the change—sell the project. Use any communication channels that you have at your disposal, and we don't just mean global email messages. Write an article for your corporate magazine. If the project is large enough, give it a brand, a name, an intranet site, or even a logo. Users will be much more accommodating if they know what's going on.
User Account Migrations
If you have a large number of user accounts to migrate from one domain to another, you probably won't be able to migrate them all in one session. The processing rate of the tool that you use to migrate accounts and the length of your downtime slot will determine the number of accounts you can migrate in one pass. If you can't migrate all the accounts at once, you might decide to migrate accounts based on the server on which their personal files are stored rather than on their workgroup. Such a plan will mean that for the duration of the migration, people from the same work team might be in different domains. This situation shouldn't be a problem from a shared-resource perspective if you're using a migration tool that can repermission the objects in the donor domain, but it's an absolute headache for administrators. Therefore, keeping the migration period as short as possible is a good idea.
The Right Tool for the Job
Anyone performing a migration of any real size should consider obtaining one of the good third-party tools on the market. When considering tools, create another evaluation matrix that lets you specify your migration's requirements and evaluate how the products meet the requirements. Some important features are
- The ability to examine and modify every embedded SID reference (including NTFS and registry references) for as many applications as possible (e.g., Microsoft Exchange Server, Microsoft SQL Server). We refer to this feature as "re-ACLing."
- The ability to maintain existing SID references until the migration is complete. The tool shouldn't delete the original SIDs right away; rather, it should add the new-account SID with the same permissions wherever it finds the original SID. This approach lets you back out of a migration stage that fails without having to restore.
- The ability to migrate account passwords from one domain to another.
- The ability to examine the SIDs of thousands or millions of objects on your LAN or WAN in a short time. Thus, an agent-based tool is a must.
- The ability to translate roaming user profiles and locally cached profiles for use by the migrated accounts. Again, because this task is a demanding one, it should be agent-based.
Some of the tools you might want to consider are from Aelita Software, BindView, NetIQ, and Quest Software (formerly FastLane Technologies). See Ed Roth, "NT-to-Win2K Migration Tools," September 2000, InstantDoc ID 9659, for reviews of these vendors' tools.
Vendors will sometimes rent you migration tools on a month-by-month basis or allow free temporary use of the tools if you engage consultants from a partner company. If you don't think you'll need the tool's facilities after your migration, you might look into these options.
Pay Attention to Your Users' Profiles
In our experience, the most disruptive aspect of account migration for users is trouble with their NT profiles. Migration tools typically copy a user's existing roaming profile to a folder with a different name, then perform a re-ACLing pass against each file, folder, and registry entry in the new copy. The tools then configure the newly created account for the user to use the new profile. This method is a good one because it leaves the original account with access to the original, untranslated profile, but the new profiles have the following disadvantages.
The profiles consume a lot of server storage. This migration approach consumes an amount of space on each profile-holding server equal to the amount already dedicated to storing roaming profiles. You must ensure that each affected server has enough free space before the migration commences.
Prev. page
1
2
[3]
4
5
next page 
