User Account Migration
I'll step you through using the User Account Migration Wizard, which migrates user accounts. (Migrating passwords is a separate activity.) After you start the User Account Migration Wizard, you see a title screen. The next screen offers the option of running the User Account Migration Wizard in test mode. This option, which none of the other wizards offer, lets you configure all the settings associated with migrating your users, test the migration, and see a report that shows any potential problems. I recommend that you run the wizard in test mode so that you can iron out any problems with the user-account migration first, then perform the password-migration configuration steps (which I describe in the next section), then run the User Account Migration Wizard again to migrate both user accounts and passwords.
Next, the User Account Migration Wizard asks you to provide the source and target domains. Note that the wizard looks only for AD domains and doesn't include the NT 4.0 domain with which we established a trust in the drop-down box of available domains. You must type in the NT 4.0 domain name.
The next screen lets you select user accounts. Clicking Add on this screen opens a rather limited dialog box for selecting AD objects. If you don't want to type in each user name, click Advanced to see an expanded Select Users dialog box, which Figure 2 shows. Click Find Now to list all the accounts in the target domain. Unfortunately, you can't filter out built-in accounts such as Administrator and Guest, so you need to either avoid selecting these accounts or remove them from the list when you return to the wizard.
After you've selected the accounts to migrate, the next step is to verify the location in the target domain in which you want to create those accounts. The wizard displays the FQDN of the location, and you can edit the target organizational unit (OU) for the accounts.
After you've specified the location, the next screen, which Figure 3 shows, lets you specify how to handle user account passwords. The default option, Complex passwords, creates new, complex passwords based on a random character sequence. Alternatively, you can choose to create passwords that are the same as the account names. With either of these options, the wizard creates a history file that associates each user account with its new password, and you should ask users to change their passwords after they log on to the domain. The third alternative is to migrate user-account passwords from the source domain, although until you've performed the steps described in the next section of this article, the Migrate passwords option isn't truly available. If you select it and click Next, you'll see error messages. For now, accept the default setting and move to the next wizard screen.
The next screen presents account activation options, as Figure 4 shows. I recommend selecting the Target same as source option so that ADMT will create accounts in the target domain with the same activation status as they have in the source domain. This setting gives you some assurance that even if you accidentally migrate an unwanted and deactivated account, the account will remain deactivated. You can also choose to have ADMT automatically flag the source accounts for deactivation. This screen also gives you the option of migrating user-account SIDs. By default, when ADMT creates a user account in the target domain, AD assigns the new account a new SID and disconnects from the new account the user's privileges and limitations as defined in the source domain. Selecting the Migrate user SIDs to target domain option copies a source account's SID into a history associated with the new account. Windows then uses this historical value to tie the new account to the old account and let the user maintain the same privileges and limitations that he or she had in the source domain. Selecting this option also triggers certain audit requirements, which the wizard automatically enables on the source and target domains. Obviously, migrating SIDs makes sense if you want privileges in the target domain for the same groups that are defined in the source domain.
Choosing to migrate SIDs introduces an additional step in the process, in which the wizard asks you to provide valid administrator credentials for the source domain (IKDOM01). ADMT needs explicit credentials because accessing account SIDs is a privileged operation.
The next User Account Migration Wizard screen, which Figure 5 shows, lets you define other user options, including two important group-related options. Select the first option—Migrate associated user groups—to migrate, along with user accounts, custom groups defined in the source domain that you haven't defined in the target domain. You should also select the accompanying suboption—Update previously migrated objects—to let ADMT know that after it creates a custom group for the first migrated user that's a member of the group, it should update that group rather than create a new group when it migrates subsequent users in that group. ADMT will automatically maintain users' memberships in the custom groups; if you're also migrating SIDs, all permissions will remain unchanged.
The second group-related option is Fix users' group memberships, which assigns user accounts to the appropriate existing groups in the target domain based on their source domain membership. (Thus, fix in this case means to attach rather than to repair.) For example, if a user account belongs to the Domain Administrators group in IKDOM01, the new account will have membership in the Domain Administrators group in IKDOM2 after the migration. ADMT is smart enough to not create duplicates of such built-in groups (when migrating groups) and gives you the option of deciding whether such assignments should be automatically transferred.
The final screen asks you to define a default option for renaming any user accounts that duplicate existing accounts in the target domain. After you do so, click Finish to begin the migration or test migration process. During migration, a status window shows what the wizard has migrated and any errors that have occurred. The wizard also generates a log file that you can review at the end of the migration. This log file is available only until you close the wizard display. After you close the display, you'll have access only to ADMT-generated reports.
Prev. page
1
2
[3]
4
next page 
