Migrating Accounts Without 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)
If you are not using security identifier (SID) history for resource access because SID filtering is in place between your forests, your migration process involves performing the following steps. First, you 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. Then, you run security translation on all resources that the users access across forests. The next step is to migrate users in batches by migrating first the user profile, then the workstation, and then the user account. Finally, you must remigrate the global groups to apply any changes that are made to the global groups in the source domain and translate security in remove mode.
It is still important to migrate SID history although user accounts will not use SID history for resource access. This ensures that operations such as Offline Files continue to function within the forest. Migrating SID history does not present a security risk because SID filtering is in place between the source and target forests. Before you migrate all user accounts, ensure that you have created test accounts that you can use to verify the success of each batch.
Complete the following steps to migrate user accounts to the target domain:
Migrate managed service accounts. Managed service accounts must be migrated before computers.
Migrate all users. Use the Fix users’ group membership option both to have the Active Directory Migration Tool (ADMT) identify global groups in the target domain that the user belonged to in the source domain and to add the user to the appropriate global group in the target domain. For this initial user migration, leave the user account enabled in source domain and disabled in the target domain.
Translate security in add mode for files, shares, printers, local groups, and domain local groups.
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, because this will result in users overwriting their existing profiles when they log onto the target domain.
Remigrate user accounts in small batches with the accounts in the source domain that are set to expire in seven days with the target accounts enabled, password migration selected, and all attributes selected for migration.
After each batch, remigrate all global groups to update any group membership changes.
After all users are migrated, run a final global group migration to update any group membership changes
Translate security in remove mode for files, shared folders, printers, local groups, and domain local groups.
Notify users in the batch to log on to the target domain.
Until you migrate all user and group accounts, continue to administer global group membership in the source domain.
The following illustration shows the steps involved in migrating accounts that are not using SID history for resource access.
.gif)