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.
Want content like this delivered right to your
email inbox?
Hi Adrian
I heave the TMG Enterprise enviroment.
All servers TMG are members of the domain.
What will be impact on TMG servers in a domain name change. ???
I want to add that we are enabled on the proxy end reverseproxy authorizations.
Hmm… never tested this kind of scenario, but I guess it will be like any other server. I will suggest you replicate this in a virtual environment and see what happens and how it goes. I will much appreciate it if you come back with the results and your findings.
Hi Adrian.
There are a number of important and vital details that you omit from you excellent example on Renaming an Active Directory domain.
Time-line for the procedure:
How long did it take you to complete the Renaming procedure from start to finish in a productive environment with two Domain Controllers, numerous servers and clients?
Can it be or should it be completed in one day or over a weekend in production environment or say over a four weeks with set steps to be completed each week preferably at weekends when the network is not busy or in use?
Dos and Don’ts:
Can you recommend any other checks and balances to help us check that the environment is ready at each step in the procedure before proceeding to the next step?
Physical versus Virtual Domain Controllers & the Domain Rename procedure:
With the advent of Hyper-V where now we have one physical and one or more virtual Domain Controllers in our production environments are there any changes required to the Domain Rename Procedure to accommodate these differences from when the Procedure was first designed for physical Domain Controllers and have you tested this in such an environment yourself?
As alway we all appreciate your response.
Regards
Hi,
Well… I can’t cover everything in just one article but long story short this is how I’ve done it in one of my environments and test labs:
I’ve done this in a school and it took me a week from start to end.
I will start with small steps and monitor and write down every move.
Before starting make sure most of all or even all errors from your domain controllers are gone. Check the Event Viewer. Also use the dcdiag command to see the health of the domain.
Your clients should all be good-to-go. No login, kerberos, profiles, GPO errors.
For an OS perspective it does not matter if is running in a virtual environment or a physical one.
Hope these helps.
Maybe some of the other visitors can share their experience.
Sadly I found this article to late and I managed to execute rendom /cleanup BEFROE rebooting the other servers in the domain. So, now the domain controller has:
Full computer name: server.olddomain.no
Domain: newdomain.no
And all the servers has
Full computer name: server.olddomain.no
Domain: olddomain.no
Any ideas how to fix this?
Ouch… Well… Try by just manually changing the DNS suffix see if it works, if not I think the best option for you is to just remove those servers from the old domain (delete the DNS suffix to because it might stick up) and join them to the new one. How many servers are we talking about ?
This guide was simply GREAT!!! Thank you so much for posting it.
I had a problem connecting my Mac users to AD due to .local domain name.
This fixed it perfectly
Glad it help you out :-).
Following these steps very closely a completely strange problem has arose. None of my privileges are working when I use my domain Administrator account. When I try to install a program on a domain computer and it asks me for administrator credentials it tells me “Access is denied.” Any ideas why?
Make sure the Administrator account is part of the Administrators group on the domain computer. Event tough it should be by default, but check it just in case.
Hi Adrian,
I followed your steps and i have problems with XP stations: the new domain does not appear in log on screen and i have to manually add them to my new domain. Can youe tell how to overcome this bug (i have 300+ XP station).
10x a lot
Hi,
This happened because you had no patience for the changes to replicate (if you have more than one domain controller), or because you did not rebooted the workstations at least two times, or you had and still have some DNS problems. Believe me 99% of the time is DNS. All that is left now is for you to manually add those workstations to the new domain (create a script for that its easier), because I can’t think of everything right now how to troubleshoot this.
Why didn’t you test this in a lab environment first ?
An update to the last post – I did find the _msdcs in the DNS, but it’s in the wrong place…
My forward lookup zone looks similar to:
_msdcs.sub.olddomain.com
subb.newdomain.com
|– _msdcs
in that _msdcs folder stored under subb.newdomain.com contains the dc, domains, gc, pdc entries. Some of the entries look different from what they should tho (like there are alias CNAMEs in the main _msdcs instead of the SOA and Nameserver entries.
I know there has to be a way to fix this, just not sure how…
I have the same type of problem that Pete had (in that my DNS on the DC’s still show the the old domain name. This is unfortunately, currently on a live domain that is now having problems, from the steps I had followed (after reading the steps on multiple websites) I thought the replication had finished but now I seem to have a problem with DNS – some of the ethernet connection indicators are showing local/internet, some are showing the old domain, etc. Is there a way I can fix this without having to tear down the entire domain and rebuild it?
There are two domains I ultimately have to migrate, this was the first one that is less critical but has more users in it so if I can fix it instead of tearing it down and rebuilding it, I’d be really happy.
Yes I know the old DNS zone is still present in the DNS console, but I will leave it alone and not delete it, not right now anyway. Depending on how big your network is you need to be sure that everything is replicated and working properly, then you can delete the old DNS zone. That’s why you are having problems, you did not wait for the replication to finish between the domain controllers, not rebooted the clients, or you had some domain problems before the renaming operation. Before I wrote this article, I heavily tested this, and found out that these are the exact steps that need to be followed, so you don’t get into trouble.
Hi Adrian,
What an excellent description of an otherwise daunting task. Thank you!
When I check DNS on my DCs I’ve still got the old forward lookup vkernel.local which appears can be safely deleted once everything is verified.
There is also a forward lookup _msdsc.vkernel.local which I only noticed after replicating these commands on the production setup rather than the testbeds.
Should the rendom commands have fixed this or is it necessary to go back a step and create a _msdsc.mynewdomain.local or have I missed/stuff-up something? (Everything seems to be working normally on day three).
Regards,
Pete
Hi,
The _msdsc.mynewdomain.local should be automatically created. I guess you did not wit for the replication to finish it’s job. I recommend you create another lab an test again. Cheers…
Hi Adrian,
Can you offer an hists for Domain Rename Procedure in a domain with one physical and one Hyper-V virtual DC.
The only issue I see have encountered is that the Virtual DC must be shutdown to allow the Hyper-V management server to twice reboot and that this has caused a failure with the netlogon service not registering the (A) and (AAAA) records for the Hyper-V management server with the new zone file while the Virtual DC was shutdown.
Any ideas on how to proceed in such a domain?
Hi,
Since domain controllers are rebooted first (not shut down as you stated), I don’t see the problem here. But if you say is not working, try to put as a preferred DNS server for the Hyper-V host the physical domain controller; since this is up and running when the Hyper-V host boots. See if that works and let me know.