The Sysadmins

Tips and tricks from the Sysadmins

ADMT Series – 1. Preparing Active Directory

Introduction to Series

After recently using ADMT for an Active Directory migration I thought I’d write a series to document its use and to share any useful tips I found along the way. This first post will explain how to prepare the Active Directory for the migration process.

If you’ve found this blog post you’re probably already aware of what ADMT is and what it can be used for, and I’d suggest (as always) to read the documentation provided by Microsoft. The user guide for ADMT can be found here:

Series Test bed

In this Series I’m going to be using 3 servers and an XP client.

Server 1 AD1 – Target Domain Server 2008 R2 Domain controller in the target.local domain
Server 2 ADMT – Target Domain Server 2008 R2 Member Server running ADMT in the target.local domain
Server 3 DC1 – Source Domain Server 2003 Domain controller in the source.local domain
Client 1 XP – Source Domain Windows XP client in the source.local domain

The goal of this series will be to migrate from the 2003 source.local Domain to the 2008 R2 target.local domain.

Preparing Active Directory

In this post we’ll look at preparing Active Directory for the migration process. There are two main things to prepare, DNS and a domain trust.

Before the domain trust can be created both domains will need to be able to resolve each other via DNS. To achieve this you can use stub zones, secondary zones or forwarders. I’ll show you how to setup forwarders below on Server 2003 and 2008 R2. When using forwarders you need to manually populate the IP(s) of the name servers you’ll be using for resolution, if for whatever reason these change you will have to manually go back and change the forwarder. This probably isn’t an issue for most scenarios.

Setting up a Server 2008 R2 DNS Forwarder

1. Open the DNS MMC console, expand the server tree and select Conditional Forwarders. Right click and select new conditional Forwarder.

2. Enter the other DNS domain name (the source domain in this case), then click below where it says “Click here to add” and enter the IP address of on the DNS servers in the other domain. Press enter. If you have multiple DNS servers in your Active Directory it’s a good idea to store the conditional forwarder in AD, and replicate it accordingly.

Before the forwarder:

After the forwarder:

Setting up a Server 2003 DNS Forwarder

1. Open the DNS MMC console, right click on the server and select properties.

2. Select the 2nd tab along titled ‘Forwarders’, new, enter the other DNS Domain (the target domain in this case) and click OK. With the Domain selected enter the IP address of one of the DNS servers in the other Domain and select Add.

Setting up the Domain Trust

The trust will be created completely on AD1 in the Target.local domain.

1. Open the Active Directory Domains and Trusts, right click on the domain and click properties.

2. Head over to the Trusts tab and select new trust.

3. Enter the DNS domain name of the other Domain.

4. Choose External or Forest trust, to setup a forest trust both domains will need to be at a 2003 Forest Functional level or higher. As we’re dealing with two single domains an external trust is fine.

5. We’ll use a two-way trust.

6. To setup both sides of the trust from the target domain you will need domain administrator credentials for the source/other domain.

7. Domain-wide authentication.

8. Confirm both the incoming and outgoing trusts.

I will cover SIDHistory in the next blog post, so we can ignore this for now.

Here we can see the trust in place.

Suffix Search List

Now that we have the forwarders in place in the source and target domains, clients from either domain should be able to resolve FQDNs from the other. However you will want to add the source/target domains suffix to the suffix search list, allowing simple, single-label names resolution.

On the Server 2008 R2 server, open Group Policy Management in Server manager, right click on the level you want to apply the policy to and select Create a GPO in this domain, and link it here… We’ll call our GPO Trust – Suffix.

Dig down to Policies -> Administrative templates -> Network -> DNS Client. Set the Primary DNS Suffix to the current domain, so in the Target.local domain we’d put this was Target.local. Then enable the DNS Suffix Search List policy, add the current domain first, then add the other domain- seperated with a comma.

In the Server 2003 domain you can either add the policy via ADUC or via GPMC ( The settings are in the same place.

We can see the policy applied when we run an ipconfig /all. The clients will now append the primary suffix first, then try the additional suffixes found in the suffix search list.

ADMT Migration Account

The account you run ADMT under will need to have administrative rights in both the source and target domain. You may decide to create a user specifically for the ADMT Migration, or you may use an existing user e.g. the default administrator account. I will create a user called ADMTUser and assign this user the correct permissions. This is the account we will use for the entire migration.

It is recommended that you make the user account in the target domain and make it a member of the domain administrators group.

Target Domain:

In the source domain add the same user to the builtin administrators group (you will be unable to add it to the domain administrators group).

Source Domain:

ADMT Series – 1. Preparing Active Directory
ADMT Series – 2. Preparing the ADMT Machine
ADMT Series – 3. SID History
ADMT Series – 4. Password Export Server
ADMT Series – 5. Machine Preparation
ADMT Series – 6. Service Account Migration Wizard
ADMT Series – 7. Group Account Migration Wizard
ADMT Series – 8. User Account Migration Wizard
ADMT Series – 9. Merging Users with a Different sAMAccountName
ADMT Series – 10. Security Translation Wizard – Local Profiles
ADMT Series – 11. Computer Migration Wizard


  1. Hi guys,

    Today we tried to create a 2 way trust between 2 domains and we had an issue where as the trust would fail because it could not find any log on servers (domain controllers) we spotted in the domains and trust snap-in that the domain controller selected was not the one in the remote office. We have a hub and spoke MPLS network and only the remote office network has a route to the acquired company’s network. When we tried to change domain controller to the one in the remote office the new trust button was grayed out. We figured it had to do with the FSMO role holders (we moved all without really narrowing down which one was the crucial) Once we moved all FSMO roles up to the DC in the remote site we could create the forest trust.

    This could maybe help some others out there dealing with similar issues

  2. This guide is freaking awesome man!
    Thank you so much for creating it.

  3. Best guide I’ve seen yet.

  4. Awesome guide, I’ve referenced many times recently. Thanks!!!

  5. Mate, awesome guide. Congrats and thanks for sharing.

  6. Loving this already. Very detailed and easy read.

  7. This is the link for password export server Microsoft has restored this link

Leave a Reply

Your email address will not be published.


This site uses Akismet to reduce spam. Learn how your comment data is processed.