Warning: Domain Renames are Not Recommended (or Supported)

I have recently run into a couple of different scenarios wherein I’ve been asked to fix domain rename operations gone awry.  After having worked through this process extensively twice now, I thought I’d post about my experience, in case this helps anyone else avoid the same troubles.

To begin, you should know that in both cases, I was able to “right the ship” so to speak, and get the domains functioning properly again. However, you should also know that domain rename operations are not officially supported by Microsoft. Yes, I know–then why make it possible to begin with? Because it’s Microsoft.

The Directory Services support team flat out told me they do not support the operation during my first call with them, however, we were able to scope that first case to solving just one issue–I felt that if I could get this working, then we would probably reach resolution of the “failed” rename, because I knew that solving this problem would involve fixing name resolution as well as a host of other related issues. I was right.

Now before you go down the rename path, it is important to note two things in particular:

1. Domain rename is not compatible with Exchange 2007 or newer –I did not say “unsupported” here, I said not compatible (i.e. impossible).  In fact, a whole gaggle of Microsoft products do not react well to a rename operation:
   • System Center products like SCOM, SCCM, etc.
   • SharePoint
   • Office Communications Server/Lync Server, etc.
   • Microsoft ISA Server
   • Certificate Services / PKI should be removed in advance
   • Probably a few more
2. Again, it bears repeating: the operation is not supported. As in, if you do this, and run into issues, you might have a difficult time getting Microsoft to assist you in fixing it. Just because I was successful here does not mean that you will be.

But there are totally legitimate reasons someone may want to rename a domain, for example:

• Inheriting a Single Label Domain name (e.g. COMPANY vs. COMPANY.local)
• Acquisition
• Company name change
• Using a DNS name that exists in the real world, but that your organization does not own
• There are probably others

So then what is one to do in these circumstances? Easy. Just remember that you always have another option available to you: migration. This is a much simpler path to take in most cases, and certainly safer (fully supported).

The Active Directory Migration Toolkit is going to be of immense help if you need to stand up a new domain, in a new forest, and migrate objects across from one domain to the other. I will likely have an article on its use at some point here, but for now, you may refer to this guide.

About that first case

In case you are curious, the “one issue” I chose to focus on with Microsoft support was fixing an error that we would receive every time upon opening the Group Policy Management Console. I do not have the screenshot anymore, but it was basically saying the domain could not be found. At the same time, we saw that DCDIAG results failed on several tests, replication was broken, the event logs were full of various failures, and the BPA analyzers were spewing all kinds of errors. So, life was a mess for those domain controllers, basically.

Now in a rename procedure, one of the critical steps is to create a DNS zone for the new namespace. In this case, that step had been, regrettably, skipped. Fortunately, it was still possible to add this zone after the fact–just manually creating it on the primary domain controller, restarting the DNS service, and then re-registering the IP addresses for the domain controllers in DNS (ipconfig /registerdns) did the trick. Eventually replication began to work again, and the zone was replicated to the other DC’s.

Finally, it became evident that the missing DNS zone also caused some of the last steps in the rename procedure to fail, e.g. gpfixup commands.  So these also had to be re-run. Once both of those key pieces had been put into place, all the “normal” domain controller-related stuff started to function again.

The BPA analyzers were much improved, the DCDIAG came back clean (for the most part), name resolution was functional, and we could do simple things like create new administrator accounts and have them work successfully. Life was looking good.

In a very simple domain with nothing but a few file shares, maybe a web server or two, then getting AD/DNS functional again might be all that you need to do.  But don’t be surprised if you have a much longer way to travel before you get back to a good place, especially if there are other things present like Exchange Server.