Background Information for Restructuring Active Directory Domains Between Forests
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)
The migration process between forests is not considered to be destructive because the migration objects continue to exist in the source domain until the source domain is decommissioned. Because the source and target domain environments exist simultaneously during the migration, you have the option to roll back to the source environment if migration fails for any reason, for example, if a particular object does not migrate or access is not maintained or preserved in the target domain after you perform the migration. You can use the Active Directory Migration Tool (ADMT) to migrate accounts and resources between domains while preserving user and object permissions. During the interforest restructure process, users have continuous access to required resources. Furthermore, you can move users, groups, and resources independently of each other.
The remaining sections in this topic explain the account and resource migration process .
Account migration process
Restructuring accounts between Active Directory forests involves the copying of users, groups, and local profiles from the source domain to the target domain, while preserving the access rights and attributes of those objects.
When user accounts are migrated between Active Directory domains in different forests, the original account remains in place in the source domain and a new account is created in the target domain. Because the security identifier (SID) of a security principal (user or group) always contains an identifier for the domain in which the security principal is located, a new SID is created for the user in the target domain. Because ADMT can migrate the SID of the original security principal to the security principal in the target domain, you do not have to perform additional tasks to ensure resource access unless you are using SID filtering between the forests.
If you are using Group Policy to manage folder redirection or software distribution, ensure that these policies continue to apply when you migrate user accounts to a new forest. Also, if you are using a Group Policy object (GPO) to grant or deny remote access in the source domain and not the target domain, ADMT cannot determine which remote access to assign to the user.
If you are using Group Policy to manage folder redirection, Offline Files does not work after the user account is migrated to a new forest. Offline Files stores the SID of the user as owner; the SID changes when the user account is migrated. To restore ownership of Offline Files, use the ADMT Security Translation Wizard to replace the permissions on the files and folders on the client computer that contains the offline files cache.
To ensure that users continue to have access to Offline Files after you migrate user accounts to the target domain, you can do the following:
Translate security on client computers to update the Offline Files.
If the SID history of the user account was not migrated to the target domain, translate security on the server that hosts redirected folders.
If you are using folder redirection, one of the following occurs:
If the folder redirection path is different in the new environment, users can access the folder if the SID history of the user account was migrated to the target domain. The folder redirection extension copies the files from the original location in the source domain to the new location in the target domain. SID history enables the user account to access the source folders.
If the folder redirection path is the same in the new environment, users cannot access the redirected folder because folder redirection will check ownership of the redirected folder and fail. You must then translate security on the redirected folder on the server.
If you are using Group Policy to manage software installation and the Windows Installer package requires access to the original source for operations such as repair and remove, you must translate security on the software distribution point after you migrate users to ensure that software installation continues to function properly in the target domain.
Resource migration process
Active Directory domains include three types of resources:
Workstation accounts
Member server accounts
Resources on member servers
The migration of workstations and member servers is a straightforward process. The local groups that you create to assign permissions to users are located in the local Security Accounts Manager (SAM) database, and they are moved when you move the server. You do not have to reconfigure access control lists (ACLs) so that users can access resources after the migration.
To migrate domain controllers between domains, remove Active Directory Domain Services (AD DS) from the domain controller, migrate it as a member server to the target domain, and then reinstall AD DS.