Windows Server 2003 Domain Renaming with Exchange Server 2003

Microsoft has long been criticized for administrative inflexibility in some of its core products. You can't rename a Windows 2000 Server domain, and you certainly can't rename an Exchange 2000 Server organization after you've deployed servers. If you get things wrong, the only solution is to start over again—not an attractive proposition if you've deployed more than a few servers. However, with Windows Server 2003 and Exchange Server 2003 Service Pack 1 (SP1), Microsoft has provided two tools that allow you to rename a Windows 2003 domain and then make the necessary changes to Active Directory (AD) to support Exchange 2003 after the domain rename. These tools aren't for the fainthearted and they're certainly not wizard-like in terms of usability and administrative friendliness. The tools require planning and testing before you can approach a rename operation with confidence, especially in a production environment. I'll provide an overview about how the tools work and point you to some additional resources to help you prepare for the extensive testing that you'll need to perform before you can rename a Windows domain that includes some Exchange 2003 servers.

Domain Renaming
Microsoft distributed the original version of the Windows Server 2003 Active Directory Domain Rename Tools on the Windows 2003 CD-ROM in a directory called valueaddmsftmgmtdomren. Confusingly, the name of the domain-rename tool executable is rendom.exe (rather than domren.exe). The version on the CD-ROM contains a bug, so you should download the latest installation kit from the Microsoft Web site and install it on the server from which you want to run the domain-rename process. In fact, there were a couple earlier versions of Rendom, some that didn't work if Exchange was present in a forest and some whose documentation stated that Exchange was unsupported, so be sure to get the latest version right before you begin. The kit installs the files into the program filesmicrosoft rename domain tools directory.

The domain-rename tool allows you to rename an AD domain, a task you might need to perform for one of many reasons. For example, after a corporate merger, divestiture, or voluntary company name change, you might want to rename a domain to reflect the new corporate name. Or, someone might have given a domain an incorrect name and partially deployed the infrastructure before anyone noticed the error. Domain renaming lets you fix the error.

However, domain renaming addresses only a subset of the potential issues that you might encounter in managing AD. For example, apart from the earlier problem with Exchange that Microsoft has now addressed (but only for Exchange 2003 servers), the domain-rename tool doesn't allow you to remove domains from or join domains to a forest, so physically separating or merging domains as a result of a corporate merger requires other approaches. You can't change the domain that's the root of the forest. Finally, you can't swap domains in one operation, so if you want to move one domain out of a forest and bring another one in to take its place (and reuse the name of the original domain), you have to perform a set of sequential operations in which you first rename the original domain and then rename the second domain. Naturally, such fundamental operations can be performed only if your account holds Enterprise Admin user rights (or Domain Admin rights in every domain in the forest) or you have access to an account with these rights.

Before renaming anything, check that all the applications and other components of your infrastructure can support the operation. Because not many installations have used the domain-rename tool, we just don't know which applications might cause problems, but some quite likely will. Don't assume that Microsoft has tested all its own applications either. Include application testing along with the other testing you plan to do as part of domain renaming and stay tuned to newsgroups and other sources of information to pick up details of problems with applications as others encounter them.

Exchange Domain Fix-Up
The domain-rename tool makes all the necessary changes in AD to rename a Windows domain, but because Exchange extends AD with some schema updates and makes extensive use of AD to store its configuration data, you shouldn't be surprised that some special processing is required to ensure that Exchange 2003 can continue to operate after a domain rename. Microsoft built the Exchange Domain Rename Fixup tool (xdr-fixup.exe) to do this processing. Microsoft released XDR-Fixup at approximately the same time as Exchange SP1, but it isn't part of the service pack. Instead, XDR-Fixup is a good example of a tool that Microsoft is providing in a "Web release." When you download XDR-Fixup from the Microsoft Web site, it's installed by default in the program filesexchange serverexchange domain rename directory.

XDR-Fixup gives a clear indication of what the tool actually does—it fixes the Exchange settings in AD so that Exchange can continue working after a domain rename. The tool is a script that generates an LDAP Data Interchange Format (LDIF) load file that you manually import into AD to change attributes to point to the new domain name. You must use an account with Exchange Full Administrator permissions (at the organization level) to run XDR-Fixup successfully. You also need Local Administrator rights on the server on which you run the Rendom and XDR-Fixup tools (Microsoft refers to this computer as the control station in the documentation); otherwise, you won't be able to install the tools.

XDR-Fixup isn't a magic fix for all the ailments that might afflict an Exchange organization, and it won't heal the effects of bad organizational design. You can't rename the Exchange organization, nor can you merge two Exchange organizations hosted by different AD forests into a single Exchange organization. Some people are vexed if the name of their Exchange organization doesn't match their company name (e.g., after a corporate name change), but they really needn't be concerned because the Exchange organization name is visible only to administrators and has no impact on more public elements of the messaging service, such as SMTP or X.400 email addresses. XDR-Fixup doesn't affect email addresses or any of the policies that Exchange implements through the Recipient Update Service (RUS).

Microsoft hasn't yet created the equivalent of the Exchange Server 5.5 Move Server Wizard tool that lets administrators move servers from one site to another or from one organization to another. An updated tool that could handle Exchange 2003 and Exchange 2000 servers would let administrators restructure and merge organizations, but its absence indicates that dealing with AD to move servers around is even more complicated than the brain surgery that you can apply to the Exchange 5.5 directory by using the wizard.

Requirements
If you haven't upgraded your infrastructure to Windows 2003 and Exchange 2003, you can't use the Rendom and XDR-Fixup tools. In fact, AD must run in Windows 2003 native forest mode, so all domain controllers (DCs) have to run Windows 2003 and the forest functional level must be set to native mode. Your Exchange 2003 organization must be in native mode, and all the Exchange servers must run Exchange 2003 SP1 or later, which means that you have to complete the rollout of SP1 across the organization before you begin domain renaming.

Of greater concern to smaller organizations is that you can't rename the domain if the Exchange server runs on a DC or Global Catalog (GC) server. It has long been a best practice to separate Exchange from core AD servers, but small organizations are tempted to install Exchange on a DC or GC. If you're in this situation (common for companies that run Exchange on Microsoft Small Business Server—SBS), you have to use the Dcpromo tool to demote the DC or GC that hosts Exchange to a normal server before you run Rendom and XDR-Fixup, then promote the server back to its previous role afterwards.

Renaming a domain and changing settings for an Exchange organization are fundamental operations that can be successful only if the forest is in a stable and consistent state before any work starts. If you have any problems replicating information throughout the forest, you must deal with the underlying replication issues before you start to rename a domain. It's also a good idea to remove obsolete servers or domains from the forest before you begin renaming to reduce the complexity of the forest within AD.

During the rename, the forest will be in a state of flux, and flushing all the changes through the forest and restoring stability will take some time. For this reason, scheduling any other changes (such as installing software, introducing new servers, or moving users between servers) to occur at the same time is unwise. Instead, concentrate on achieving stability in the period leading up to the rename and perform the rename at a time when you know that the forest will be quiet, such as over a holiday weekend.

Steps to Rename a Domain with Exchange
You can find detailed descriptions of the steps required to rename a domain that includes Exchange in the documentation and materials listed in the Additional Resources box. Here's an overview of the steps:

Exchange server clusters require a separate step. For every server cluster in the renamed domain, you must log on to the cluster and run the following command:

C:> cluster /priv  Exchange_domain = New_domain

In this case, Exchange_domain is the DNS name before the rename and New_domain is the DNS name after the rename. In addition, verify that the account name used by the cluster service account is correct by checking the Log On As value on the Log On tab. Naturally, this account needs to be a valid privileged account in the renamed domain.

Gotchas
Like any other moderately complex procedure, domain renaming has some gotchas that you need to factor into your planning. Fortunately, aside from the reboots that are necessary during the domain-rename process (and subsequent loss of connectivity to the systems as they reboot), these gotchas shouldn't affect clients, but there are a few known issues for servers. Windows NT workstations and servers are an exception because you have to remove them from the original domain and then join them back to the renamed domain.

Microsoft's documentation includes a description of how to rename DCs along with the domains. Doing so might make sense if the DCs include the domain in their name (management might be easier if the DC names correspond with the renamed domain). However, changing DC names affects RUS because it must contact DCs to retrieve information about new or updated mail-enabled objects such as accounts. If you change DC names, make sure that RUS points to a valid DC afterwards or you won't be able to complete the process of mail-enabling objects by updating them with proxy email addresses. If you've hard-wired DSAccess (as described in the Microsoft article "Directory service server detection and DSAccess usage" at http://support.microsoft.com/?kbid=250570) so that Exchange servers use specific DCs (set through the Directory Access tab in the server's Properties dialog box, as Figure 1 shows), you need to check that these DCs are still valid after all the rename operations. If problems persist and DSAccess returns error 2075 in the event log on an Exchange server when it attempts to find a list of DCs and GCs, you might need to flush the cache on that server as noted in the Microsoft article "Event ID 2075 Occurs When You Try to Obtain a List of the Global Catalog Servers" (http://support.microsoft.com/?kbid=312425).

Changes to DC names and the resulting upheaval in DNS can also interrupt SMTP processing, so check message queues after a rename to see whether messages are building up for any particular domain. If you find more than 50 messages in a queue, stop and restart the SMTP service on the server to force the SMTP virtual servers to flush their caches and discover the new information that Exchange caches about DCs.

Finally, the Microsoft article "Supplemental steps for using the Exchange Server Domain Rename Fixup tool together with the Windows Server 2003 domain rename tools" (http://support.microsoft.com/?kbid=842116) describes a change to the ValidPorts value under the HKEY_LOCAL_MACHINESOFTWAREMicrosoftRpcRpcProxy registry subkey that you might need to make on RPC over HTTP proxy servers if you rename any of the servers specified in the registry. In fact, because hardwired server names might be present in the registry, it's a good idea to scan the registry on Exchange servers to check whether any changes are required. For example, administrators might have entered a DC name for the Name Service Provider Interface (NSPI) to use on a cluster (as described in the Microsoft article "DSProxy configuration for static ports on Exchange cluster" at http://support.microsoft.com/?kbid=282446), so if that DC name changes, you would obviously have to adjust the value on the cluster.

If You Can't Avoid It
The best way to avoid the need to rename domains is to use generic or functional names for domains rather than tying them to a company name that could change. If you call your forest Windows, you likely won't have a problem if your company decides to change its name from Acme, Inc., to Global Gobstoppers Corporation. You can take a similar approach with Exchange and call your organization Email or Messaging.

If you do need to plunge in to domain renaming, it isn't something to do on a whim. Every AD infrastructure and Exchange organization differs in some subtle respects, so you need to take time to understand the basic principles behind the Rendom and XDR-Fixup utilities and then work out how to apply them effectively in the target infrastructure. The amount of testing and validation required before you can rename a Windows 2003 domain is probably enough to stop you from rushing in to do work that you should not or need not do. After all, who knows whether another company merger or acquisition is around the corner, and you wouldn't want to do all that work twice.