How to Rename an Active Directory Domain

50.7K

In this post, we will rename an existing contoso.com domain with AD controllers to theitbros.com (the process is supported on Windows Server 2019/2022/2025 DCs).

Do You Really Need to Rename the AD Domain?

Before planning an AD domain rename, you need to determine if the AD domain name actually needs to change. Note that in many environments a company rebrand does not require changing the AD domain at all. In case the goal is to change users’ sign-in names, you can usually add a new UPN suffix and assign it to user accounts without renaming the AD domain. For example, users can sign in as user@newcompany.com while the underlying AD domain remains unchanged.

In case the goal is to change email addresses or the organization’s email branding, you can update the Microsoft 365/Exchange Online domain config and users’ SMTP addresses instead of renaming the AD domain.

For mergers and acquisitions (M&A), consolidating organizations into a new Active Directory forest is often a more appropriate method than renaming an existing production domain. A forest migration allows you to redesign the target identity structure and migrate users, computers, groups, apps, and other dependencies in a controlled manner.

AD domain rename should therefore be considered only when changing the actual AD DNS/NetBIOS domain name is a confirmed requirement and all apps and infrastructure components in the forest support the operation.

Preparation for an AD Domain Rename

Before you proceed to change your domain name, check the basic requirements:

• Forest functional level: AD domain rename requires a forest functional level of Windows Server 2003 or higher. This is a legacy minimum requirement; you should not treat Windows Server 2003 and 2008 functional levels as modern deployment targets. In current environments, you should check the forest and domain functional levels and use the highest functional level supported by all DCs. In case the forest contains Windows Server 2025 DCs, the domain and forest functional levels must be at least Windows Server 2016;
• If Active Directory Certificate Services (AD CS) is deployed in your environment, you need to prepare your certification authorities before the domain rename operation. You should review certificate templates, auto enrollment settings, CRL Distribution Points (CDP), and Authority Information Access (AIA) paths to ensure that certificates and certificate validation continue working after the rename. Don’t forget to pay special attention to certificates used for NPS, VPN, Wi-Fi authentication, smart cards, and internal apps. Additionally, take a look at Microsoft’s guidance for preparing certification authorities for domain rename.
• After the domain rename, you should review certificates that contain the old domain name in the Subject/Subject Alternative Name (SAN) fields. Certificates issued for servers, services, and devices may need to be reissued if they reference the previous domain name. You need to pay special attention to certificates used by Web servers and internal HTTPS apps, LDAPS connections, NPS/RADIUS authentication, VPN services, Wi-Fi authentication (802.1X) and enterprise apps and service accounts.
  You need to review certificate templates and check if automatic certificate enrollment will issue updated certificates with the new domain names after the rename operation.
• AD domain rename is not supported in an Active Directory forest that contains on-premises Exchange Server. In case your environment uses Exchange Server, including a hybrid Exchange deployment, do not use rendom to rename the existing AD domain. The supported method is to build a new AD forest/domain and migrate Exchange, users, computers, and other resources to the new environment. Note that simply removing/decommissioning Exchange does not turn the existing forest into a supported domain-rename case;
• You should review all Microsoft and third-party apps that rely on AD before performing a domain rename. Some apps may store the old domain name, LDAP paths, service accounts, or Service Principal Names (SPNs) in their config. You must verify vendor support for Active Directory domain renaming before proceeding;
• You should review AD trusts and SIDHistory dependencies before performing a domain rename. Don’t forget to check all external, forest, and shortcut trusts to ensure that authentication continues working after the rename. If SIDHistory is used for migration scenarios, you need to check if that migrated users and groups retain the required access to resources. You can review existing domain trusts with the command nltest /domain_trusts or netdom trust contoso.com /Domain:partner.local /Verify (don’t forget to replace contoso.com and partner.local with the actual domain names involved in the trust relationship).
• In case your environment uses Microsoft Entra Connect (Azure AD Connect), Microsoft Entra hybrid join, Intune, or other cloud identity services, you should review your hybrid identity config before performing the domain rename.
  

  You should check the following components:- Microsoft Entra Connect sync rules and sync status;
  – User Principal Name (UPN) suffix config;
  – Microsoft Entra hybrid join device registration status;
  – Intune device enrollment and compliance policies;
  – Conditional Access policies that depend on users, groups, or device identities;
  – Authentication dependencies such as SSO, certificates, and enterprise apps. A domain rename can affect user sign-in names, device registration, and cloud identity sync. You should plan and validate the hybrid identity config before and after the rename operation. To review current user UPNs, use the following PowerShell command:

  Get-ADUser -Filter * -Properties UserPrincipalName | Select-Object Name, UserPrincipalName

• You need to create a primary DNS zone for the new domain name in your AD;
• If your DFS namespaces, redirected folders, roaming user profiles, etc. are implemented in your infrastructure, gather all the relevant info for them and schedule a migration immediately after the domain name change.

Important. In hybrid identity environments, an AD domain rename can affect Microsoft Entra ID sync and device registration. Before proceeding, you need to review your Microsoft Entra Connect config and check that user sign-in names (UPNs) match the required cloud identity config.

Note. Be sure to backup your AD before you start renaming your domain.

Verify Active Directory Health Before Domain Rename

Before starting the AD domain rename operation, you need to make sure that your environment is healthy. Any existing replication, DNS, or DC issues should be resolved before running the rendom tool.

Note that the domain rename operation requires appropriate forest-wide admin privileges. You need to use an account with Enterprise Admins membership in order to perform the forest-level rename operation. In case you have a multi-domain forest, you need to also ensure that the required admin permissions are available in each affected domain for the corresponding DC and post-rename tasks.

Check FSMO Role Holders

First, you need to check the current FSMO role owners and make sure that all roles are available:

netdom query fsmo

Make sure that the Domain Naming Master role holder is online and accessible, as this role is required during the domain rename process.

Check Active Directory Replication Health

Now check if all DCs can successfully replicate AD changes:

repadmin /replsummary

For a more detailed replication status report, run the following command:

repadmin /showrepl

You need to resolve any replication errors before continuing. A domain rename operation should not be performed in an environment with existing replication failures.

Run Domain Controller Diagnostics

Now run a complete Active Directory health check:

dcdiag /e /v

After that review the output and make sure that there are no critical errors related to:

• AD services;
• Kerberos authentication;
• SYSVOL;
• Netlogon;
• replication;
• DC availability.
• Verify DNS config

Because AD relies heavily on DNS, you need to check if all DCs have a healthy DNS config:

dcdiag /test:dns

Fix any DNS-related issues before proceeding with the domain rename. Keep in mind that incorrect DNS config can prevent DCs and domain-joined machines from locating the renamed domain.

After completing these checks and confirming that AD is healthy, you can proceed with creating the DNS zone for the new domain name.

Create a Primary DNS Zone for the New Domain

The first step is to create a primary DNS zone for the new domain on your DNS server:

Check for Existing DNS Namespace Conflicts

Before creating a new AD-integrated DNS zone, you need to check if the new domain name does not conflict with an existing public DNS namespace.

For example, if the new AD domain name is:

theitbros.com

you need to check whether this namespace is already used for:

• Public website hosting;
• Microsoft 365 services;
• Exchange Online or Autodiscover records;
• SPF, DKIM, and DMARC records;
• Other external services.

If the same DNS namespace is already used externally, you need to plan a split-brain DNS (split DNS) config. In this case, internal Active Directory DNS servers host the internal zone, while external DNS providers continue to manage public DNS records.

Before creating the new DNS zone, don’t forget to review existing public DNS records and make sure that required external services will continue working after the domain rename.

1. Connect to DC and open the DNS Manager console (dnsmgmt.msc);
2. Expand the Forward Lookup Zones node;
3. Select New zone;
   

   

4. Create a new primary AD-integrated zone called theitbros.com with enabled Allow only secure dynamic updates option. Wait for the new zone to replicate all the DNS servers in the forest.
   

   

Renaming AD Domain Using RenDom Tool

In order to change the AD domain name, you must use the rendom console tool, which is available on any domain controller. The C:\Windows\System32\rendom.exe command allows you to perform all the necessary actions for a domain renaming operation.

Generate and Edit the Domainlist.xml Configuration File

Sign-in to the DC and open the command prompt as an administrator.

Run the following command to generate an XML file containing your domain configuration:

rendom /list

After generating the Domainlist.xml file, you need to create a backup copy of this file before making any changes. This file contains the domain rename config and may be required for troubleshooting/rollback planning.

Open the Domainlist.xml with notepad:

notepad Domainlist.xml

Open the Domainlist.xml file and carefully update the domain naming attributes. Do not perform a global Find and Replace operation in the XML file. Modify only the required domain name values:

• DNSName — replace the old DNS domain name with the new domain name.
• NetBiosName — update the NetBIOS domain name if required.

You should avoid changing other XML elements/identifiers, as they contain internal AD config data required for the rename operation.

Save the changes to the Domainlist.xml file.

Verify the new configuration (command makes no changes yet):

rendom /showforest

Upload the New Domain Configuration

Upload a new configuration file to the DC running the Domain Naming Operations Master FSMO role:

rendom /upload

Wait for the file containing the domain renaming instructions to be replicated to all other domain controllers in the forest.

Now check if AD replication is healthy and that all DCs have received the updated config:

repadmin /showrepl

Note that you must resolve any replication errors before continuing with the domain rename operation. All DCs must be able to successfully replicate changes before running rendom /prepare.

You can force the sync of changes made on the Domain Naming Master to all DCs. Use the command below:

repadmin.exe /syncall /d /e /P /q DomainNamingMaster_DC_HostName

This command forces replication of the domain rename config to the other DCs.

Important. After the forest is frozen by the rendom process, you need to avoid making any structural changes to AD until the domain rename operation is completed. During this period, do not:

• Add or remove DCs;
• Create/remove domain trusts;
• Perform schema updates;
• Make major AD config changes.

Complete the domain rename operation within a planned maintenance window and unfreeze the forest only after all required steps have been successfully completed.

Prepare and Execute the Domain Rename

Check if the domain is ready to accept changes (checks the availability of all DCs):

rendom /prepare

If this command returns no errors, you can run the rename operation:

rendom /execute

The rendom /execute command initiates the rename operation and restarts DCs as required.

Important. You should run the domain rename operation during a planned maintenance window. Before executing the command, make sure you have:

• A tested Active Directory System State backup of DCs;
• Console/out-of-band access to DCs;
• A documented recovery plan in case the operation fails.

You should avoid performing a domain rename when a DC is the only authentication server in a site, as a failed rename operation/unexpected outage can affect user authentication and access to domain resources.

You should plan staged reboot of clients and servers for the changes to take effect. The first reboot allows domain members to update their domain info. The second reboot helps register updated DNS records and apply the new domain config.

Now your users can log on to computers using their old usernames and passwords.

Post-Rename Configuration and Cleanup

After the domain rename operation, you need to update the fully qualified domain names (FQDNs) of DCs. The domain rename process does not automatically change the hostnames of DCs to match the new DNS domain name.

Use the following command to rename each DC:

netdom computername DC01.contoso.com /add:DC01.theitbros.com

netdom computername DC01.contoso.com /makeprimary:DC01.theitbros.com

Reboot the domain controller to apply the changes.

After restarting the DC, you should verify that the new FQDN has been applied correctly and that the expected Service Principal Names (SPNs) are registered. To check the current FQDN, run the following command:

[System.Net.Dns]::GetHostEntry($env:COMPUTERNAME).HostName

The command should return the new FQDN, for example:

DC01.theitbros.com

Now check the registered SPNs for the DC:

setspn -L DC01

You need to make sure that the SPN entries reference the new domain name and that there are no duplicate/missing SPNs. Note that incorrect SPN registration can cause Kerberos authentication failures after a domain rename.

Update Group Policy Objects (gpfixup)

Now you need to rebind the Group Policy Objects to the new domain name:

gpfixup /olddns:contoso.com /newdns:theitbros.com

Then run the command to fix the NetBIOS name of the domain in the GPOs:

gpfixup /oldnb:CONTOSO /newnb:THEITBROS

After updating Group Policy references, review other AD-dependent services that may contain the old domain name. Keep in mind that the domain rename operation does not automatically update all UNC paths, service configs, or app settings.

Update DFS Namespace Paths

If DFS Namespaces are used, you need to review namespace paths and folder targets that reference the old domain name. For example, update references such as:

\\contoso.com\Public

to:

\\theitbros.com\Public

You should verify DFS Namespace config and folder targets after the rename operation.

Update Folder Redirection and Roaming Profiles

If Folder Redirection/Roaming User Profiles are configured through Group Policy, you need to review the configured paths. You should check for old domain references in paths such as:

\\contoso.com\Users\%username%

and update them to the new namespace if required.

Clean Up and Unfreeze the Forest

Remove links to the old domain:

rendom /clean

You can now complete the domain rename and unfreeze the AD forest:

rendom /end

Make sure that the rename was successful. Check if all Active Directory domain controllers can be contacted, users can sign in to the new domain; check if applications work correctly, and check AD replication and errors on DCs. If your environment uses AD trusts or SIDHistory, you need to validate authentication between trusted domains and verify that users can still access required resources.

Now change paths in DFS namespaces, roaming profiles, redirected folders, etc. if used.