Plan and Execute an Active Directory Merger, Part 1

Configure Name Resolution and Forest Trusts
Now it's time to get to the migration mechanics. Be sure to plan time in a lab environment to familiarize yourself with the setup process.

A 2-way trust between the domains is a requirement for domain migration. You might have established this trust earlier; if not, you'll do it now. Before you can create the trusts, both domains must be able to resolve Fully Qualified Domain Names (FQDNs) in the other domain. You use the Forwarders tab in the DNS server Properties dialog box to have each DNS domain point to the other. Figure 3 shows the configuration where machines in the New.local domain can resolve machines in the Old.local domain. When complete, you should be able to ping server1.old.local from any machine in the New.local domain.

To connect to a host name in the other domain without using the FQDN, add both domains (new.local and old.local) in the Advanced TCP/IP settings on each machine. This task can be tedious, so you'll do yourself a favor by using Group Policy for it.

Use the Microsoft Management Console (MMC) AD Domains and Trusts snap-in to create 2-way trusts between the domains with the following procedure:

1. Log onto a domain controller (DC) on one of the domains (it doesn't matter which) and open AD Domains and Trusts.
2. Right click the domain and choose Properties.
3. Click the Trusts tab, choose New Trust, then click Next.
4. Enter the FQDN of the other domain; this is why you need to have the DNS Forwarders set up properly first.
5. For the trust type, choose Two-way.
6. Choose Both this domain and the specified domain on the Sides of Trust page to create the trust simultaneously from both domains.
7. Enter the other domain's administrator user name and password, then click Next.
8. Review your settings, then click Next.
9. Click Yes, confirm the outgoing trust, then click Yes, confirm the incoming trust so that the DC will ensure that your trusts are working correctly.
10. Click OK to confirm the message about SID filtering; we'll disable SID filtering in a later step.

Set Up the Password Export Server Service
ADMT can create new, complex passwords for your migrated users, but you'll have to distribute those passwords securely to your users. In my experience, migrating passwords from the old domain to the new domain is easier for everyone involved. If you're concerned about passwords being transmitted across the network, take comfort in the fact that they're encrypted on the wire and, by default, users are required to change passwords on first logon. Here's how you do it:

1. Log on as a domain administrator or equivalent to the computer on which ADMT is installed.

2. At a command prompt, use the following ADMT command to create the .pes file:
   
   admt key /opt:create /sd:old /kf:c:\

3. Copy the .pes file you just created to a DC in the source domain (old.local).
4.  Install the Password Migration DLL on the Password Export Server (PES) by running pwdmig.msi. PES can be downloaded from the Microsoft Download Center; be sure to use the PES from ADMT 3.1 if you're running 64-bit DCs. PES installation is quick and will prompt you for the .pes file that you created earlier.
5. Specify that the Password Export Server service runs as a user with domain administrator privileges. You must use the domain\account format.

You'll need to reboot the DC after installing the PES service, so be sure to plan for this downtime. The PES service is set to Manual by default, so it won't start when the server reboots. In addition, you need to change the following DWORD registry subkey to 1: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\AllowPasswordExport. For security reasons, Microsoft recommends that you keep the PES service off and the registry subkey set to a value of 0 until you're ready to migrate passwords. For additional information, see the Microsoft article "How to use Active Directory Migration Tool version 2 to migrate from Windows 2000 to Windows Server 2003."

Disable SID Filtering
To allow the users and groups SID to pass back and forth between the domains, we need to disable a security feature called SID filtering on the source domain. From a DC on the old.local domain, type the following command:

netdom trust old /domain:new /quarantine:No
 /UserD:Administrator /passwordD:P@ssword 

Although the code breaks here for space reasons, you would enter it all on one line. If SID filtering has been disabled properly, you'll receive a message telling you SIDs are no longer being filtered. Note that Netdom isn't installed on Windows 2003 or Windows 2000 servers by default, but you'll find it on the server CD-ROM in the Support\Tools folder.

Create a Migration Server
I've found it easier to perform migrations from a dedicated server. It doesn't need to have a lot of power; a simple virtual machine (VM) running Windows Server 2003 Standard is sufficient; ADMT won't run on Windows XP. Be sure to make the migration server a member of the target domain, New.com. Even though you have a trust between the two domains, always log on to the new domain when migrating objects from the old directory to the new one.

There's also a small but very important step that must be completed on the old domain to let you migrate objects to the new domain: Add a target Domain Admins user account to the built-in Administrators group in the source domain, as Figure 4 shows.

When you install ADMT on the migration server, you have two choices for storing the migration data. You can choose the free SQL Express for small and simple migrations or use a more powerful SQL Server version for large, complex projects. Which one you choose will depend on your specific scenario. To keep the example as simple as possible for this article, we'll use SQL Express.

Prepare the Computers and New Domain for Migration
The last step in preparing the environment for migration is to ensure that computers themselves are ready for migration. Newer versions of Windows have a firewall that blocks connection attempts by the ADMT. The ports ADMT uses aren't well-documented. However, you can disable the XP firewall just long enough to perform the migration. To do so, create a Group Policy Object (GPO) that opens up the firewall and link it to an organizational unit (OU) called MigrationPrep, then move the computer to this OU right before you're ready to migrate. You'll also want to verify that the target OU is ready with all of the correct GPOs applied.

The user performing the migration needs to have administrator privileges on each computer that will be migrated, which can be done with a GPO linked to the MigrationPrep OU. I describe this method in "Adding a Global Group to the Local Administrators Group." The user performing the migration also needs to have permission to join computers to the new domain.

According to Microsoft's ADMT Guide (available from the Microsoft Download Center), "All target domains must be operating at either the Windows 2000 native functional level, the Windows Server 2003 functional level, or the Windows Server 2008 functional level." This process is irreversible, so be sure you understand the consequences before raising the domain functional level. To raise the domain level, open the MMC AD Users and Computers snap-in, right-click the domain (new.local), and select Raise Domain Functional Level. Choose Windows Server 2003 on the next screen, then click OK.

Preparation, Preparation, Preparation
As you can see, just the preparation for an AD migration can be a complicated process. You'll want to take time to try this out in a lab environment before attempting it in production. In the second part, I'll show you how to migrate the users, computers, and groups to the new domain. We'll also tackle the task of the Exchange portion of the migration.