Problem

I’ve not used ADMT for ages, I’ve got a domain migration to do soon, so I
thought I’d get on the bench and have a reminder. Although ADMT 3.2 was
‘re-jigged’ to support Server 2012 R2, I’m still going to install it on Server
2008 R2. I’ve got a test domain built to migrate from, and a new domain
setup ready to migrate into.
 Old/Source Domain: olddomain.com
 Old/Source Domain Controller: Source-DC.olddomain.com
 New/Target Domain: newdomain.com
 New/Target Domain Controller: Target-DC.newdomain.com

Solution
ADMT – DNS Setup
The old domain needs to be able to resolve names in the new domain, and
the new domain needs to be able to resolve names in the old domain. To
achieve this you need to setup ‘Conditional Forwarding’ in each domain for
the other one.

Don’t worry if it looks like there’s a problem as long as the DNS servers
can se each other, (and there’s no firewall in-between blocking TCP and
UDP port 53). Just add in the DNS server give it a while then re-open the
forwarders settings and it should have ‘gone-green’.

You can test it’s working by pinging BOTH the old and new domain
names, in BOTH domains.

In addition, we want all machines (in both domains) to set their primary
DNS Suffix, to their own domain, and their DNS suffix search list to look for
their own domain first, then the other domain. The easiest way to do that
is via group policy. On a domain controller > Administrative Tools >
Group Policy Management Console.
It’s better practice to ‘link’ your policy to the actual OU that your
computers are in, to keep things simple, (and because I’m lazy) I’m going
to link my policy to the root of the domain.
Edit the policy you have just created.

Navigate to;
Computer Configuration > Policies > Administrative Templates > Network >
DNS Client >

Setting: Primary DNS Suffix: Set to current domain.

Setting: DNS Suffix Search List: Set to current domain ‘comma‘ other
domain.
Then wait or Force a Group Policy Update, to test visit a machine and
issue an ‘ipconfig /all‘ command;

Above: you can see both the policies have taken effect.
Repeat the procedure in the new domain, (but the domain names will be
the opposite way round) like so;
ADMT – Creating Domain Trust
Both domains need to trust each other for the migration to take place. If
you have two simple domains like I do a “two way domain trust” is fine.
You would only need a ‘forest-trust‘ if you were migrating from/to root
and sub domains for example.
As the name implies Trusts are setup from Administrative tools > Active
Directory Domains and Trusts. You can setup the whole thing from one
domain, below I’m creating it in the old domain.

Welcome Screen = Next > Provide the name to the ‘other’ domain > Next
> External Trust > Next.
Two Way > Next > Both this domain and the specified domain > Next >
Provide administrative credentials for the ‘other’ domain > Next.

Domain wide authentication > Next > Domain wide authentication > Next
> Next.
Next > Yes. Confirm outgoing trust > Next > Yes. Confirm incoming trust
> Next.

Finish > READ the warning about SID history, we will have to mess about
with SID History filtering a bit further on > OK.
This step is not really necessary, (it’s just for peace of mind). I do this in
BOTH domains and validate each trust, (so you will do this four times).
Select the trust > Properties > Validate > Type in credentials > OK > Type
in Credentials > OK > OK.

ADMT – Users / Admins and Rights Assignment

Create the user that will do all the hard work in the NEW domain. Then
add that user to the domain admins group (again in the NEW domain).
Username: ADMTAdmin (Can be anything you want, but I’ll refer to this
username throughout).
Over in the OLD domain, you won’t be able to add your ADMT user into
the domain admins group, you need to add the ADMTAdmin account from
the NEW domain into the Builtin\Administrators group on
the OLD domain.

Additionally: the ADMTAdmin user needs to have local administrative

rights to all the machines in the OLD domain. The easiest way to do that is
again with a group policy.
In the OLD domain create a group, (Type: Domain Local)
Group Name: GP-ADMT-Admins, (again you can call it something else if
you want).
Add your ADMTAdmin account to this group, (Note: I like to add the
domain admin account for the NEW domain as well, though that’s not
necessary).

On a domain controller > Administrative Tools > Group Policy

Management Console.
Once Again: It’s better practice to ‘link’ your policy to the actual OU that
your computers are in, to keep things simple, (and because I’m lazy) I’m
going to link my policy to the root of the domain.
Edit the policy you have just created;

Navigate to;
Computer Configuration > Policies > Windows Settings > Security Settings
> Restricted Groups

Add Group > Select GP-ADMT-Admins > OK > Add (bottom option) >
Administrators > OK.
Setup correctly it should look like this;

To Test: On a client Open an administrative command window > and

run ‘gpresult-R’.
Or the best test is, make sure that the GP-ADMT-Admins group is actually
in the local admins group.

ADMT – Database Requirements

OK, a lot of posts say don’t install ADMT/SQL on a domain controller. That’s
not strictly true, you can install ADMT and SQL on a domain controller, in
fact that’s what Im going to do (there are a few commands and extra steps
that I will point out below).
You can you use full blown SQL if you like, but it’s just as easy to use SQL
Express 2008 SP1 > Download and run > Instalation > New SQL Server
stand-alone installation or add features to an existing installation.
Accept the defaults > In feature Installation select ‘Database Engine
Services’.

Accept the named instance ‘SQLExpress’.

Keep accepting defaults until you get to ‘Server configuration‘ page,
add in the ADMTAdmin account.

Then add in your ADMTAdmin account again. (Once again theres nothing
wrong with adding the domain admin account as well).
ADMT – Additional SQL Steps For Domain Controllers

Open an administrative command window > and run the following

commands;
NET LOCALGROUP SQLServerMSSQLUser$Target-DC$SQLEXPRESS /ADD

SC SHOWSID MSSQL$SQLEXPRESS

{Copy the SID to the clipboard you will need it in a minute}

MD %SystemRoot%\ADMT\Data
ICACLS %Systemroot%\ADMT\Data /grant *{Paste the SID from above}:F
i.e.
ICACLS %systemroot%\ADMT\Data /grant *S-1-5-80-3880006512-4290199581-
1648723128-3569869737-3631323133:F

ADMT – Downloading and Installing ADMT

Download the ADMT software, if that link ever dies use this
one. Download ADMT 3.2. Launch the installer and accept all the
defaults until you get to database selection, use .SQLEXPRESS

No we don’t want to import and data from an existing database > Next >
Finish.

We can now open the ‘Active Directory Migration Tool’ management

console.
Problem
Back in Part One we setup our migration admin account, and installed
ADMT. Now, as I’m going to migrate the users passwords I need a
‘Password Export Server‘, but first I need to tackle the subject of user SIDs

Solution
Domain Migrations and SID Filtering
Every user has a SID (Security Identifier) it’s the thing AD uses to refer to
and apply security to users, (and other objects). This is why you can
rename a user and it’s security does not change, (because the SID always
remains the same). Why is this important for domain migrations? Well if
you’re a doing a migration that’s taking place over a period of time, users
in the NEW domain may still need access to things IN the OLD domain,
(like file shares, printers, applications etc).
This is a problem because when you setup a domain trust it Enables SID
filtering, back in part one it told you this, here. So if a user
in newdomain.com tries to access a folder, (they could access before the
migration,) in olddomian.com they wont be able to do so, (because their
SID has changed, to a new SID in the new domain. Even if you migrated
their old SID if get’s filtered out as the user comes back over the trust).
How do we fix that? We need to do two things,
 Migrate the users old SID to newdomain.com (This then become
their, sIDHistory attribute)

 Disable SID filtering in olddomain.com (To allow the

sIDHistory attributes to come back over the trust)
This lets users in the new domain have their NEW SID, and their OLD
SID.
Migrating the users SID is simple, (it’s just a box you tick when running a
migration, you will see that later). Disabling SID filtering can be a little
confusing. Where do you do it, and which way round do you execute the
command? Above I’ve solved the first one for you you Disable SID
Filtering on the OLD domain. The following diagram will explain why;

Usually users DON’T have a sIDHistory. attribute, (unless they’ve been

migrated before!) They only have a SID (objectSID attribute.) To
demonstrate let’s jump forward in time, and look at a migrated user
(ABarksdale)

Click to enlarge the above image, and inspect the users SID (objectSID)
and old SID (sIDhisttory) attributes.
In the olddomain.com;
objectSID: S-1-5-21-227018303-3265311450-382577
sIDHistory: {None}
In the newdomain.com;
objectSID: S-1-5-21-3846632479-19853633304-4016520
sIDHistory: S-1-5-21-227018303-3265311450-382577 (Note: objectSID
migrated from olddomain.com)

Disabling SID Filtering

Now we know where to do it, we just need to construct the command to

disable it. Run the following command;
netdom trust {source-domain} /domain:{target-domain} /quarantine:No
userro:{username} password:{password}

Or for a Forest Trust

netdom trust {source-domain} /domain:{target-domain}
/enablesidhistory:Yes /userD:{username} /passwordD:{password}

So in my example;
 source-domain: olddomain.com
 target-domain: newdomain.com
 username: (Domain administrator in olddomain.com)
 password: Password for user above.

ADMT: Setting up a Password Export Server

As the name implies, this is a piece of software that runs on the source
domain, (on a domain controller,) that ADMT uses to migrate user
passwords. Before you can do this, you need to create a ‘key’ in
the NEW domain, (where ADMT is running). Then, you use that key to
setup the password export server in the OLD domain.
On the ADMT Server open an administrative command window and
issue the following command;
admt key /option:create /sourcedomain:{source-domain} /keyfile:”C:\
PES.pes” /keypassword:{password}

So in my example;
 source-domain: olddomain.com
 keyfile: Where you want to save the keyfile.
 password: can be anything you want, but you will need it to setup
the password export server, so don’t forget it.

If it runs OK, find your keyfile, then copy this to the domain controller in
the old domain you are going to install the password export server service
on.
Theres two versions of the password export server software, (a 32 bit and
a 64 bit version.) Download and install the version applicable to your
source domain controller.
Passport Export Server 64 bit version
Passport Export Server 32 bit version
Note: The install requires a reboot of the server, you might want to do this
at the end of the day.
The install is pretty simple, Accept the EULA, browse to the keyfile, and
enter the password you used above.

Specify a user account to run the service as, (I just use the ADMTAdmin
account we’ve already created).
Finish the install, and let it reboot.

After a reboot, if you look in the services (Start > Run > services.msc).
You will see the ‘Password Export Server Service’.
Note: You will also notice the startup type for the service is
‘Manual’. ONLY start this service, when you are actually migrating
passwords.

ADMT: Granting Local Rights to ADMT user in the Source Domain.

To migrate machines, the ADMTAdmin user needs “Local” administrative
access on all the source machines. The easiest way to do this is via group
policy, using ‘Restricted Groups’. This allows you to take a group (or user)
and put put them on the local groups (including administrators) of the
targeted machines.
In the OLD domain, create a group and put the ADMTAdmin from the
target domain in it. (I put the domain admin from the target domain in it
as well, to be on the safe side, but that’s up to you).

Note: You may see this a few times while doing migrations, notice above
the user icon there’s a small red curved arrow (below), that logo denotes
‘Foreign Security Principle’, it’s not really our user at all, it’s a special
object that AD creates in a hidden OU, (turn on advanced mode in AD
users and computers you can see them.)
Create a new GPO that will apply to the computers/servers you are going
to migrate.

Edit it.
Navigate to;
Computer Configuration > Policies >Windows Settings > Security Settings
> Restricted Groups

Add a new one, select the group you have just created > and add it to
‘Administrators’.

It should look like this when you are finished.

Windows – Forcing Domain Group Policy
To test it has applied, on a client run ‘gpresult -R’ at an administrative
command prompt.

You can of course, simply check the local administrators group to make
sure the new group is in there.
ADMT: Additional GPO Note
To perform computer migrations, (and security translations), ADMT needs
to deploy an ‘agent’ to the machines in the OLD domain. The local firewall
(if enabled) can stop this, I simply disable the local firewall. (If someone
wants to send me a list of ports to add, to make it work I’ll publish the).
But even the Microsoft Documentation on Technet says disable the
firewall.
Create a new GPO linked to where your source computers are, (here I’m
just linking to the root of the domain).

Edit the GPO.

Navigate to;
Computer Configuration >Policies > Administrative Templates > Network >
Network Connections > Windows Firewall > Domain Profile

Locate “Windows Firewall protect all network connections‘ and set it to

disabled.

Windows Group Policy – Disable The Local Windows Firewall

In addition I have also seen the agent fail to deploy if the ‘Remote Registry
Service’ is not running on the target machines, (it’s disabled by default).
So I use this policy to turn that on as well.
In the same GPO navigate to;
Computer Configuration > Polices > Windows Settings > Security Settings
> System Services

Locate the ‘Remote Registry’ service, and set it’s startup to automatic.
This may take a while to permeate down to all the machines, Windows –
Forcing Domain Group Policy
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.
Problem
On the homeward stretch now, back in Part Three, we migrated service
accounts, groups, and users. Now we turn our attention to our machines.
Note ADMT 3.2 Only support the migration of Operating Systems up to
Windows 7, (that doesn’t mean Windows 8 and Windows 10 wont work, it
just means they are not supported). Migrating Windows 8 and 10 throws a
lot of security translation errors, because of the way it treats ‘Apps’, so I’d
recommend you do a LOT of testing before carrying out a live migration.

Solution
ADMT Computer Security Translation
Migrating computers is a two-step procedure, you do a security
translation on a machine, then you migrate the machine. The security
translation adds the security for the user(s) in newdomain.com to all the
objects (files, folders, user profiles, and registry hives, etc) that their user
account in olddomain.com did. like doing the service account migration
(above) the plan is to get everything ready to ‘work’ before the machine is
migrated.
Real World Note: This can take a while, (up to an hour for some
machines,) and it’s best done without anyone being logged in (to prevent
any profiles, or registry hives being locked). So take time to plan when this
is done – rush it and you will have problems, and the very users who are
too busy to be interrupted, are the very ones that shout the loudest if
there’s a problem post migration. I would (if possible) have a stock of
prebuilt machines on the new domain in case there’s any migration
dramas, at least then you can get people working quickly.
This should be getting familiar by now, accept the defaults.

Select your computer(s) > Select all the options > SELECT ADD > Finish.
Agent Note: You are about to deploy the ADMT agent, make sure you
have followed part one and part two. This process will be familiar if you
carried out the service translation wizard earlier.

Run the pre check, and agent deploy.

What you will find after translation is all the profiles, and files etc will have
the new domain users added alongside the old one with the same rights.

ADMT Computer Migration

Now finally to migrate the machines, ADMT > Computer Migration Wizard.
Select the computers.

Select the Target OU > Tick everything > Add > Select the amount of time
to wait before rebooting the machine into the new domain.
Hang About Haven’t we done some of this? Yes, but because you
have done the security translation already it can see the ACLs exist as it
goes through and skips creating them.
As usual I’m not filtering any attributes > I’ll quit if theres a conflict >
Migration should then complete.

Can I migrate Servers With ADMT?

Yes, but you need to have a good think about doing so first? For simple file
and print servers that should be OK (Obviously back them up first
etc). DONT try and do this with an Exchange server, or any other server
that relies on Active directory for its very existence! And wherever
possible if you can create clean new servers and migrate your data into
them do so!

What about Microsoft Exchange and User Mailboxes?

I mentioned Exchange briefly on the user migration, Exchange migrations
between domains, are possible, depending on your setup it may be easier
to export all the mail form the old system and import it into the new one
(use the search bar above. I’ve already written a load of stuff about doing
this). In the not to distant future I’ll cover Exchange Inter Organisation Mail
migrations.
Readers Note:
As with all the articles here, please provide feedback below, if one thing
you have found can save another reader sweat and toil, then that’s the
very reason for this site! If you have been with this since part one thanks
for staying till the end (PL).