How to Rename a Domain in Windows Server 2019 (Change Your AD Domain Name)

To rename a domain in Windows Server 2019, run Microsoft’s rendom tool from a member server, then fix Group Policy with gpfixup and restart every member computer twice. A previous admin left an awkward name behind, and now the domain in Windows Server 2019 needs a rename. Or a merger left two forests behind. Or corp.local simply no longer fits. The tool for the job is Microsoft’s domain rename tool, rendom.exe.

• Check the prerequisites, back up every domain controller.
• Run rendom from the control station.
• Fix Group Policy with gpfixup.
• Restart every member computer twice.
• Clean up, then rename the domain controllers.

Two more tools work alongside it, gpfixup.exe and repadmin.exe. All three run from a member server that acts as the control station.

Changing a domain name in Windows Server makes experienced admins nervous. The nervousness is justified. Done carefully, though, it’s a predictable sequence of commands, and we walk through it from planning to cleanup.

Can it be done at all

It can. Microsoft supports the operation through rendom. The tool changes the DNS and NetBIOS names of one or more domains in a forest.

It’s a forest-wide change. Every domain controller restarts, and every member computer needs two restarts afterwards.

Your domain infrastructure is the backbone of everything: logons, file shares, printers, Group Policy, line-of-business apps. A rename touches all of it. That’s why the preparation takes far longer than the commands.

Admin hesitation comes from real risks.

• Authentication failures.
• Applications with hardcoded names.
• Users locked out when the restart rules get skipped.

Typical reasons for a rename:

• Mergers and acquisitions. The domain name still carries the old company brand.
• Rebranding. The internal name should match the new corporate identity.
• Better naming. A move from a single-label or .local name to a subdomain of a registered domain, such as ad.company.com.

When not to rename

Three situations speak against it.

• Exchange Server 2007 or later is installed in the forest.
• The forest functional level is below Windows Server 2003.
• Many applications store the domain name in their configuration.

In those cases a migration to a new domain with ADMT carries less risk. So does a trust between forests.

That last row deserves a closer look. Often what people really want is for users to log on with the new brand and see it in email addresses.

An alternative UPN suffix gives exactly that with zero risk. You add it in Active Directory Domains and Trusts. The internal DNS name stays the same.

Subdomains are another compromise. A new child domain keeps the existing structure intact.

No Exchange Server release from 2007 on supports a domain rename. That covers 2007, 2010, 2013, 2016 and 2019. If any of them is installed in the forest, we’d plan a cross-forest migration and leave rendom alone.

Preparing for the change

Preparation decides whether the rename takes one evening or one bad week.

Check the prerequisites

1. Confirm the forest functional level is Windows Server 2003 or higher. A Windows Server 2019 forest normally runs at the 2016 level.
2. Check replication health on every DC, and fix any errors before going further.
3. Pick a member server, not a DC, as the control station. Install the AD DS tools on it.
4. Create the DNS zone for the new domain name on your DNS servers. Set dynamic updates to Secure only. DCs register the new SRV records there.
5. Check for Exchange, for Certificate Services on a DC and for DFS namespaces. They need extra steps or block the rename.

Get-ADForest | Select ForestMode
repadmin /replsummary
dcdiag /v
Install-WindowsFeature RSAT-AD-Tools

Back up and inventory everything

Standard file backups aren’t enough.

• Take a system state backup of every domain controller.
• Export the DNS zones.
• Back up all Group Policy Objects, password policies in Windows Server 2019 included.

Backup-GPO -All -Path C:\GPOBackup

Store the backups somewhere that stays reachable even if the domain doesn’t. Our guide to Windows Server Backup covers system state jobs step by step.

Then build an inventory of what authenticates against the domain. A simple table works.

Finally, plan communication. Tell users when the change happens and who to call. What they must do is usually just restart twice.

Remote laptops that are offline during the window are the classic problem. They won’t get the change and may need to rejoin the domain later.

Go or no-go before the change window

• Replication is clean on every DC.
• System state backups exist, and one restore was rehearsed.
• The new DNS zone accepts secure dynamic updates.
• The lab run finished with no open errors.
• Users know the date and the two-restart rule.
• Offline and VPN-only devices are on a list.
• Someone with Enterprise Admins rights is on call for the evening.

How to rename a domain in Windows Server 2019 with rendom

Run every command from the control station, in an elevated Command Prompt, signed in as a member of Enterprise Admins. The order matters. Skip a step, and the forest can end up partly renamed.

1. Generate the forest description. It lands in Domainlist.xml in the current folder, with the current DNS and NetBIOS name of every domain.
2. Edit the description. Open Domainlist.xml in Notepad and change the DNSname and NetBiosName values of the domain you’re renaming. Leave the GUIDs untouched and save the file.
3. Review the result and check that the new names are what you expect.
4. Upload the instructions. This freezes the forest configuration, and it creates Dclist.xml, which tracks the state of each DC.
5. Force replication from the domain naming master, so every DC receives the instructions.
6. Check DNS readiness. The new zone must exist, and DCs must be able to register records in it.
7. Prepare. Every DC must report Prepared in Dclist.xml. Fix any that show an error and run the step again.
8. Execute. Each DC applies the change and restarts automatically.
9. Unfreeze the forest once every DC reports Done.

rendom /list
rendom /showforest
rendom /upload
repadmin /syncall /d /e /P /q DomainNamingMaster
rendom /prepare
rendom /execute
rendom /end

Keep Domainlist.xml and Dclist.xml in the same folder on the control station for the whole operation. A DC shows Error in Dclist.xml after execute? Check its connectivity and run the execute step again. DCs that already finished are skipped.

After the domain rename in Windows Server 2019

The order here matters as much as before. Group Policy first, then the member restarts. Cleanup and the DC renames come last.

Fix Group Policy

Group Policy links still point to the old domain name. Run gpfixup on the control station, once for each renamed domain. Then force replication and review the log for errors.

gpfixup /olddns:old.local /newdns:new.local /oldnb:OLD /newnb:NEW /dc:dc01.new.local 2>&1 >gpfixup.log
repadmin /syncall /d /e /P /q dc01.new.local

Restart member computers twice

Every member server and workstation must restart twice. The first restart lets the computer learn the new domain name. The second updates its own records.

That includes the primary DNS suffix, when the setting “Change primary DNS suffix when domain membership changes” is on.

Computers that miss this rule frequently show one message: “The trust relationship between this workstation and the primary domain failed”.

Clean up and rename the domain controllers

1. Remove the old domain names from Active Directory with the clean step. Do this only after every member computer has restarted twice.
2. Rename each DC with netdom. Add the new name, make it primary, restart, then remove the old one.
3. Recreate external trusts to other forests. They don’t survive the rename.
4. Check DNS: SRV records under the new zone, delegations, and conditional forwarders on partner networks.

Update services, certificates and applications

DNS records need more than new A records. Check the service principal names of your service accounts too. Missing or stale SPNs show up as odd Kerberos failures.

setspn -L

• Applications that store the domain name in config files, connection strings or the registry need manual changes.
• Certificates issued to the old DNS name no longer validate. Reissue them.
• Email routing, spam filtering and directory synchronization with cloud services usually need updating.

Audit security policies as well. Rarely does a GPO list the domain name explicitly. Logon scripts, drive mappings, folder redirection paths and DFS links frequently do. Those break quietly.

Is migrating safer than a Windows Server 2019 domain rename

For large or complex forests, generally yes. It’s also the only supported route when Exchange is present.

You build a new forest with the right name. A trust connects the two. Then users, groups and computers move in stages with the Active Directory Migration Tool, ADMT. SID history is kept, so access to resources keeps working.

The migration takes longer. It gives you control and an easy rollback, because the old domain keeps running until the last object has moved.

1. Deploy a new forest and domain with the target name, at the functional level you’d like to end up with.
2. Create a two-way forest trust between the old and the new forest. Confirm name resolution in both directions.
3. Install ADMT on a member server in the new domain and configure SID history migration.
4. Migrate groups first, then users, then computers.
5. Translate security on servers and user profiles, so permissions and profile data follow the accounts.
6. Move servers last, one service at a time. Retire the old domain once nothing authenticates there.

Users move with SID history. Passwords can come along through the Password Export Server, if needed.

Computer accounts need the most attention. Each machine must join the new domain, and that takes a restart and local admin rights.

ADMT handles workstations in batches. Servers that host critical services typically get an individual plan.

The join itself is in our guide to joining Windows Server to a domain. For the account side, see managing users in Windows Server 2019.

Fixing problems after a Windows Server 2019 domain rename

Most problems come from five sources.

• Members that didn’t restart twice.
• Stale Kerberos tickets.
• Outdated SPNs.
• Broken replication.
• Applications that still use the old name.

If something goes badly wrong, the last resort is a forest recovery. It uses the system state backups you took before the upload step.

Practising that restore in the lab is the best insurance you can buy. DSRM access is part of it, and we explain that in our article on booting Windows Server 2019 in safe mode.

How long it takes

The commands take a few hours of hands-on work, with a short outage while the domain controllers restart. The full project often spans several weeks.

A migration with ADMT usually runs for weeks to months.

That plan fits a small to medium organization.

Success doesn’t come from avoiding every problem. It comes from expecting them. Admins who rehearse the run and keep the runbook in front of them tend to finish without drama.

Leave time for the stragglers too. Laptops that were switched off during the change window are the usual ones.

Newer Windows Server versions

The rendom procedure is identical on newer Windows Server releases. So if the change is part of a bigger refresh, you can run it on newer domain controllers.

Planning a refresh anyway? It’s a good moment to raise the forest functional level and move DCs to a newer version. Windows Server 2025 Standard, say.

Need a key? Our Windows Server 2019 Standard key comes as a genuine license. We email it instantly after payment.

Terms used on this page

What a Windows Server 2019 domain rename can and can’t change

Rendom does more than swap a name. It can also reshape the domain trees inside one forest. Its limits matter just as much.

The requirements fit on one card.

• Rights. Enterprise Admins for every step.
• Control station. A member server, never a domain controller.
• Forest functional level. Windows Server 2003 or higher. A Windows 2000 native forest fails.
• Exchange. Not installed on any domain controller, and no Exchange 2007 or later anywhere in the forest.
• Domain-based DFS namespaces. Root servers on a supported Windows version, which every current server is.

And a lab run first. Two domains at least, Microsoft says. Why two? One domain hides the trust and replication steps, and those are where a real forest trips.

The reference for all of this is Microsoft’s archived introduction to Active Directory domain rename. Same steps on Windows Server 2019.

Versions this domain rename guide covers

Microsoft’s archived domain rename procedure is still the reference for the order of steps.