How to: Rename an Active Directory Domain Name
There are many reasons why you might want to rename an Active Directory Domain Name. Microsoft names situations were there is a reorganization of the enterprise which could simply be internal or due to an adquisition, etc. In my case I have been reading about how to properly name an Active Directory Domain Name. Back in the days of Windows Small Business Server 2003 Microsoft recommended that you named your forest Something.Local. Because .Local is not accepted or recognized in the Internet it gave you a level of separation that avoided DNS issues that using a valid domain name would. However, come 2007 the best practice changed and although a lot of people continue to use .Local this presents a few issues. The most important one is that no public CA would issue a non-valid public domain name. Further reading seemed to indicate that the current best practice is to name your Active Directory Forest after an available subdomain name, for example: Corporate.Bauzas.com or AD.Bauzas.com or Internal.Bauzas.com and have the hierarchy trickle down from there. Because of this I decided it was time to rename the Domain to align to the new best practices. I also had some issues with Apple OS X networking… apparently .Local is reserved for other uses.
Below are some simple instructions on how to rename your domain name in Windows Server 2012. I strongly recommend/encourage that you read the whole article/pages on Technet as this is a major operation. You should first do this in a lab environment and should study everything carefully… last thing you want is messing up your entire AD infrastructure.
But before that here are a few things I encountered that might save you trouble when you do rename your Active Directory Domain Name:
- The DFSR did not work right out the bat. I ended up removing manually through ADSEdit all the references to the namespaces and replication. I think the best way to go about it would be to remove it all before performing the change and then setting everything up again. Perhaps further reading might reveal I missed a step in order to properly set this up.
- Before you complete rendom you should make sure all client computers have rebooted at least twice. You can automate this process or you can do it manually but if you don’t perform this reboot they will not transfer to the new domain name and that will cause issues with those workstations.
- DHCP failover replication will stop working… well, at least it did for me. Disable all failover relationships and re-establish them once you have completed the renaming of the domain.
As you can observe unforeseen details are bound to surface so you should read all literature available and perform this on a lab environment first to observe if any line of business applications or server roles/features do not work and to identify if they can be addressed.
Fix Group Policy after a Domain Name Change
gpfixup /olddns:OldDomainDnsName /newdns:NewDomainDNSName /oldnb:OldDomainNetBIOSName /newnb:NewDomainNetBIOSName /dc:DcDnsName 2>&1 >gpfixup.log
Note: The command-line parameters
/newnb are required only if the NetBIOS name of the domain changed. Otherwise, you can omit these parameters from the command line for
To force replication of the Group Policy fix-up changes that are made at the domain controller that is named in
DcDNSName in step 3 of this procedure to the rest of the domain controllers in the renamed domain, type the following command, and then press ENTER:
repadmin /syncall /d /e /P /q DcDnsName NewDomainDN