Sys-Manage Logo
SSL | Register | Login Monday, October 26, 2020 Flag en-US 
Search
 

Active Directory Migration

 

This video shows Sys-Manage CopyRight's Active Directory migration functionality. In this example a Windows® 2008 R2 Active Directory DOMAINA.COM containing users, groups, contacts, distribution lists and OUs is migrated onto a Windows® 2019 domain controller of DOMAINB.COM.

Opposed to Microsoft's ADMT, CopyRight2 does not require a trust between the two domains, neither any agents that have to be installed, nor does it require a SQL server instance. As it supports sidHistory-less migrations, there is no security risks attached to it and none of the requirements of ADMT have to be fullfilled.

For simplicity, in this video, the account used to run the migration has the same password in both domains (a.k.a. pass-through authentication), otherwise the GUI would prompt for authentication.

  Environment  

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.

  Settings  

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 OU's 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
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

  Notes  
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 peform 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, automaticallty 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.
  Video  
  Download  

Copyright © Sys-Manage, 1998-2020. All Rights Reserved.

Privacy Statement
Terms Of Use