← All notes
Windows

Renaming an Active Directory domain in production: a practical case

A production-oriented Active Directory domain rename case using rendom and gpfixup, covering DNS, SYSVOL, GPOs, SPNs, certificates, NAS integration and post-migration validation.

Status: currentPublished: 2026-10-06Updated: 2026-10-06

Tested on: Windows Server 2022 · Active Directory Domain Services · DNS Server · Group Policy Management

Context

Renaming an existing Active Directory domain is an infrastructure migration, not merely a DNS change. The old namespace can remain embedded in GPOs, SYSVOL, DNS, SPNs, certificates, UNC paths, services and third-party systems.

This case covered the following production rename:

legacy.example.local
        ↓
ad.example.com

The FM2 NetBIOS name was retained. All IP addresses, endpoint/server names and internal GPO names in this article are anonymized.

Initial layout

Component Example
DC1 dc01.legacy.example.local / 10.20.30.10
DC2 dc02.legacy.example.local / 10.20.30.11
New namespace ad.example.com
NetBIOS FM2

1. Pre-flight

Active Directory should be healthy before a rename.

repadmin /replsummary
repadmin /showrepl *
dcdiag /e /c /v
dcdiag /test:dns /e /v
netdom query fsmo

Verify SYSVOL and NETLOGON:

net share

For DFSR-backed SYSVOL, the healthy state is State = 4.

System State backups of both DCs were created before the change. A hypervisor snapshot alone should not be treated as the recovery plan for this operation.

2. Domainlist.xml

rendom /list

Edit Domainlist.xml:

legacy.example.local → ad.example.com

Keep the NetBIOS name as FM2.

Validate:

rendom /showforest

3. Upload and prepare

rendom /upload
repadmin /replsummary
rendom /prepare

Every DC should reach Prepared.

4. Execute the rename

rendom /execute

After the controllers reboot, immediately re-check:

repadmin /replsummary
repadmin /showrepl *
dcdiag /e /c /v

In this environment, one DC temporarily experienced domain discovery and replication problems. Connectivity restoration, synchronization and KCC convergence returned the directory to a healthy state. Cleanup was therefore deliberately postponed.

5. Validate the new namespace

nltest /dsgetdc:ad.example.com /kdc /force
nslookup -type=SRV _ldap._tcp.dc._msdcs.ad.example.com
Resolve-DnsName dc01.ad.example.com
Resolve-DnsName dc02.ad.example.com

Documentation-only addressing:

dc01.ad.example.com → 10.20.30.10
dc02.ad.example.com → 10.20.30.11

6. Repair Group Policy references

gpfixup /olddns:legacy.example.local /newdns:ad.example.com /dc:dc01 /v

Check that gPCFileSysPath points to the new SYSVOL:

\\ad.example.com\SYSVOL\ad.example.com\Policies\{GUID}

On test clients:

gpupdate /force
gpresult /r
gpresult /h C:\Temp\gpresult.html

The migration also exposed an older security-filtering issue in one internal GPO. Its actual name is intentionally omitted.

7. Third-party systems

One internal management service still used:

security01.legacy.example.local

and had to be changed to:

security01.ad.example.com

A temporary GPO was used to update client configuration. Its real internal name is anonymized.

Before a rename, inventory:

8. Certificates

A domain rename does not reissue third-party certificates. Review Subject and SAN entries for internal services, RDP, LDAPS, reverse proxies and web interfaces.

Anonymized examples:

app01.legacy.example.local
terminal01.legacy.example.local
security01.legacy.example.local

9. NAS and ACLs

The file-storage system is anonymized as nas01.

After rejoining:

nas01.ad.example.com
NAS01$@AD.FONDMET.COM

Validation included machine trust, user/group resolution, SIDs, RID/idmap and existing SMB ACLs. Avoid changing idmap without a clear requirement because existing ACL mappings can break.

10. SPNs

Search for the old namespace:

setspn -Q */*.legacy.example.local

Inspect a specific account:

setspn -L COMPUTERNAME

Do not delete matches automatically. Identify the owning service first.

11. Cleanup

Keep the old namespace available during the transition while applications, certificates, tasks, scripts and UNC paths are audited.

After stabilization:

rendom /clean
rendom /end
repadmin /syncall /AdeP
repadmin /replsummary

Pre-flight checklist

[ ] repadmin /replsummary clean
[ ] dcdiag without critical errors
[ ] AD DNS healthy
[ ] SYSVOL/NETLOGON available
[ ] DFSR SYSVOL State = 4
[ ] FSMO role placement recorded
[ ] System State backup of both DCs
[ ] GPO inventory
[ ] search old FQDN in SYSVOL
[ ] SPN inventory
[ ] certificate audit
[ ] service accounts
[ ] scheduled tasks
[ ] Windows services
[ ] NAS/Samba
[ ] monitoring
[ ] backup
[ ] EDR/antivirus
[ ] LDAP/Kerberos applications

Post-flight checklist

[ ] Get-ADDomain / Get-ADForest
[ ] netdom query fsmo
[ ] repadmin /replsummary
[ ] repadmin /showrepl
[ ] dcdiag
[ ] DNS SRV records
[ ] nltest /dsgetdc
[ ] SYSVOL / NETLOGON
[ ] gpupdate / gpresult
[ ] gPCFileSysPath
[ ] SPNs
[ ] Kerberos
[ ] NAS
[ ] certificates
[ ] monitoring / backup
[ ] search for the old namespace

Takeaway

The core command sequence is short:

rendom /list
rendom /upload
rendom /prepare
rendom /execute
gpfixup
rendom /clean
rendom /end

The real migration is broader:

AD → DNS → replication → SYSVOL → GPO → clients
   → NAS → applications → certificates → SPNs

A domain rename is not complete when rendom /execute reports Done; it is complete when the infrastructure no longer has unintended dependencies on the old namespace.