Active Directory to UCS Migration

The source server "WIN2K19" is a domain controller of the "DomainE.Com" domain. The target system "UCS-6999" is a domain controller of the "Acme.Com. The two domains are in two different forests. CopyRight2 was previously installed on the source system, to push the accounts to the target. There is no trust defined between the two domains.

There are 3 OUs called "Support", "Marketing" and "Sales" in the source Active Directory. Those three OUs and any users, groups, contacts, distribution lists and OUs they contain, shall get migrated into 3 OUs having the same names, located directly below the root of the target Active Directory.

If the source domain was running on a different Windows versions the same settings could be used.

Job Type
User and Group Migration

Name and Description Page
Name: Active Directory Migration

Source and Destination Page
Source computer: WIN2K19
Destination computer: UCS-6999

User and Group Migration Page
Specific accounts: The OUs of the "Support", "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: Disabled
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://DC=Acme,DC=Com
Local group memberships: Enabled (Add/Remove)
Global group memberships: Enabled (Add/Remove)

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. This case requires sidHistory to be used. In this 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 using the original samAccountName, because the samAccountName has to be unique within the forest.