The Sysadmins

This post will look at preparing your workstations and servers to work with ADMT and to make sure you give ADMT the correct permissions and connectivity.

Local Administrators Group

The ADMT Migration Account that you use to migrate workstations and member servers must have local administrator rights in the the source domain. If you don’t the ADMT agent cannot be deployed which will result in errors such as:

ERR2:7006 Failed to install agent on \\xp1.source.local, rc=5 Access is denied.

ERR2:7674 Unable to determine the local path for ADMIN share on the machine 'xp1.source.local'. rc=-2147024891

We’ll look at two ways to achieve this with group policy.

Method 1. Restricted Groups

Create a Domain Local Security Group in the Source Domain, add the ADMT Service Account (ADMTUser in my case) to the group. You may decide to simply add the domain admins group from the target domain, as this includes the ADMTUser account. Also the Domain Admins group will get automatically added when the computers are migrated. The end result is the same though.

Create a new GPO and link it to the OU with the computer objects in.

Give it a name.

Continue reading

During the User account migration you will have the option to migrate passwords from the source domain user accounts to the target domain. If you choose to use this feature there are a few steps you need to carry out. This feature is very useful, and removes the requirement to communicate new passwords to end users.

Migrating Password Prerequisites

Before you can migrate passwords, you will need to install the password export server onto a domain controller in the source domain.

Download the tool here: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=10370 https://connect.microsoft.com/site1164/Downloads/DownloadDetails.aspx?DownloadID=53422

Before you go ahead and install PES onto a DC in the source domain you need to create an encryption key from the machine running ADMT in the target domain. In our case this is ADMT.target.local. From the command prompt run:

admt key /option:create /sourcedomain:source.local /keyfile:"c:\PES Key\PES.pes" /keypassword:*

Now head over to a DC in the source domain (AD01.source.local) and download and run the PES installer. When prompted choose the .key file you created on the ADMT machine.

Provide the password you used when creating the key.

Continue reading

In the first post we setup the trust and prepared Active directory for the migration. One of the last messages provided when creating the trust states:

To improve the security of this external trust, security identifier (SID) filtering is enabled. However, if users have been migrated to the trusted domain and their SID histories have been preserved, you may choose to turn off this feature.

What is SID History

SID history helps you to maintain user access to resources during the process of restructuring Active Directory domains. When you migrate an object to another domain, the object is assigned a new SID. Because you assign permissions to objects based on SIDs, when the SID changes, the user loses access to that resource until you can reassign permissions. When you migrate users into the target domain you will have the option to migrate the users SID to the target domain. This becomes the sIDHistory attribute under the new user object.

Resources within the source and target domains resolve their access control lists (ACLs) to SIDs and then check for matches between their ACLs and the access token when granting or denying access. If the SID or the SID history matches, access to the resource is granted or denied, according to the access specified in the ACL.

SID history can be used for roaming user profile access, certification authority access, software installation access and resource access.

To visualise this I’ve created a user called Ronnie Coleman in the source domain and run dsquery to display the user’s SID.

dsquery * -filter "&(objectcategory=user)(samaccountname=ronnie.coleman)" -attr objectsid

Here is Ronnie Coleman’s SID in the Source Domain:

If we use ADMT to migrate Ronnie Coleman to the target domain and migrate his SID from the source domain you will see both the new SID, and the sIDHistory from the source domain.

The actual process of migrating the sIDHistory will be shown in the Migrating Users part of the series, this post is simply to explain what SID History is and why you would use it in your migration.

Continue reading

You should install ADMT and SQL onto a member server in the target forest. Use the ADMT service account explained in the previous post to install SQL and ADMT.

ADMT requires a preconfigured instance of SQL Server for its underlying data store, so we’ll go ahead and install SQL 2008 SP1 Express on ADMT.target.local.

Installing SQL Express 2008 SP1

SQL Express download here: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=25052

1. Choose New Stand-alone installation.

2. Select Database Engine Service.

3. Accept the default named instance.

Continue reading

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: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=19188

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:

Continue reading