Establishing Migration Accounts for Your Migration

Updated: September 29, 2013

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 and resources between forests, you must establish migration accounts and assign the appropriate credentials to those accounts. The Active Directory Migration Tool (ADMT) uses the migration accounts to migrate the objects that you identify. Because ADMT requires only a limited set of credentials, creating separate migration accounts helps you to simplify administration. If the migration tasks for your organization are distributed across more than one group, it is helpful to create a migration account for each group involved in performing the migration.

To simplify administration, create a single account in the source domain and a single account in the target domain for all objects, with the required credentials to modify the objects, such as users, managed service accounts, global groups, and local profiles, to be migrated by that account. For example, a migration account that you use to migrate user accounts along with the security identifier (SID) history, global groups along with SID history, computers, and user profiles has local administrator or domain administrator credentials in the source domain. The migration account also has delegated permission on the user, managed service account, group, and computer organizational units (OUs) in the target domain, with the extended right to migrate SID history on the user OU. The user must be a local administrator on the computer in the target domain on which ADMT is installed. A migration account that you use to migrate workstations and domain controllers must have local administrator or source domain administrator credentials on the workstations or the account must have source domain administrator credentials on the domain controller, or both.

In the target domain, it is necessary to use an account that has delegated permissions on the computer OU and the user OU. You might want to use a separate account for the migration of workstations if this migration process is delegated to administrators that are in the same location as the workstations.

The following table lists the credentials that are required in the source and target domains for different migration objects.

 

Migration object Credentials necessary in source domain Credentials necessary in target domain

User/managed service account/group without SID history

Delegated Read all user information permission on the user OU or group OU and domain administrator credential

Delegated Create, delete, and manage user accounts, Create, delete, and manage groups, and Modify the membership of a group for the user OU or the group OU and local administrator on the computer where ADMT is installed.

User/managed service account/group with SID history

Delegated Read all user information permission on the user OU or group OU and domain administrator credential

Delegated permission on the user OU or the group OU, extended permission to migrate SID history, and local administrator on the computer on which ADMT is installed.

Computer

Domain administrator or administrator in the source domain and on each computer

Delegated permission on the computer OU and local administrator on the computer on which ADMT is installed.

noteNote
If the computer has a managed service account installed, you need to supply credentials that have permission to update the security descriptor of the managed service account in the target domain.

Profile

Local administrator or domain administrator

Delegated permission on the user OU and local administrator on the computer on which ADMT is installed.

noteNote
You might need to complete additional preparation steps if you migrate roaming profiles for computers that run Windows Vista or later. For more information, see Preparing for migration of roaming profiles with computers that run Windows Vista and later versions of Windows.

The following procedures provide examples for creating groups or accounts to migrate accounts and resources. Procedures differ according to whether a one-way trust or a two-way trust exists The procedure for creating migration groups when a one-way trust exists is more complex than the procedure for when a two-way trust exists. This is because, with a one-way trust, you must add the migration group to the local Administrators group on local workstations.

The sample procedure for creating migration groups when a one-way trust exists involves creating separate groups for migrating accounts and resources. However, you can combine acct_migrators and res_migrators into one group, if you do not need to separate them to delegate different sets of permissions.

  1. In the target domain, create a global group called acct_migrators.

  2. In the target domain, add the acct_migrators group to the Domain Admins group, or delegate administration of OUs that are targets for account migration to this group.

  3. If you are migrating SID history, and you did not place the acct_migrators group in the Domain Admins group, grant the acct_migrators group the Migrate SID History extended permission on the target domain object. To do this, follow these steps:

    1. Start Active Directory Users and Computers, right-click the domain object, and then click Properties.

    2. Click the Security tab, click Add, and then select acct_migrators.

      If the Security tab does not appear, in Active Directory Users and Computers, click View, and then click Advanced Features.

    3. In Permissions for acct_migrators, click Allow for the Migrate SID History permission.

  4. In the source domain, add the acct_migrators group to the Builtin\Administrators group.

  5. On each computer on which you plan to translate local profiles, add the acct_migrators group to the local Administrators group.

  1. In the target domain, create a global group called res_migrators.

  2. In the target domain, add the res_migrators group to the Domain Admins group, or delegate administration of OUs that are targets for resource migration to this group.

  3. In the source domain, add the res_migrators group to the Administrators group.

  4. On each computer that you plan to migrate or on which you plan to perform security translation, add the res_migrators group to the local Administrators group.

  1. In the source domain, create an account called res_migrator.

  2. In the source domain, add the res_migrator account to the Domain Admins group. (The Domain Admins group is a member of the local Administrators group on every computer in the domain by default. Therefore, you do not have to add it to the local Administrators group on every computer.)

  3. In the target domain, delegate permissions on OUs that are targets for resource migration to the res_migrator account.

ADMT also includes database administration roles that you can use to assign a subset of database permissions to users who perform specific migration tasks. The database administration roles and the migration tasks that they can perform are listed in the following table.

 

Role Migration task

Account migrators

Account migrations tasks, such as user and group migration.

Resource migrators

Resource migration tasks, such as computer migrations and security translation. Account migrators also hold the role of resource migrators.

Data readers

Queries against that database. Account migrators and resource migrators also hold the role of data readers.

Users who are assigned the role of SQL Server sysadmin hold all ADMT database administration roles. They have the credentials to do the following:

  • Display database roles and users who hold those roles

  • Add groups or users to roles

  • Remove groups or users from roles

By default, the local Administrators group is assigned the role of sysadmin and can perform all ADMT database functions.

Community Additions

ADD
Show: