Migrating Accounts Without Using SID History

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

If you are not using SID history for resource access because SID filter quarantining is in place between your forests, your migration process involves first migrating all user accounts, but not enabling 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, then the user account. Finally, you must remigrate the global groups to apply any changes 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 filter quarantining is in place between the source and target forests. Before migrating 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:

1. Migrate all users, and use the Fix users’ group membership option to have ADMT identify global groups in the target domain that the user belonged to in the source domain and 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.

2. Translate security in add mode for files, shares, printers, local groups, and domain local groups.

3. Translate local user profiles for a batch of users.

4. Migrate workstations in batches that correspond to the user account batches.

5. Before migrating 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.

6. Remigrate user accounts in small batches with the accounts in the source domain set to expire in seven days, the target accounts enabled, password migration selected, and all attributes selected for migration.

7. After each batch, you might want to remigrate all global groups to update any group membership changes.

8. After all users are migrated, run a final global group migration to update any group membership changes

9. Translate security in remove mode for files, shared folders, printers, local groups, and domain local groups.

10. 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.

Figure 11.10 shows the steps involved in migrating accounts that are not using SID history for resources access.

Figure 11.10   Migrating Accounts Without Using SID History