Exchange for Experts: Be The Master Of Your Domain Rename With Exchange

Article
09/08/2016

Exchange for Experts

Be The Master Of Your Domain Rename With Exchange

Steve Schiemann

At a Glance:

Preparing for a domain rename
How to rename a domain
Troubleshooting domain migrations

Active Directory

Exchange Server

Domain Controllers

Windows Server 2003

Systems administrators have always assumed that after you deploy a Microsoft Windows forest for your organization, its topology cannot be changed. Without potentially complex and time-consuming reinstalls and domain controller promotion or demotion operations, this was true, at least until the release of Windows Server™ 2003.

You might make such changes for political considerations, mergers, or acquisitions—but you shouldn't take it lightly.

A tool called rendom.exe in the \VALUEADD\MSFT\MGMT\DOMREN directory on the Windows Server 2003 CD, allows you to rename an Active Directory® domain. There are certain limitations, however, which you can read about at Windows Server 2003 Active Directory Domain Rename Tools.

Domain rename operations are a serious business and entail extensive planning and lab work before implement-ing this process in production. Domains can be renamed in place, or you can restructure the existing topology. Rather than provide a step-by-step guide, I'll offer an overview to help you decide if you want to proceed.

Prerequisites

There are some prerequisites for domain rename operations from a Windows Server perspective, and more from a Microsoft® Exchange Server perspective. One specific Windows Server consideration is that Active Directory must be in Windows Server 2003 forest mode. This means that all domain controllers must be running Windows Server 2003, and the forest functional level needs to be changed using the Active Directory Domains & Trusts Microsoft Management Console (MMC) snap-in. Figure 1 shows the old and new domain structures.

Figure 1 Old and New Domain Structures

Figure 1** Old and New Domain Structures **

Unfortunately, from the time Windows Server 2003 was released until the release of Exchange Server 2003 SP1, some users of Exchange Server experienced problems after renaming one or more domains. The Exchange System Attendant service would not start and the domain had to be renamed with the original name, or Exchange Server reinstalled from backup. The Exchange Server 2003 tools download site now has an Exchange Server Domain Rename Fixup tool which allows Exchange Server to function after a domain rename.

When using the Exchange Server Domain Rename Fixup (XDR-fixup) tool, there are a number of Exchange Server prerequisites to consider:

All Exchange Servers in the organization must be Exchange Server 2003 SP1 or later. This also means no Exchange Server 5.5 can exist in the org. This includes intra-org Certificate Authorities (CAs) and Site Replication Service; the Active Directory Connector (ADC) service supports only inter-org CAs.
Exchange Server 2003 can only be installed on member servers, not on Domain Controllers (DC).
Domain rename will not rename the Exchange Server org.
Exchange domain rename will not let you merge two Exchange Server orgs (from different forests) into a single Exchange Server org.
In other words, XDR-fixup does not replace or extend the functionality of the Windows Server 2003 domain rename tools. XDR-fixup is a script that modifies certain Exchange Server attributes after a domain has been renamed so that Exchange Server can function.

If you meet these prerequisites, have a solid reason for renaming one or more domains in your forest, and like to live on the edge, then the tool combination of rendom.exe and xdr-fixup could be useful to you. Take a look at the sidebar "Renaming a Domain" for the steps involved.

Domain Controller Rename

Quite often companies that rename their domains will also want to rename their domain controller for consistency. If you do rename domain controllers, there are some minor extra steps that must be taken for full Exchange Server functionality. This is a separate process from renaming the domain. After the domain rename, your domain controllers will still have the old domain suffix. If the old domain was Contoso.com, after the random process all domain controllers in the renamed domain will still be called serverx.Contoso.com.

Domain Rename Resources

Member servers will have the new domain suffix, say serverx.NorthwindTraders.com. For more, see "Rename a domain controller" in Windows Server 2003 Server Help and Support Center, which is found at Start | Help | Support.

If you rename DCs, you must point the Recipient Update Service to the newly renamed domain controller. Until you update this configuration, the Recipient Update Service (RUS) will log warnings/errors 8033, 8201, 8284, 8264, and not function correctly. Choosing the domain controller for the RUS is easy using the properties of each RUS. Browse and select the new domain controller name. You can find more detailed instructions for working with the Exchange Recipient Update Service at How to work with the Exchange Recipient Update Service.

If you have statically configured any DSAccess domain controllers via the Directory Access tab from server properties in Exchange System Manager, or directly in the registry, you will have to hardcode them again after they have been renamed. The old fully-qualified domain name (FQDN) of the server will be cached and will need to be updated after you rename domain controllers. The same goes for clients that might have global catalog servers configured in the registry.

Next, check the message queues on each Exchange Server. If messages appear to be stuck, stop the System Attendant service and the SMTP service on the server, and then restart them in any order. Renaming a domain will cause Content (full-text) Indexing to malfunction. However, the Exchange Server MSSearch Administration Tool (which you can download by visiting Downloads for Exchange Server 2003) can be used to resolve this problem.

Troubleshooting

Occasionally the entire rendom/xdr-fixup process doesn't go smoothly. In these cases, the trace file generated by xdr-fixup has been useful. With this output file, you can search for errors such as "Did not convert attribute <attribute>:<attributevalue>". This file output, in combination with an ldifde.exe dump of the Exchange Server organization container, has led to successful Exchange Server functionality after the domain rename process.

And don't forget XDR-fixup—it can make life much easier. Although far from effortless, successful domain renaming is possible as long as certain requirements are met. Check out the additional resources for more information.

Renaming a Domain

One important tool you'll use when renaming a domain is the command-line tool XDR-fixup. You can type "XDR-fixup /?" at a command prompt to see the available switches. The Exchange Server Domain Rename Fix-up.doc (installed with XDR-fixup) gives a brief explanation of these switches. Sample syntax is also shown in the document. The XDR-fixup tool represents just one step in the domain rename process.

First, the tool generates an LDIF file. Next, you import this file manually into Active Directory with ldifde.exe. This will modify certain Exchange Server attributes so they reference the new domain name. You can look at the LDIF file and see exactly what is changed before you perform the import. You definitely want to use the /trace switch when running XDR-fixup since this generates a very useful log file. Finally, verify the changes with XDR-fixup. If the corrections.ldf file is 0 bytes, there are no corrections that need to be made.

The XDR-fixup tool can be run anytime after the rendom /execute step is run, but it's usually run immediately after. Be sure not to use the RTM version of rendom.exe, because it has been updated since then to fix a potential issue with replication. Use the version found at the link I referred to earlier.

The Process

What follows is a view of the entire process performed from a single control station, a server running Windows Server 2003 that is a member of the forest. Steps in your labs and production environments will be more detailed:

Log on as an administrator with full Active Directory and Exchange Server permissions.
Copy Rendom.exe, Gpfixup.exe, and XDR-fixup.exe (all command-line tools) to a folder such as C:\Rendom on the control station. All of the commands related to renaming a domain will be issued from this command prompt at this control station.
Open a command prompt to C:\Rendom and type "rendom /list" (see Figure A).
Open Domainlist.xml in Notepad, and save it as BackupDomainlist.xml.
Edit Domainlist.xml in Notepad to reflect the new domain name.
At the command prompt, type "rendom /upload". Wait for at least 15 minutes (or more, depending on your Active Directory configuration) to allow for a significant amount of Active Directory replication.
The rendom /upload command also generates the state file in the same directory (DcList.xml) that is used to track the progress of the domain rename operation. Verify in DcList.xml that the state of all DCs is set to "Initial", then type "rendom /prepare".
Verify in DcList.xml that all domain controllers are set to the "Prepared" state and type "rendom /execute".
Check DcList.xml. The state of all domain controllers should be set to "Done" or (hopefully not) "Error".
Type "xdr-fixup /s:backupdomainlist.xml /e:domainlist.xml
/trace:tracefile.txt /changes:changes.ldf /restore:restore.ldf".
Import the changes noted in changes.ldf by inputting "ldifde -i -f changes.ldf" at the command prompt.
Verify that the changes were made successfully by running "xdr-fixup /trace:tracefile2.txt /verify:changes.ldf /changes:corrections.ldf".
Reboot member servers twice.
Enter "gpfixup /olddns:OldDomainDnsName /newdns:NewDomainDNSName
/oldnb:OldDomainNetBIOSName /newnb:NewDomainNetBIOSName
/dc:DcDnsName 2>&1 >gpfixup.log".
Finally, at the command line, type "rendom /clean".

Figure A Saving a Description of the Forest Structure

Figure A** Saving a Description of the Forest Structure **

If possible, you should also plan on having staff standing by in all locations where you have Exchange Servers, just in case something goes wrong and you need to perform a hard reset. Better safe than sorry.

Steve Schiemann has been working with Exchange Server in Microsoft Product Support Services for over seven years. He is now on the Exchange Server administration specialty team.

Additional resources