How to Decommission an Old Domain Controller Safely

Retiring an old domain controller sounds like it should be simple — it’s getting replaced, so why not just shut it down? Because a DC is woven into far more than its own hardware. It may hold FSMO roles, serve as a Global Catalog, run DNS and DHCP, and be referenced in SRV records that clients across the domain rely on. Pull it offline carelessly and you leave a trail of orphaned metadata and stale records that cause logon delays and replication errors for weeks.

Done properly, decommissioning is methodical and low-drama. You confirm the domain is healthy, move every service and role the DC was carrying onto a healthy replacement, gracefully demote it so AD removes its own metadata, and tidy up DNS. The order matters, so this guide follows it end to end.

The decommissioning order at a glance#

flowchart TD
A["1. Pre-checks<br/>replication healthy?"] --> B["2. Move FSMO roles"]
B --> C["3. Move Global Catalog<br/>(if last GC in site)"]
C --> D["4. Move DNS & DHCP"]
D --> E["5. Graceful demotion<br/>removes metadata"]
E --> F["6. DNS cleanup<br/>stale records"]
E -.->|"if demotion fails"| G["Forced removal +<br/>manual metadata cleanup"]
G --> F

Step 1: Pre-checks#

Don’t start removing anything until the domain is healthy. Demoting a DC while replication is broken just spreads the mess.

Confirm replication is clean and find out exactly what the DC is responsible for:

# Replication health across the domain
repadmin /replsummary
repadmin /showrepl

# Which DC holds the FSMO roles
netdom query fsmo

# Is this DC a Global Catalog?
Get-ADDomainController -Identity "OLD-DC01" | Format-List Name, IsGlobalCatalog, OperationMasterRoles

While you’re here, take stock of everything else the box might be doing: DNS zones, a DHCP scope, a file share, a certificate authority, a print server, monitoring agents. A DC that’s been around for years often quietly accumulated extra duties.

Step 2: Move the FSMO roles#

If netdom query fsmo showed this DC holding any of the five roles, transfer them to a healthy DC before you go any further. A graceful demotion will try to relocate roles automatically, but it’s far better to move them deliberately so you control where they land.

# Transfer all five roles to the replacement DC
Move-ADDirectoryServerOperationMasterRole `
  -Identity "NEW-DC02" `
  -OperationMasterRole SchemaMaster, DomainNamingMaster, RIDMaster, PDCEmulator, InfrastructureMaster

Confirm with netdom query fsmo that the roles now live on the new DC. The full breakdown of each role and the transfer-vs-seize decision is covered in transferring or seizing FSMO roles.

Step 3: Move the Global Catalog (if needed)#

Check whether the DC is a Global Catalog and, more importantly, whether it’s the only GC in its site. If it is, make another DC in that site a GC before removing this one — otherwise logons and Exchange/Universal-group lookups in that site have to cross the WAN to find a GC, or fail.

You can add the GC role to another DC in the NTDS Settings properties in Active Directory Sites and Services, or with PowerShell:

# Make NEW-DC02 a Global Catalog
Set-ADObject -Identity (Get-ADDomainController -Identity "NEW-DC02").NTDSSettingsObjectDN `
  -Replace @{ options = 1 }

Give the new GC time to finish building (watch for event ID 1119 in the Directory Service log) before retiring the old one.

Step 4: Move DNS and DHCP#

A DC very often doubles as a DNS server and sometimes a DHCP server. Both need handling before the box goes away.

DNS. If your zones are AD-integrated (as they should be — see best DNS settings for domain controllers), the zone data already lives in AD and replicates to other DCs running DNS, so you won’t lose the zones. What you do need to fix is every client and DC that points at the old DC for DNS. Re-point them at a remaining DNS server before decommissioning.

DHCP. DHCP does not move automatically. If this server runs a DHCP scope, migrate it to another server first, or clients stop getting addresses when it’s gone. Export and import the configuration:

# On the old DHCP server — export all scopes
Export-DhcpServer -File "C:\dhcp-export.xml" -Leases

# Copy the file, then on the new DHCP server — import
Import-DhcpServer -File "C:\dhcp-export.xml" -BackupPath "C:\dhcp-backup" -Leases

# Authorize the new server in AD if it isn't already
Add-DhcpServerInDC -DnsName "NEW-DC02.corp.local"

Step 5: Gracefully demote the DC#

With roles and services moved off, demote the DC. This is the step that cleanly removes the DC from AD and deletes its own metadata — which is exactly why a graceful demotion is so much better than just deleting the machine.

On Server 2012 and later, the old dcpromo GUI is gone. Use Server Manager’s Remove Roles and Features wizard, or PowerShell:

# Gracefully demote this DC (run on the DC being retired)
Uninstall-ADDSDomainController -DemoteOperationMasterRole -Credential (Get-Credential)

The wizard removes AD DS, hands back the metadata, and turns the box into a normal domain-joined member server (or a standalone server if you tell it to). After it reboots, you can unjoin and shut it down.

Step 6: Metadata cleanup (only if demotion failed)#

If the DC died, was force-removed, or had its roles seized rather than transferred, its objects are still sitting in the directory. Leftover metadata causes other DCs to keep trying to replicate with a server that’s gone. Clean it up.

The modern, easy way: in Active Directory Users and Computers, expand Domain Controllers, right-click the dead DC’s computer object and delete it. Current versions of the console run the metadata cleanup for you and prompt to remove associated records.

The manual way with ntdsutil, still useful for stubborn cases:

ntdsutil
  metadata cleanup
    remove selected server <DC name or DN>
    quit
  quit

Also remove the dead DC from Active Directory Sites and Services (its server object under the site) if it’s still listed.

Step 7: DNS cleanup#

The last loose end is DNS. Even after demotion or metadata cleanup, stale records pointing at the old DC can linger and send clients chasing a dead server. Check the AD-integrated zones and the _msdcs zone and remove anything referencing the retired DC:

• The DC’s A (host) record in the forward lookup zone.
• Its PTR record in the reverse lookup zone.
• Its CNAME (<GUID>._msdcs.<domain>) in the _msdcs zone.
• SRV records under _msdcs, _sites, _tcp, and _udp that list the old DC as a Kerberos, LDAP, or Global Catalog server.
• Any Name Server (NS) entries on your zones that still name the old DC.

If you have aging and scavenging enabled, many of these clear on their own over time, but it’s worth removing the obvious ones immediately so nothing waits on a server that no longer answers.

Wrapping up#

Decommissioning a domain controller is really an exercise in moving things off it in the right order and then letting AD remove itself cleanly. Check replication health, relocate FSMO roles and the Global Catalog, migrate DNS pointers and DHCP scopes, then gracefully demote — which spares you manual metadata cleanup entirely. Reserve ntdsutil metadata cleanup for DCs that were lost without a proper demotion, and finish by scrubbing stale DNS records.

Skip these steps and the domain looks fine until the day it doesn’t. Follow them and the old DC slips out of the picture with nothing left chasing it. If you’re retiring a DC after a failure rather than a planned swap, read this alongside transferring or seizing FSMO roles and backing up and restoring Active Directory.