The galactic story is going backwards, one prequel at a time…
There are some AD migration scenario’s (I’d rather call them “consolidation”) were, for various reasons, the user accounts already exist in the destination domain. This is typically the case when organizations use to operate a “mail forest”, dedicated to Exchange and used another forest for user to log and then decide they want to merge them, preferably keep the one used for mail because it contains rich address book information but also because Exchange is difficult to move from one domain to another. The “mail forest” only contains disabled user account linked to the user forest.
The ADMT does not provide a way to “reconcile” account and populate SID history of the existing users in destination domain using the original SID of the source domain. Fortunately, the force is with you if you use a scripting COM object part of the Windows 2000 Reskit: DSUtils.ClonePrincipal. This component allows you to script, using WSH or PoSh, the reconciliation of both users in the destination domain, consequently preserving permission set with the SID of the source domain.
In order to be able to use DSUtils.ClonePrincipal, the same requirements as the ones applicable to ADMT with Sid history usage are applicable: Trusts, Forest functional level, Registry modification (NT4)… Here is a short example of how to use it, where “Anakin” is the name of the user in the source domain and “darthvador” is the matching user in the destination domaine. Note that the actual domain names are specified in the line starting with “objClonePr.Connect” and must not be supplied in the line starting with “objClonePr.AddSidHistory”, which contains only SAM Account names of the users.
Set objClonePr = CreateObject(“DSUtils.ClonePrincipal”)
objClonePr.Connect “SourceDomainPDCDNSName”, “SourceDomainDNSName”, “DestinationDomainPDCDNSName”,”DestinationDomainDNSName”
objClonePr.AddSidHistory “anakin”, “darthvador”
Note: This also works for groups and computers (do not forget the $ at the end of the computer name in this case). Of course, it will not migrate the group membership, only the SID.
Now, practically, how would look a typical domain migration/consolidation end-to-end with the following constraints:
– Users exist in source and destination domain and must be reconciled
– Computers exist in source domain only and must be migrated
– Groups exists in source domain only and must be migrated
– Profiles and Permissions must be translate on all systems
You would have to plan the following steps:
1. Prepare a CSV text file containing the user-mapping between the source and the destination domain. It would look like:
2. Using ADMT, migrate the groups preserving SID History
3. Migrate/reconcile users using the script snippet above and the file made at step 1
4. Manually or using a script (I’ll provide an example in a later post), reconcile the group membership
5. Using ADMT, migrate the computer and perform security and profile translation. ATTENTION: you will need to run ADMT multiple times in order to get the permission and profiles correctly translated:
Run #1: Just to change the domain affiliation of the computer. The Migrated computer will reboot
Run #2: Chose Security Translation and all options as default. The Migrated computer will not reboot
Run #3: Chose Security Translation BUT specify a SID-mapping file, which is actually the file made at step 1
6. Optionally migrate logon scripts, GPO’s… as necessary
In a later post, I will publish and comment scripts to help getting the whole job done.