KB ID 0001307

Problem

Seems like ages since I wrote Part Two, now we are ready to actually start moving objects from one domain to another.

Solution

ADMT: Service Account Migration

Why would you want to do this first? Well this replaces any service accounts on the OLD domain machines with migrated service accounts form the NEW domain, so when the client machines, (or servers,) are migrated they’re already using the new service account, (neat eh!) Not only that, it will replace Local accounts with Domain accounts, for which you can specify a decent (secure) password.

Common Sense Check: If you are carrying this out on a server, then I’d suggest a good backup, or if it’s a VM, then at least a snapshot before you start!

Launch ADMT > Service Account Migration Wizard.

The wizard is pretty straight forward.

When prompted select the computer(s) you want to perform the service account migration upon.

Select Run pre-check > OK > It should say ‘Passed’.

Select Run pre-check and agent operation > Start > It should say ‘Successful’.

It will locate (if found) any service accounts, you can choose whether to ‘skip’ them or ‘include’ them  > Next > Finish.

Now we have to do a ‘User migration’ for these users, (don’t panic we haven’t started migrating domain users yet.) But these service accounts need creating in newdomain.com

Launch a ‘User Account Migration Wizard’.

This time it will remember the domain settings, and should display your chosen service accounts.

Select the ‘Target OU” in newdomain.com > Next > Generation complex passwords > Make sure you tick ‘Migrate User SIDs to target domain’.

Because I was lazy, and didn’t manually enable auditing, ADMT will do it for me, (Note: This will create a security group in olddomain.com).

Update User Rights > I’m not excluding any attributes > Do not migrate if theres a conflict > Check and include the accounts as required > Select “Migrate all service accounts and update SCM for items marked include”.

Heed the local group warning > Finish > Hopefully it should complete without errors.

So now your computers, (still on the olddomain.com) have their services running under service accounts on newdomain.com.

ADMT Domain Group Migration

Wait, you are migrating groups before users? Yes, the ADMT database tracks who is in what groups, and they will all get put in the right groups as the users come across into the new domain.

There is a sequence for doing this though, you may or may not be aware there are three types of security groups and they HAVE TO be migrated in the correct order;

• First: Universal Groups
• Second: Global Groups
• Third: Domain Local Groups

To locate what types of groups you have, and what they are called, run the following commands;

PowerShell Display all Universal Groups

import-module activedirectory
Get-ADGroup –LDAPFilter "(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=-2147483640))"

PowerShell Display all Global Groups

import-module activedirectory
Get-ADGroup –LDAPFilter "(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=-2147483646))"

PowerShell Display all Domain Local Groups

import-module activedirectory
Get-ADGroup –LDAPFilter "(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=-2147483644))"

Launch ADMT > Group Account Migration Wizard.

This is probably the easiest of all the migrations, just accept the defaults and locate your universal groups.

Select the target OU > Fix Membership of group > Migrate Group SIDs to target domain  > Again I’m not excluding any attributes.

Dont migrate if theres a conflict > Finish > Hopefully they will all complete successfully.

Then repeat for the other two group types.

What about Distribution Groups? These are created by Microsoft Exchange, if you need to migrate Distribution groups then you can convert them to domain local security groups, then migrate them with ADMT. Note: You may need to fix their Email address manually, that depends on your new email deployment in newdomain.com

Converting Distribution Groups to Security Groups

Run the following commands;

$dlGrps = Get-AdGroup -Filter { name -like "GROUP-NAME -AND GroupCategory -eq "Distribution"} | select -exp SamAccountName

foreach ($dl in $dlGrps) { Set-AdGroup $dl -GroupCategory Security }

ADMT Migrating Domain Users

Common Sense Check: At this point it’s worth considering ‘user attributes’. For the uninitiated, a user attribute is a ‘setting’ that all users can have, e.g. a user-name, a telephone number, a department etc. All these are ‘user attributes‘ The attributes that users can have, are defined in the ‘Schema‘. So if you have any software that ‘extends the schema‘, this creates new attributes. The best example of this is Microsoft Exchange, which add lots of attributes. But there are third party bits of software that you may use, that do the same. For example I have client that has third party software that creates a ‘Photo’ attribute that holds the users ‘mugshot’, and another that adds employee payroll numbers. MAKE SURE that these bits of software have been installed into the target domain, if you want the attributes to migrate properly.

ADMT > User Account Migration Wizard.

Accept the defaults > Select the users you want to migrate.

Note: If you are wanting to change the username i.e. from p.long to pete.long then you can use a CSV and select ‘read objects from include file.’ 

Format

Sourcename,TargetSAM,TargetUPN
p.long,pete.long,pete.long@newdomain.com

Select the target OU > Migrate Passwords > Migrate User SID’s.

Note: Remember, if migrating passwords, to go and manually start the ‘Password Export Service’ in olddomain.com.

Authenticate > Update User Rights > Again Im not excluding any attributes > And I will terminate if there’s a conflict.

Finish > Watch them migrate.

As the users migrate, they get populated into to the correct security groups automatically.

In Part Four, we will finish by migrating machines to the new domain.

Related Articles, References, Credits, or External Links

NA