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
_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