Home Runbooks DC Decommission Companion: Cleaning Up What dcpromo Leaves Behind
Troubleshooting FREE

DC Decommission Companion: Cleaning Up What dcpromo Leaves Behind

Even a clean demotion leaves DNS records, SRV entries, Sites and Services objects, and replication links that persist until you remove them manually. This is the cleanup guide for after the demotion completes.

⌛ 9 min read· Updated 2026

What a Clean Demotion Still Leaves Behind

Running dcpromo or the PowerShell demotion cmdlet does a lot of the right things — it demotes the server, triggers metadata cleanup, and removes the NTDS Settings object. But it consistently misses several things that will cause noise in your environment for months if you don't clean them up manually.

This guide is the companion to the DC decommission checklist. Run it after the demotion completes and the server has rebooted as a member server.

DNS Cleanup

Even after a clean demotion, the former DC's DNS records often persist. The server's own DNS client may have re-registered them before you had a chance to clean up.

# List all DNS records for the decommissioned DC
$dcName = "OLDDC01"
$zone = "corp.local"

Get-DnsServerResourceRecord -ZoneName $zone |
  Where-Object {$_.HostName -eq $dcName -or $_.RecordData.IPv4Address -eq "10.0.0.20"} |
  Select HostName, RecordType, RecordData

# Remove the A record from the forward lookup zone
Remove-DnsServerResourceRecord -ZoneName $zone -Name $dcName -RRType A -Force

# Remove from the _msdcs zone
Remove-DnsServerResourceRecord -ZoneName "_msdcs.$zone" -Name $dcName -RRType A -Force -ErrorAction SilentlyContinue

# Remove from reverse lookup zone
$reverseZone = "0.0.10.in-addr.arpa"
Get-DnsServerResourceRecord -ZoneName $reverseZone -RRType PTR |
  Where-Object {$_.RecordData.PtrDomainName -like "*$dcName*"} |
  Remove-DnsServerResourceRecord -Force
NoteCheck for the record in both the forward zone and the _msdcs zone. The _msdcs zone is what clients and other DCs use to locate domain controllers — stale entries there cause ongoing authentication noise.
# After removing records, force remaining DCs to re-register theirs
# Run on each surviving DC
ipconfig /registerdns
net stop netlogon && net start netlogon

SRV Record Cleanup

SRV records in _msdcs, _ldap._tcp, _kerberos._tcp, and related zones sometimes outlive the DC. Check for them explicitly:

# Find SRV records pointing to the old DC
Get-DnsServerResourceRecord -ZoneName $zone -RRType SRV |
  Where-Object {$_.RecordData.NameTarget -like "*OLDDC01*"} |
  Select HostName, RecordData

# Remove any found
Get-DnsServerResourceRecord -ZoneName $zone -RRType SRV |
  Where-Object {$_.RecordData.NameTarget -like "*OLDDC01*"} |
  Remove-DnsServerResourceRecord -Force

Sites and Services Verification

The demotion usually removes the NTDS Settings object, but the server container in Sites and Services sometimes survives. Verify it's gone:

# Check if the server object still exists in Sites and Services
$configNC = (Get-ADRootDSE).configurationNamingContext
Get-ADObject -Filter {objectClass -eq "server"} -SearchBase "CN=Sites,$configNC" |
  Where-Object {$_.Name -like "*OLDDC01*"} |
  Select DistinguishedName

If anything is returned, remove it manually. Delete the NTDS Settings child object first, then the server object:

$serverDN = "CN=OLDDC01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,$configNC"
Remove-ADObject -Identity "CN=NTDS Settings,$serverDN" -Confirm:$false -ErrorAction SilentlyContinue
Remove-ADObject -Identity $serverDN -Confirm:$false

Replication Link Cleanup

After demotion and metadata cleanup, replication links to the dead DC should be gone. But in large environments with manual connection objects, they occasionally persist:

# Check for lingering connection objects referencing the old DC
Get-ADObject -Filter {objectClass -eq "nTDSConnection"} `
  -SearchBase (Get-ADRootDSE).configurationNamingContext -Properties fromServer |
  Where-Object {$_.fromServer -like "*OLDDC01*"} |
  Select DistinguishedName, fromServer

If any are returned, delete them:

Get-ADObject -Filter {objectClass -eq "nTDSConnection"} `
  -SearchBase (Get-ADRootDSE).configurationNamingContext -Properties fromServer |
  Where-Object {$_.fromServer -like "*OLDDC01*"} |
  Remove-ADObject -Confirm:$false

Group Policy Cleanup

Check if any GPOs reference the old DC explicitly — some environments use GPO preferences or logon scripts that hardcode DC names.

# Search all GPO reports for the old DC name
Import-Module GroupPolicy
Get-GPO -All | ForEach-Object {
  $report = Get-GPOReport -Guid $_.Id -ReportType Xml
  if ($report -like "*OLDDC01*") {
    Write-Output "Found in GPO: $($_.DisplayName) ($($_.Id))"
  }
}

Also check Group Policy's PDC Emulator reliance — if GPO processing is slow after the demotion, verify the PDC Emulator role was successfully transferred and is advertising correctly:

netdom query fsmo | findstr /i "PDC"
nltest /dsgetdc:corp.local /pdc

Final Verification

# Full health check across all remaining DCs
dcdiag /test:Replications /e
dcdiag /test:FSMOCheck /e
dcdiag /test:DNS /e

# Replication summary — should show no errors and no reference to old DC
repadmin /replsummary

# Confirm no more references to old DC anywhere in replication topology
repadmin /showrepl | findstr /i "OLDDC01"
# Should return nothing
You're done whendcdiag passes all tests, repadmin /replsummary shows 0 failures, and the old DC name appears nowhere in repadmin /showrepl output. Any remaining references at that point are cosmetic and will age out via AD scavenging.