Active Directory Migration

The source server "WIN2K8R2" is a domain controller of the "DomainA.Com" domain. The target server "WIN2K19" is a domain controller of the "DomainB.Com. The two domains are in two different forests. CopyRight2 and the Password Synchronization Add-on, are installed on the target system, to pull the accounts from the source. There is no trust defined between the two domains.

There are 3 OUs called "IT", "Marketing" and "Sales" in the source Active Directory. Those three OUs and any users (including passwords), groups, contacts, distribution lists and OUs they contain, shall get migrated into 3 OUs having the same name, located in the "Sys-Manage" OU located directly below the root of the target Active Directory.

If newer Windows versions were used, or if running it on the source or a 3rd computer, the same settings could be used.

Job Type
User and Group Migration

Name and Description Page
Name: Domain Migration

Source and Destination Page
Source computer: WIN2K8R2
Destination computer: WIN2K19

User and Group Migration Page
Specific accounts: The OUs of the "IT", "Marketing" and "Sales" Departments, including any users, groups, contacts and distribution lists contained.

Filter Page
User accounts: Enabled (Add/Update)
Local groups: Enabled (Add/Update)
Global groups: Enabled (Add/Update)
Contacts: Enabled (Add/Update)

Settings Page
Migrate user passwords: Enabled
Local group memberships: Enabled (Add/Remove)
Global group memberships: Enabled (Add/Remove)
Local group members: Enabled (Add/Remove)
Global group members: Enabled (Add/Remove)
Do not migrate any accounts indirectly that are not selected: Enabled

Active Directory Options Page
Migrate OU & container structure: LDAP://OU=Sys-Manage,DC=DOMAINE,DC=COM
Local group memberships: Enabled (Add/Remove)
Global group memberships: Enabled (Add/Remove)

Scripting Page
The same script is used for "Transform users" and "Transform contacts":

if InStr(Source("mail"), "@ext.sys-manage.com") then
 Destination("mail")=Replace(Source("mail"),"@ext.sys-manage.com","@ext.target.com")
end if
if InStr(Source("mail"), "@sys-manage.com") then
 Destination("mail")=Replace(Source("mail"),"@sys-manage.com","@target.com")
end if

CopyRight2 fully supports sidHistory style migrations, where the target accounts (users or groups) get additional old SIDs added to grant access to resources referencing those SIDs the accounts had in the source domain. Using the sidHistory feature allows you to separate the account from the resource migration at the expense of higher complexity. After the user and group accounts have been migrated, you would have to perform a sidHistory cleanup, replacing the old SIDs the accounts had in the source domain, with the SIDs the accounts got in the target domain. Once all SIDs have been replaced, usually in NTFS and share level permissions, the sidHistory Active Directory field can be cleared and the migration is completed. There are several requirements to meet if you want to perform a sidHistory migration. Please check the CopyRight2 user's manual for more information on those requirements.

This example does not make use of sidHistory, to simplify the process. You can either run a subsequent data migration, automatically replacing the SIDs on-the-fly while the data and permissions are copied to the target, or in case the data should not get moved, you can use a "Security & Attributes" type of job to perform a search & replace operation for the accounts. This method has no additional requirements and much less complexity than a migration using sidHistory.

This example shows an interforest migration. CopyRight2 supports intraforest (source and target domain in the same forest) migrations as well, with and without making use of sidHistory. If sidHistory should be used in the intraforest scenario, the accounts get moved between the two domains and not copied. After the account was moved, it automatically gets the SID of the original source account added to its sidHistory field allowing access to the resource originally accessible. In case of an intraforest migration, it is not possible to copy the account while retaining its original SID in sidHistory, because the SID has to be unique within the forest.