ADMT (Active Directory Migration Tool) Domain Migration – Part 3

KB ID 0001307


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


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.

ADMT Rights to Profiles

The wizard is pretty straight forward.

ADMT Service Account Migration

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

Service Account Migration Inter Domain

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

ADMT Pre Check

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

ADMT Agent Install

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

ADMT Service Account

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

Launch a ‘User Account Migration Wizard’.

Migrating Service Accounts Windows 2016

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

ADMT service accounts

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

ADMT 2016


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

ADMT Enabling Auditing

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”.

ADMT Migration eUsers


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


So now your computers, (still on the have their services running under service accounts on

Migrated Service Account

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))"

Powershell List AD Groups

Launch ADMT > Group Account Migration Wizard.

Group Migration ADMT

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.

Migrate Universal Groups

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


Then repeat for the other two group types.


ADMT Migrating Groups

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

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.

ADMT Migration domain Users

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.’ 



ADMT User Migration

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

User Password Migration

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

ADMT User Attributes

Finish > Watch them migrate.

Bulk Migrating Users

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

ADMT Migrated Users


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

Related Articles, References, Credits, or External Links


Author: PeteLong

Share This Post On


  1. Hi Pete, Did you ever complete part 4?

    Post a Reply
  2. Our application team wants a TEST AD which will be a replica of our production AD. Can I follow the steps to achieve it?

    The following statement concerns me.

    PART 3: 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.

    1. I dont want service account disabled or deleted or replace in PROD
    2. I want the exact service accounts in the new Domain as well.

    Post a Reply
    • Why do a domain migration to a ‘Test AD’, if your servers are virtualised, simply clone the VMs into a separate network, and grant the application test team access to that, thats a much better approach? If the servers are Physical then P2V convert them into VMs (either VMware or Microsoft) then the team can run them as VMs on their own machines and do what they want with them, if they break them they can simply roll back to snapshot.

      Post a Reply

Submit a Comment

Your email address will not be published. Required fields are marked *