On June 29th our Systems Team successfully performed an Active Directory Domain Rename. In our research we found that this task appeared to be one which struck fear in the hearts of Windows Administrators the world over. It was very easy to find forum posts and articles that will explain the plagues of locusts that would undoubtedly rain down upon us for even considering such blasphemy, and while we were concerned for the safety of our first borns, we trudged onward with steadfast determination. The driving force behind this need was that our senior management did not want to see remnants of past iterations of our company. Our former domain name came from when the company was called something else. We had been using a custom GINA.DLL file to mask the real domain name on the Windows XP login dialog. However, since Windows Vista does not use GINA, this solution would cease being effective when our management decides to upgrade.
We created a virtual environment to test the rename on consisting of a Domain Controller, control station, Exchange server, SQL server, Live Communications Server, and an IIS server. We performed several renames with great success, noting any tweaks which were needed along the way. In the end what we found was that the rename actually executed exactly as advertised. All Microsoft core infrastructure applications (Exchange, SQL, IIS) handled the rename process gracefully and without issues. Live Communications Server does not accommodate the rename, which Microsoft clearly warns of. However, during our testing we found a workaround for LCS making it easy to get back online once the rename was complete.
Obviously this document is based on our environment, which is likely rather simplistic compared to some of yours. However, non-Microsoft applications in our environment had zero issues with the rename. Blackberry Enterprise Server, Goodlink Technologies, FACSys, AVST Voicemail Server, Track-It, Tandberg Video Conferencing, Meeting Room Manager, Veritas Backup Exec, McAfee ePolicy Orchestrator Suite, and VMware Virtual Infrastructure 3.01 all had no issues other than changing the domain account they ran as to the new domain.
We?ve put together this document with the hope of dispelling some of the myth surrounding the difficulty of the rename process. It is also our hope that if any of you are in a similar circumstance and find this as one of your options, that our experience may provide some insight as to whether it?s a good choice for you. The bottom line for us, it was WAY easier than any type of migration.
There are some helpful links at the end.
Detailed Steps
Preparation
Forest and Domain functional levels must be Windows 2003 Native.
Exchange must be Exchange 2003 SP1 or higher.
Exchange cannot be installed on a Domain Controller.
Create a control station which can be any Windows 2003 Server that is not a Domain Controller, but is a member of the domain being renamed.
Install the Domain Rename Tools, the XDRFIXUP (Exchange Domain Rename Fixup), and the Windows Support Tools from the installation CD.
Create a folder in the root of a drive called domainrename. When you install the Domain Rename tools and XDRFIXUP they will place files into their default paths (C:\Program Files\Domain Rename Tools and C:\Program Files\exchsrvr\Exchange Domain Rename Tools) which must be copied to the domainrename folder you created in the root.
On the control station, the following commands can be run ahead of your actual rename, these are run from the command prompt.
Run rendom /list (Gathers information about the existing forest and creates an XML file.)
copy domainlist.xml domainlist-save.xml (Later in the process this will be used as a comparison file.)
Using notepad modify domainlist.xml (In our case, we replaced each instance of olddomain.com with newdomain.corp, and changed the NETBIOS name from olddomain to newdomain.
Run rendom /showforest (This command verifies the syntax of the domainlist.xml.)
Create a new primary Active Directory integrated DNS zone(s) for the new domain name. If you have existing trusts, make sure that the trusted domains are able to transfer from the new zone.
If your domain was originally a Windows 2000 domain that was upgraded to Windows 2003, then you only need to create a single AD Integrated DNS zone.
If your domain was created with Windows 2003, then you need to create an additional zone called _msdcs.newdomain.name.
Execution
Backup all Domain Controllers.
If you?re using DFS, please refer to Microsoft?s documentation, we don’t use it.
Remove certificate services from local certificate authorities if you have installed them on a Domain Controller. Otherwise, Microsoft claims to sustain certificate services through a domain rename procedure.
If you have a spam filtering or mail gateway appliance which utilizes LDAP recipient verification, disable this feature.
Microsoft Live Communications Server
Make note of existing settings and configurations.
In the LCS administrator console, deactivate existing pools choosing the option to force deactivation. This is necessary because the pool still homes users.
Also in the LCS administrator console, unprep the domain, then unprep the forest.
Uninstall LCS, choosing the option to keep the user database.
The LCS proxy server does not need to be touched during this process.
Break any existing trusts.
From the Control Station:
Run rendom /upload (this populates the DNS zone of the new domain name with the Active Directory DNS objects.)
Run dsquery server -hasFSMO name (Identifies the Domain Controller that holds the Domain Naming Master role)
Run repadmin /syncall /d /e /P /q
Manually verify that the DNS records were successfully created in the new DNS zone.
Run rendom /prepare (Essentially places Active Directory into a read only mode so that no changes can be made.)
Run rendom /execute (Renames the domain using the information in domainlist.xml and forces the Domain Controllers to reboot.)
Microsoft Exchange Process
Verify that all Domain Controllers have been rebooted.
From the Control Station:
Run “XDR-fixup /s:DOMAINLIST-SAVE.XML /e:DOMAINLIST.XML /trace:TRACEFILE /changes:CHANGESCRIPT.LDF /restore:RESTORESCRIPT.LDF” (This will create two LDIF files for use later in the process.)
Reboot the Control Station twice.
Run LDIFDE -i -f CHANGESCRIPT.LDF
Reboot all Exchange servers twice.
Verify Domain Controllers fully qualified name. You will have to go to the properties of My Computer, in the Computer Name tab and click the Change, then More buttons and manually change the DNS suffix. This manual change is only necessary on Domain Controllers.
Verify that the A record of the Domain Controllers has been created in the new DNS zone.
From the Control Station:
Run random /end (This places Active Directory back into its normal mode and allows changes.)
Run “gpfixup /olddns:olddomain.com /newdns:newdomain.corp /oldnb:OLDDOMAIN /newnb:NEWDOMAIN /dc:dc1.newdomain.corp 2>&1 >gpfixup.log” (Modifies existing group policies to accommodate the domain name change. If you have paths to scripts specified with a group policy, these will have edited manually.)
Run “repadmin /syncall /d /e /P /q dc1.newdomain.corp dc=newdomain,dc=corp” (Forces replication from the specified Domain Controller.)
Create CNAME in old DNS zone for all Exchange servers redirecting them to the new DNS name. This is necessary because Outlook will not update the Mail Profile information.
At this point the Domain Rename is complete,
all domain computers must be rebooted twice in order to insure that each member computer learns of the domain changes and propagates them to all applications and services on the member computer. This also removes the DNS record of a machine from the old DNS zone and adds it to the new zone.
Despite the statement above, any services installed and running under a Domain account should be checked to make sure the new domain is represented.
Establish previous trusts if any.
Reinstall certificate services to your environment.
Microsoft Live Communications Server Reinstall:
Run Forest Prep and Domain Prep from the LCS CD.
Reinstall LCS to the original location, and specify the original user database location.
Restore previous settings manually, SIP domain, archiving, etc.
Once the install is complete, from Active Directory Users & Computers, choose an OU which will contain all LCS beneath it, right-click and choose move Live Communications Users, and select the new Pool.
Also from Active Directory Users & Computers, from the same OU, right-click and choose Configure Live Communications Users and select the options that were enabled previously.
Recreate and reapply all local certificates.
On the LCS Proxy server, specify the new name of the LCS server.
Process for remote users who?s machines are offsite:
User should login to their computer normally, then establish VPN connection.
User locks the computer while connected via VPN.
User unlocks the computer logging on as
User logs in again and should see the new domain in the login dialog.
User should reconnect via VPN, and reboot one more time.
Helpful Links
Domain Rename Tools Download:
http://technet.microsoft.com/en-us/windowsserver/bb405948.aspx
XDR-Fixup Download:
http://www.microsoft.com/downloads/details.aspx?familyid=24b47d4a-c4b9-4031-b491-29839148a28c&displaylang=en
How Domain Rename Works:
http://download.microsoft.com/download/9/6/5/965e6899-e086-4b3e-8ed6-516ea07ea225/domain-rename-intro.doc
Step by Step Guide to Implementing Domain Rename:
http://download.microsoft.com/download/c/f/c/cfcbff04-97ca-4fca-9e8c-3a9c90a2a2e2/domain-rename-procedure.doc
Support Webcast: Microsoft Windows Server 2003, Implementing Domain Rename:
http://support.microsoft.com/default.aspx/kb/819145
Support Webcast: Renaming Domains When Microsoft Exchange 2003 is in the Active Directory:
http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B838623
Using The Exchange Server Domain Rename Fixup Tool:
http://support.microsoft.com/?id=842116