Renaming an Active Directory domain

I know renaming an AD domain sounds bad, and it is in some cases, and that’s why you need to take time and think about what the domain name should be for the company. But mistakes happen, or you just have a bunch of clients that have bad domain names for their environment and need to be changed. Now, if their domain controllers are running 2003 server you are good-to-go, because starting with 2003, you can rename the domain name. If they don’t have 2003, well…upgrade, or create a new domain. If Microsoft Exchange is present in the infrastructure, your out of luck, because domain rename is not supported. It was in Exchange 2003, but starting with Exchange 2007 this option is gone. If you have an internal Certification Authority this will complicate things, so for the sake of this example I am not going to have one.

For this guide I have two domain controllers running Windows server 2008 R2, and two clients running Windows 7 and Windows XP that are joined to the domain “vkernel.local“. We are going to rename this domain from vkernel.local to mynewdomain.local. I know is not a great name, but this way you will know which is the old domain and which is the new one. The account used for this procedures needs to have enterprise permissions.

Just as an warning…before we move along, backup up your domain controllers just in case something goes wrong. One other thing; until you have completed all the procedures, discontinue the following activities:

• Creating new domains in or removing existing domains from your forest.
• Creating new application directory partitions in, or removing existing application directory partitions from, your forest.
• Adding domain controllers to or removing domain controllers from your forest.
• Creating or deleting shortcut trusts within your forest.
• Adding attributes to or removing attributes from the set of attributes that replicate to the global catalog (called the partial attribute set).

Now, let’s set up a control station from where we can manage all this. The control station needs to run a Windows server platform, and be a domain member. If you are running 2003 as the OS for the control station, you need to install the Windows Support Tools available on the 2003 media (support\tools folder) or download from here. If you are using 2008 R2 those tools are available as a feature.  Open Server Manager, right-click Features and check the box AD DS and AD LDS Tools on the Select Feature page. Click Add Required Features on the window that pops-up.

When done, reboot the server.

As you can see in the screens bellow my Windows clients are login in the vkernel.local domain, and is time to change that.

First task is to create a new DNS zone. Open the console, right-click the Forward Lookup Zone and choose New Zone.

On the Welcome page on the New Zone Wizard click Next.

We need to create an Active Directory Integrated Zone, so make sure the Primary zone radio button is selected and the box Store the zone in Active Directory is checked.

Choose how this zone will replicate in your environment then click Next to continue.

In the box, type the name of your new AD domain name then hit Next.

Leave the default option here since is the most secure one.

At the end click Finish to close the wizard.

The new zone is now created and displayed under the Forward Lookup Zone in the DNS console.

Before we move along with this I want to tell you one very important thing: always, I repeat, always let the replication finish its job, especially if the domain spreads across multiple sites. If not, the domain rename operation will fail and clients will not even be able to recognize the old domain. To verify everything is synchronized issue the following command:

repadmin /showrepl

If no errors are showing you can move to the next step.

Now is time to create a file, an XML file, that contains a description of the current forest structure and a list of all the domain partitions and application directory partitions in the forest. From the terminal issue the following command:

rendom /list

You might get the message The Behavior version of the Forest is 0. It must be 2 or greater to perform a domain rename: The server is unwilling to process the request. :8245. This pops-up when the forest is not running at minimum 2003 functional level. I did this on purpose so in case you encounter the same situation, you know why. If the forest is at 2003 level the command succeeds.

   

The file is generated in the root of the C drive of the control station with the name Domainlist.xml. Open the file using Notepad or any other text editor and replace all the instances of the old domain name with the new one.

Save the file and issue the bellow command to generate the domain name instructions and upload them to Active Directory. After issuing the command, I recommend you wait for the replication to finish because changes are made in DNS and AD after the file upload.

rendom /upload

To verify that all domain controllers are ready to continue with the domain rename procedure issue the command:

rendom /prepare

If you issued this command right after rendom /upload, you might get errors in the console, so wait a bit, then do the prepare and you should be fine. To be able to continue all DCs must be in a prepared state.

If everything is in order, the next step is to run the rendom /execute command so changes get executed. All domain controllers will reboot at the same time, so don’t panic if you see this happening, panic if you don’t see it.

During the rename procedure the forest configuration was in a freeze state, meaning no addition or removals of domains or domain controllers were allowed. Before the unfreeze command is executed reboot the control station twice so it will get the new domain. If you don’t reboot the control station you will get an error when trying to execute rendom /end.

Now, to unfreeze the forest configuration, issue the command rendom /end.

After the domain rename operations, some small tasks need to be done. Right now if you try to open the Group Policy Editor it can’t find a domain controller. If you look carefully, you can see that it tries to connect to the old domain.

To fix this open a terminal and issue the following commands:

gpfixup /olddns:vkernel.local /newdns:mynewdomain.local

then

gpfixup /oldnb:vkernel /newnb:mynewdomain

Now is time to reboot the member computers in the renamed domain twice, so they get the new domain name. In my test environment I didn’t even have to reboot the clients and the new domain name was already present at the log on-screen, but do that anyway.

After all clients were rebooted and they recognized the new domain name, is time to issue a command to clean-up the stale records in DNS and AD.

You have to be careful. The clean-up command needs to be issued after all member computers are rebooted, and not before, or they will not recognize the new domain name any more, and neither the old one.

rendom /cleanup

We are not done yet, because if you take a look at the FQDN of the domain controller(s) you will see the old domain name.

To fix this, two more commands need to be executed on the domain controller itself.

netdom computername server-dc.vkernel.local /add:server-dc.mynewdomain.local

and

netdom computername server-dc.vkernel.local /makeprimary:server-dc.mynewdomain.local

off course replace server-dc.vkernel.local and server-dc.mynewdomain.local with your FQDN of your domain controller. To take effect a reboot of the domain controller is needed.

After reboot, if you take a look at the FQDN of the domain controller(s), should be OK.