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


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


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?

31 thoughts on “Renaming an Active Directory domain

  • 08/03/2020 at 16:30

    Thanks for this article.

  • 25/05/2016 at 22:22


    Thanks for posting this. A nicely comprehensive guide.

    A couple questions…I testing a single server as a domain controller for a small office. I also have one Windows 7 PC connected to the domain. I changed the domain name and all went well. However, when I login to the PC using a domain admin account, it appears that the domain admin account is not an local admin on the Win 7 PC. I thought this might have something to do with cached credentials. However, I created a new Domain Admin account, logged in to the PC. Same result. Any ideas?

    • 31/05/2016 at 08:04

      I guess the renaming didn’t go well :). I don’t know what to say here, because I don’t know what the problem might be. Try one more time and see how it goes.

  • 09/07/2015 at 20:27

    Adrian,can you explain what happens to the user profile on workstations. How are documents, photos and other data moved from the old domain name profile to the new domain name profile? I’m asking this because if I were to remove a workstation from the domain all data and settings would erased from the workstaion domain user profile.


    • 10/07/2015 at 07:19

      The documents are not removed from the workstations, they will stay there. I recommend you create a test lab and practice in the lab before going to production. No workstation needs to be removed from the domain, they will automatically change the domain they are part of, once the domain is renamed. I will say this again, DO NOT try this in a production environment only after you tested in a lab and you understand the procedure.

  • 23/06/2015 at 19:02

    Dear Admin,
    First, I would like to thank you for a great document. Second, I have followed the whole document and did the change smoothly.

    The question I need to ask is that I am able to login with the new domain with admin account ‘newdomain\administrator’ but the thing which is bothering me is I can still be login with “old_domain\administrator” with the same password on server itseld?? I have even deleted the old forward lookup zone but with no luck.

    Even If do RDC from any laptop or desktop, I can still be login with my other domain accounts which I have domain rights on.

    Kindly do let me know what option I am missing and where to get rid of my old domain totally from the edisting network.


    • 28/06/2015 at 13:43

      This happens because the domain and user credentials are cached on the machines. The cache period depends on how your domain policy is set-up. Just create a new user in the domain as a test and you will see that you can’t log in to the old domain using this new user. If you don’t want o wait, you can manually clear the cache on the clients but this involves modifying some keys in the registry; to much headache. The second thing you could do is to modify the policy in the domain, but is not worth it and this gives you option number three… just wait for the cache to clear automatically.

  • 22/02/2015 at 23:00

    Hey Adrian:
    I’ve recently done the domain rename process in my home network and appreciated this article. My domain consisted of a forest root and child domain, 2 DCs in each, 4 total. It took me 2 go’s to finally figure out what I was doing wrong. As you stated, most of the time it’s DNS related. I had to step away from it last night but it came to me almost immediately today when doing it.

    So, just a little background, the way that I setup DNS was using the “Decentralized with a Parent-Child Delegation” model. This means that during domain setup of the “”, you have to manually create a delegation in “” for “child”. This also likewise holds true for the domain rename process. Once you configure the domain list XML file and run the rendom /upload, the process does NOT create the “child” domain delegation in your new “” root. Here is how I would add in the steps from Adrian’s article to take into account for a parent-child domain configuration with Decentralized DNS:

    @Arian’s Step –
    “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”

    **NOTE: If you are renaming a domain with a child AND using Decentralized DNS configuration, now is a good time to create the “child” domain delegation in the new root DNS zone.
    1) In DNS Management, expand the Forward Lookup Zones on one of your root DCs.
    2) Right-click the new root DNS zone that you created above and select “New Delegation…”
    3) Click Next, then enter the NETBIOS name of your new child domain in the “Delegated domain” field and click Next.
    4) Add in the DCs for the child domain that are authoritative for the child DNS zone and click Finish
    5) You’ll now see the NETBIOS name for the domain inside the root DNS zone in a grayed out look as expected.
    6) And as Adrian says, WAIT for replication to push this delegation to the other root DCs.

    Without adding in the delegation it will prevent replication from ever completing and appear quite broken. The root DCs will be missing half of the reps and it can cause you to troubleshoot in circles for hours.

    I hope this helps others out there that have a multi-domain forest!

    • 23/02/2015 at 15:01

      Thanks for your comment, really appreciate it since I can’t cover every scenario in a single article.

  • 13/11/2014 at 05:23

    Just planning to rename my AD to from .local domain. However, we do have an enterprise CA on a member server. What other steps that we will have to do to with an Enterprise CA in the domain with regard to the domain rename procedure?

    Or is it better to rebuild the CA once the domain rename has completed?

    • 16/11/2014 at 14:25

      Re-building the CA will be way better, but this depends on your environment. If you have thousands of computers, this is not a great solution. Renaming a domain with a CA present is a complicated thing, and I quote ” Anyone who undertakes domain rename in an environment that uses certificates must have considerable expertise in managing Microsoft CAs.” This is not something that you can find in a single document and needs a lot of testing, especially if you never done this.


Leave a Reply

Your email address will not be published. Required fields are marked *