Migrating User Accounts
Updated: March 28, 2003
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
The ADMT user account migration process includes the following steps:
The administrator selects the source user objects to be migrated.
ADMT reads attributes from the source user objects.
ADMT creates a new user object in the target domain and a new primary SID for the new user account.
If you are migrating SID history, ADMT adds the original SID of the user account to the SID history attribute of the new user account.
ADMT migrates the password for the user account.
You cannot migrate every user property when you migrate user accounts. For example, Protected Storage (Pstore) contents for Windows NT 4.0 workstations, including Encrypting File System (EFS) private keys, are not migrated by ADMT when you migrate user accounts. To migrate Pstore contents, you must export and import keys during the migration process.
For clients that are running Windows 2000 or later operating systems, data that is protected by the Data Protection API (DPAPI) is also not migrated. DPAPI helps protect the following items:
Web page credentials (for example, passwords)
File share credentials
Private keys associated with EFS, S/MIME, and other certificates
Program data that is protected by using the CryptProtectData() function
For this reason, it is important to test user migrations by using your test migration account to identify any properties that did not migrate and update user configurations in the target domain accordingly.
Following the migration, audit events are logged in both the source and the target domains if you are migrating SID history.
Using ADMT to migrate user accounts preserves group memberships. Because global groups can contain only members from the domain in which the group is located, when users are migrated to a new domain, the user accounts in the target domain cannot be members of the global groups in the source domain.
As part of the migration process, ADMT identifies the global groups in the source domain that the user account belongs to, and then determines whether the global groups have been migrated. If ADMT identifies global groups in the target domain that the users belonged to in the source domain, the tool adds the users to the appropriate groups in the target domain.
Using ADMT to migrate user accounts also preserves user passwords. After the user accounts are migrated to and enabled in the target domain, the users can log on to the target domain by using their original passwords. If the user account migration is successful but the password migration process fails, then ADMT creates a new complex password for the user account in the target domain. By default, ADMT stores new complex passwords that are created in the default drive, in Program Files\Active Directory Migration Tool\Logs\Password.txt file.
If you have a Group Policy setting on the target domain that does not allow blank passwords (the Default Domain Policy/Computer Configuration/Security Settings/Account Policies/Password Policy/Minimum password length setting is set to any number other than zero), then password migration will fail for any user who has a blank password. ADMT generates a complex password for that user, and writes an error to the error log.
Establish a method for notifying users who have been assigned new passwords. For example, you can create a script to send an e-mail message to users to notify them of their new passwords.
Because only a hash of a user password exists in the source domain, the password filter cannot verify whether the password meets complexity or length requirements. The target domain controller used to set the password can verify the password history because it compares the hash of the password against previous hashes.
You can migrate user accounts by using the ADMT console, by using the ADMT command-line option, or by using a script.
To migrate the current batch of users by using the ADMT console
On the domain controller in the target domain on which ADMT is installed, log on by using the ADMT account migration account.
Open the Active Directory Migration Tool, and then select User Account Migration Wizard.
Complete the User Account Migration Wizard by using the information provided in Table 10.10.
Table 10.10 Using the User Account Migration Wizard to Migrate User Accounts
Wizard Page Action
Test or Make Changes
Click Migrate Now?
In the Source domain box, type or select the NetBIOS name of the source domain.
In the Target domain box, type or select the NetBIOS or DNS name of the target domain.
In the Select Users dialog box, select the user accounts you want to migrate, and click Add.
Organizational Unit Selection
ADMT lists an OU here. Ensure that this is the correct target OU. If it is not correct, type in the correct OU or click Browse.
In the Browse for Container dialog box, navigate to the target domain and OU, and then click OK.
Select Migrate Passwords.
Account Transition Options
Select Enable target accounts.
Select Days Until Source Account Expires and enter a number of days. A value of 7 is commonly used.
Select the Migrate user SIDs to target domains check box.
Type in the User name, Password, and Domain of a user account that has administrative credentials.
Select the Translate roaming profiles check box.
Select the Update user rights check box.
Clear the Migrate associated user groups check box.
Select the Fix users’ group memberships.
Select the Do not rename accounts check box.
Click Ignore conflicting accounts and don’t migrate.
When the wizard has finished running, click View Log and review the migration log for any errors.
Start Active Directory Users and Computers, and then verify that the user accounts exist in the appropriate OU in the target domain.
To migrate the current batch of users by using the ADMT command-line option
On the domain controller in the target domain on which ADMT installed, log on by using the ADMT account migration account.
To migrate a set of specified users "user_name1" "user_name2," at the command line, type:
ADMT USER /N “user_name1” “user_name2” [parameters]
ADMT USER /N “user_name1” “user_name2” /SD:”source_domain” /TD:”target_domain” /TO:”target_OU” /MSS:YES TRP:YES /UUR:YES
ADMT USER /N “user_name1” “user_name2” /O “option_file.txt”
Table 10.11 Parameters Required for User Migrations
Options Command-Line Syntax Option File Syntax
Target OU location
Do not rename accts
Ignore conflicting accts and do not migrate them
Translate Roaming Profile
Update User Rights
/UUR:YES(/UUR:NO is the default)
Review the results that are displayed on the screen for any errors.
Start Active Directory Users and Computers, and then navigate to the target OU. Verify that the users exist in the target domain OU.
To migrate users by using a script
Prepare a script that incorporates ADMT commands and options for migrating users by using the sample script shown in Listing 10.6.
Listing 10.6 Migrating User Accounts
<Job id=" MigratingUserAccountsNTSource" > <Script language=" VBScript" src=" AdmtConstants.vbs" /> <Script language=" VBScript" > Option Explicit Dim objMigration Dim objUserMigration ' 'Create instance of ADMT migration objects. ' Set objMigration = CreateObject(" ADMT.Migration" ) Set objUserMigration = objMigration.CreateUserMigration ' 'Specify general migration options. ' objMigration.SourceDomain = " source domain" objMigration.TargetDomain = " target domain" objMigration.TargetOu = " target container" objMigration.PasswordOption = admtCopyPassword objMigration.PasswordServer = " password export server name" objMigration.ConflictOptions = admtIgnoreConflicting ' 'Specify user migration specific options. ' objUserMigration.MigrateSIDs = True objUserMigration.TranslateRoamingProfile = True objUserMigration.UpdateUserRights = True objUserMigration.FixGroupMembership = True objUserMigration.MigrateServiceAccounts = False ' 'Migrate specified user objects. ' objUserMigration.Migrate admtData, Array(" user name1" ," user name2" ) Set objUserMigration = Nothing Set objMigration = Nothing </Script> </Job>