Profile translation takes a long time. Translating roaming profiles can consume a significant proportion of the time a tool takes to perform a migration. Measure profile-translation time beforehand and take into account that some live migrations will occur across low-bandwidth WAN links that might further slow the process. Profile translation might be the determining factor in how many accounts you can migrate per session.
Profiles might become corrupted when users download them. When users log on with their new accounts, their locally cached profiles will no longer be appropriate (or accessible) for them. Each user will need to download a copy of his or her newly translated profile from the server. The download will take time and bandwidth, and in some cases, the new profile will become corrupted. Some users with large profiles won't have enough disk capacity on their workstation to hold their new profiles; the largest profile we've come across was in excess of 1.5GB. Have a tried and tested procedure ready to help your support staff deal with these problems.
Profiles must be current when you translate them. The migration tools translate the roaming copy of a user's profile, so you should ensure that roaming profiles are up-to-date before migration. Updating remote users' profiles is especially important because these users typically use cached profiles to log on.
Tricks of the Trade
Here are some tips that can make your life easier during a migration. We also include some scripts that might help automate parts of your migration process.
Decrease the amount of profile space required during migration. If you have a good backup of the user roaming profiles that you need to migrate, you can extract the bulky parts of the profiles before translation and reinsert them afterward to save migration time and disk space. Listing 1 and Listing 2 show sample DOS code that performs the extraction. You run the script in Listing 1 from a workstation just before migration. The script submits one near-future task for each user in a text-file list to the NT Task Scheduler on the server that holds the user's profile. This automated task copies some common file types from the user's profile to a temporary location. The code in Listing 2 specifies the file types to copy. After migration, you need to use a reverse procedure to copy the users' displaced files to the new profiles; the files would then inherit permissions from the newly translated profiles' top-level folder.
Disable user accounts during migration. You can reverse most user-account migrations that you perform with third-party migration tools simply by reenabling the user accounts in the source domain. Disabling user accounts on the source domain before migration (and reenabling them only if you need to back out of a migration) is a good idea. Disabling user accounts on the target domain until you've completed the migration is an even better idea. If the accounts are disabled, overzealous users can't try to log on before you've completed your crucial work.
Add a new Start menu item for migrated users. You might want to add a program to each migrated user's roaming profile Start folder—maybe a self-deleting batch file that performs some post-migration cleanup task or a dialog box with post-migration instructions for the user. The script in Listing 3 copies a new Start item into the roaming profiles of users listed in a text file. We haven't provided a Start item here; an example might be a script that prompts the user to update his or her contact information in the corporate telephone directory or a script that sends an email message that notifies the project Help desk that the user has just made his or her first post-migration logon.
Preserve your SAMs during migration. In case something goes horribly wrong, preserve each domain's SAM database throughout the migration process. We recommend that you take one of a domain's BDCs offline before you use your migration tool on that domain, and don't bring the BDC back online until a couple of days after migration. In case of disaster, you can promote the offline BDC to a PDC and use it to restore the domain to its predisaster state.
Send an email message to each user slated for migration. If you have a text file that contains a list of users to be migrated, you can use one of the command-line email programs available as freeware to send your users advance warnings or post-migration instructions. You might have to manipulate the user-list text file to associate the NT usernames with the correct email addresses first (again, Excel's VLOOKUP function might come in handy).
DC Migrations
Migrating a DC is more of a rebuild than a migration. For security reasons, you can't move DCs from one domain to another the same way that you can move a member server or workstation. (People might tell you otherwise, but moving a DC requires some messy registry work that we don't recommend and that Microsoft certainly doesn't support.) Keep in mind that you must leave the source domain's PDC running until you're ready to retire the domain, so you might need to move the PDC function to a different or new server.
Before you perform the rebuild, lift from the server the important data and parameters that you need. Afterward, you can replace what you removed. Some items that you might want to remove and replace are
- user data and profiles
- print queues
- applications and Microsoft BackOffice products (e.g., SMS sites)
- networking settings (e.g., IP addresses)
- DHCP and WINS details (the Microsoft articles "How to Move a DHCP Database to Another Windows Server" at http://support.microsoft.com/support/default.aspx?scid=kb;en-us;q130642, "Recovering a WINS Database from Other Backup Sources" at http://support.microsoft.com/default.aspx;scid=kb;en-us;q235609, and "Restore of WINS Database to a Different Server Fails" at http://support.microsoft.com/default.aspx?scid=kb;en-us;q170849 detail the procedures for saving and then restoring DHCP and WINS databases)
Prev. page
1
2
3
[4]
5
next page 
