Update: please note that domain rename is not supported by any version of Exchange newer than Exchange 2003.
I'd like to introduce a relatively new Exchange 2003 tool called xdr-fixup. It's a handy tool, because it allows Exchange 2003 servers to continue to function after a Windows 2003 domain rename procedure. xdr-fixup is not technically part of Exchange 2003 SP1, but did release at the same time as SP1. Anyway, before this tool released, customers were in bad shape if they renamed a domain with Exchange in the mix. The System Attendant would not start; the resolution was to rename the domain BACK to the original name. On the Windows 2003 CD, there is a new tool called rendom.exe in the \VALUEADD\MSFT\MGMT\DOMREN directory. This tool allows you to rename your Active Directory domain. Why would anyone want to do this? Political reasons, mergers, acquisitions come to mind, but this is not a procedure to undertake at the drop of a hat. See the resources list at the end of this BLOG for more information, but the point here is domain renames are serious business and plenty of planning and lab work should happen before implementing in production. By the way, don't use the version of rendom found on the Windows 2003 CD! There is a newer release found here which fixes at least one nasty bug that most customers wouldn't even hit, but as best practice, always use the latest build. So what does the new Exchange tool xdr-fixup do? It's simply an added step to the domain rename process, a script which generates an LDIF file, which you manually import into AD. It fixes certain Exchange attributes so they reference the new domain name. You can look at the LDIF file and see exactly what is changed. Then you use xdr-fixup to verify the changes and life is good.Of course rendom and xdr-fixup both require certain permissions, and have certain limitations and requirements. In order to successfully rename the domain with rendom.exe, Enterprise Admin rights are required. In order to successfully fix-up the Exchange configuration, the account used must have Exchange Full Administrator permissions at the Exchange organization level. You also need local admin rights on the server you will be running rendom/xdr-fixup from in order to install the xdr-fixup MSI package. Rendom/xdr-fixup requirements:
AD must be in forest mode 2 (Windows 2003 Native Forest mode), so this means that all DCs must be running Windows 2003, and the forest functional level changed from AD Domains & Trusts MMC snap-in.
All Exchange servers in the org must be Exchange 2003 SP1 +
This also means no Exchange 5.5 in the org (no ADC intra-org, no SRS)
No Exchange server installed on DC/GC
For the limitations of rendom, see the rendom documentation. Limitations of Exchange xdr-fixup:
Domain rename will NOT let you rename the Exchange Org
Exchange domain rename will NOT let you merge two Exchange orgs (from different forests) into a single Exchange org.
Exchange domain rename will NOT try to overcome any limitation of the AD rendom tool
Procedure:As stated above, the xdr-fixup steps are just added to the rendom process. xdr-fixup can be run anytime after the rendom /execute step is run. Below is a VERY high level view of the entire process that is done from a control station (member server in the forest). As a matter of fact, this post is a high-level view of the process; the actual steps in your labs/production environments will be of course more detailed:
Exchange fixup steps
Reboot member servers twice
Domain Controller RenamesMany customers will choose to rename the Domain Controllers also. This makes sense since is reduces confusion. If you choose to rename domain controllers as described in the "Step-by-Step Guide to Implementing Domain Rename," you must do the following steps for Exchange:
Point the Recipient Update Service to the appropriate domain controller. The domain rename operation does not automatically update the DNS host names of domain controllers in the renamed domain. There are steps you can follow to rename domain controllers (see "Rename a domain controller" in Windows Server 2003 Server Help and Support Center). However, if you do this, you must point Recipient Update Service to the correct domain controller. Until you update this configuration, the Recipient Update Service will log warnings/errors 8033, 8201, 8284, 8264 and not function correctly.
If you had hard-coded any DSAccess domain controllers via the "Directory Access" tab from server properties in Exchange System Manager, you will have to hard-code them again after they have been renamed. The old FQDN of the server will be cached in the registry; you could manually edit the registry but choosing the DCs in the GUI is the best way to go.
Check the message queues on each Exchange server. If messages appear to be stuck, restart the Simple Mail Transfer Protocol (SMTP) service on the server.