Plan and Execute an Active Directory Merger, Part 1

In today's business culture, it's not uncommon for companies to merge or for one to buy another. One day, you're an administrator taking care of your Active Directory (AD) domain and Microsoft Exchange Server organization, and the next thing you know, you have to figure out a way to merge two companies. Now what?

This two-part series explores some of the ins and outs of an AD and Exchange Server migration. The procedures I demonstrate aren't the only way to perform a migration. In fact, no two migrations are ever the same. My intention is to paint a picture and help you set up a simple migration in a lab environment. Running through the process and learning how the different tools work will help you plan a migration for your unique situation.

Planning Is the Key
Merging two AD domains is fairly easy; doing it while the network is in use is a little more difficult. I explained it to my wife this way: Changing out a car engine is pretty simple. The process is well-documented, and there are tools to help you do the job right. But changing out the engine while the car is traveling 60 miles per hour—and doing it so the occupants don't notice? That takes a bit more planning to pull off.

You can't overstate the need for detailed planning on a project as complicated as a company merger, particularly with tasks involving the IT departments. If you shortcut the planning process, you'll pay for it eventually. Some things to plan for are

For this scenario, the big company that purchased the smaller company is called New.com and the small business that was purchased is called Old.com. We'll assume that the network engineers have solved the connectivity issues with either a site-to-site VPN, Multiprotocol Label Switching (MPLS), or another secure solution. Nothing I describe can be completed without network connectivity.

Easy Wins First
An AD and Exchange merger can takes months to plan and implement—a timeline that might not sit well with company management. Other departments are also combining business processes, and IT can become a bottleneck. To help smooth the immediate transition, try implementing some of the following easy wins that give the appearance of a combined enterprise.

One company, one email. A fast way to show the rest of the world that you're now one company is to make sure everyone has the same email suffix (e.g., new.com). Microsoft has a detailed article, "How to share an SMTP address space in Exchange 2000 Server or in Exchange Server 2003," that explains how to set up the recipient policy, a new SMTP virtual server in your Exchange organization, and contacts so that it appears to your customers and internal users that you have one email system. For setting up a similar structure in Exchange 2007 environments, see "How to Configure Exchange 2007 to Route Messages for a Shared Address Space."

As Figure 1 shows, email for New.com still flows to the existing email server at New.com's headquarters. If a message comes in for an employee of Old.com to a New.com address, the Exchange server forwards it to the Old.com email server. When an employee of Old.com sends a message, the primary address (aka reply-to address) is New.com. You'll eventually want to move all email into one Exchange organization, but this trick buys you some time to perform your migration.

Free/busy information. A company merger requires excellent communication from everyone on both sides, and this typically means lots of meetings. Unfortunately, separate Exchange organizations don't share calendaring—or, free/busy—information by default. When an executive tries to schedule a meeting with someone from the other company, he or she is met with gray hash marks in Outlook instead of the distant user's schedule.

You can create another easy win by sharing free/busy information between the company's two halves. Microsoft provides a free tool called the Inter-Organization Replication tool that replicates public folders and free/busy information. The tool isn't cluster aware and gets confused when installed on a cluster node, so if you're running an Exchange cluster, you'll need a standalone Exchange server to use for replication. When you set the username and password settings, be sure to preface the username with the domain name: DOMAINUSERNAME.

Free/busy information replicated between Exchange organizations can be as much as 30 minutes old; be sure to communicate this detail to your users. The application comes in two parts: the Replication Configuration program and the Replication service. The Microsoft article "Installing, configuring, and using the InterOrg Replication utility" walks you through using this tool.

Trusts. Your business leaders need to share data files—documents, spreadsheets, presentations, and so forth—and they need to do it securely and not always through email. This process is simple after the domains are merged into one, but you need a solution to satisfy the immediate need. To grant a user from one domain permission to use a resource on another domain, you need to set up a forest or domain trust. I explain how to set up a simple forest trust later in the article.

You might find other easy wins that you can quickly deploy. Take time to listen to the needs of the business and come up with solutions that buy you time to properly plan the full migration while helping the rest of the company with the transition.

Moving Toward Migration
As soon as you have taken care of the immediate needs of the company, it's time to get started with a detailed plan for the AD domain and Exchange organization migration. If you have only a few users, computers, and servers, you might get away with simply adding those objects to your domain using scripts and other homegrown methods. But if you have a larger domain, it will be worth your time to investigate the third-party tools that are available. Vendors such as Quest and NetIQ have products that can help you assess and even model your migration.

Microsoft provides a free utility called Active Directory Migration Tool (ADMT), which might be sufficient for your needs instead of using a third-party product. The latest version, ADMT 3.1, provides support for 64-bit environments; you can find it in the Microsoft Download Center. Exchange Server has a built-in mailbox move tool, but there are third-party solutions for this task as well. However, the rest of this article assumes you're using ADMT and the built-in Exchange tools. The concepts should be similar for any product you choose.

SID History to the Rescue
If you can't migrate everything to the new domain within a few hours, you'll probably have to divide the migration into stages, with some users and system processes continuing to work from their original domains while others move to the new one. User and group migrations copy only the name of the object to the new domain; the objects themselves are actually brand new and, as such, they get a new SID from the new domain. This situation can cause problems when migrated users attempt to access resources that are still in the old domain, which won't recognize the new SID.

One solution is to use SID history. As Figure 2 shows, a user in the New.local domain that was migrated from the Old.local domain has two SIDs—the newly generated one for the New.local domain and the one from the old domain, now an attribute in SID History. When the user accesses a resource on the old.com domain, the file server matches the SID from the old.com domain, and the user is granted access. To take advantage of SID history, you need to disable SID filtering between the domains so that the object's SID can be migrated to the new domain along with the object, a process I'll describe later in this article.

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:

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:

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_MACHINESystemCurrentControlSetControlLSAAllowPasswordExport. 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 SupportTools 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.