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
- training for the technicians performing the migration
- scheduled outages
- company cultural differences such as who's allowed access to AD and Exchange, or how file system security is set
- network differences between the two sites
- network, AD, or Exchange anomalies
- customer and employee communication
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: DOMAIN\USERNAME.
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.
