Migrating Accounts While Using SID History
Applies To: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2
Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)
To migrate accounts while using the security identifier (SID) history, first migrate all the user accounts—but do not enable them in the target domain—to prepopulate the target domain and allow migration of user profiles. After all the user accounts are successfully migrated, begin migrating users in batches by migrating first the user profile, then the workstation, and then the user account. Before you migrate all user accounts, ensure that you have created test accounts that you can include in each batch to verify the success of the migration for that batch.
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 the Active Directory Migration Tool (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 Server or later, 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 that are associated with EFS, Secure/Multipurpose Internet Mail Extensions (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. Use your test migration account to identify any properties that did not migrate, and update user configurations in the target domain accordingly.
Complete the following steps to migrate user accounts to the target domain:
Migrate standalone managed service accounts. Standalone managed service accounts must be migrated before computers. Group managed service accounts cannot be migrated.
Migrate all the user accounts with the account enabled in the source domain, disabled in the target domain, with complex password selected, and with no attributes migrated.
Translate local user profiles for a batch of users.
Migrate workstations in batches that correspond to the user account batches.
Before you migrate the batch of user accounts, verify that local profile and workstation migration succeeded for all users in the batch. Do not migrate any user account for which profile or workstation migration failed. This will result in users overwriting their existing profiles when they log on to the target domain.
Remigrate user accounts in batches with the account set to expire in the source domain in seven days, the target account enabled, with password migration selected, and all attributes migrated.
After each batch, remigrate all global groups to update any group membership changes.
Notify users in the batch to log on to the target domain.
After all users are migrated, run a final global group migration to update any group membership changes.
Migrating user accounts in batches helps you to track the accounts that have been migrated and to test the success of each migration step. If the organizational unit (OU) structure for the target domain is the same as the OU structure for the source domain, migrate groups of users based on OU. If the OU structures are not the same, select an alternative way to group users based on the structure of your organization. For example, you might migrate users by business unit or by floor to enable you to consolidate help desk resources.
If you plan to retain your source domain OU structure, migrate the OUs along with the users that they contain. For example, if your source domain has a functional OU structure, and the target domain does not have an OU structure, migrate OUs from the source domain.
If you created a new OU structure in the target domain, migrate batches of users without the OUs. For example, if your source environment was a Windows NT 4.0 domain that you upgraded to a Windows Server 2003 domain, the source domain might not have an existing OU structure; therefore, you can migrate users without migrating OUs.
For more information about creating an OU structure, see Designing Organizational Units for Delegation of Administration (https://go.microsoft.com/fwlink/?LinkId=76628).
Until you migrate all user and group accounts, continue to administer global group membership in the source domain. To support a rollback strategy, manually synchronize any changes that you make to users in the target domain with the existing user accounts in the source domain. For more information about administering users and groups during the interforest restructure process, see Managing Users, Groups, and User Profiles, earlier in this guide.
If you are migrating OUs when you migrate user accounts, migrate the groups that belong to those OUs to the target domain OU during the user account migration process. When you migrate global groups by using the global group migration process, they are placed in the target OU in the target domain. If you migrate OUs from the source to the target domain, select the option to move the global groups to the target domain at the same time. This way, the groups are moved from the target OU that they were placed in during the initial global group migration to the OU in which they belong.
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 accounts belong to, and then determines whether the global groups have been migrated. If ADMT identifies global groups in the target domain that the migrated users belonged to in the source domain, the tool adds the users to the appropriate global 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. After they log on, the users are prompted to change the password.
If the user account migration process is successful but the password migration process fails, ADMT creates a new complex password for the user account in the target domain. By default, ADMT stores new complex passwords in the C:\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), 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.
The following illustration shows the steps involved in migrating accounts if you are using SID history for resource access.
.gif)