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_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy 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.