AD Artifacts After Improper DC Decommission — Fix

Why This Happens

When a domain controller is removed from a network without running a proper demotion — powered off, deleted from the hypervisor, or just abandoned — Active Directory doesn't clean itself up. The DC's metadata stays in the directory indefinitely. The result is a collection of stale artifacts that cause real problems: replication errors, DNS failures, failed domain joins, and Netlogon warnings that never go away.

This runbook assumes the DC is gone and unrecoverable. If you still have the server, use the companion decommission runbook to do a clean demotion first.

Before you startRun these commands from a healthy DC — not a workstation. You need the AD RSAT tools and domain admin or enterprise admin rights.

Identify What Was Left Behind

# Find the dead DC — it will still appear in AD
Get-ADDomainController -Filter * | Select Name, Site, IsGlobalCatalog, OperationMasterRoles

# Also check for computer accounts that look like DCs but aren't responding
Get-ADComputer -Filter {PrimaryGroupID -eq 516} -Properties * |
  Select Name, DistinguishedName, LastLogonDate | Sort LastLogonDate

# Check which FSMO roles the dead DC held
netdom query fsmo

If the dead DC held any FSMO roles, you must seize them before doing anything else. See the FSMO migration runbook — seizing roles from a dead DC is covered in the final section.

NotePrimaryGroupID 516 = Domain Controllers group. Any computer account in that group that hasn't logged in recently is a candidate for cleanup.

Remove the DC Metadata

Metadata cleanup removes the dead DC's entry from the AD configuration partition. This is what tells the forest the DC no longer exists.

Remove via Active Directory Users and Computers (GUI)

Open ADUC → expand Domain Controllers OU → right-click the dead DC → Delete. Windows Server 2008 R2 and later runs metadata cleanup automatically when you delete a DC from this OU.

Remove via PowerShell (faster, scriptable)

# Remove the DC's computer account — this triggers metadata cleanup
Get-ADDomainController -Identity DEADDC01 | Remove-ADObject -Recursive -Confirm:$false

# If the above fails, target the computer account directly
Get-ADComputer -Identity DEADDC01 | Remove-ADObject -Recursive -Confirm:$false

Remove via NTDSUTIL (manual metadata cleanup — older OS fallback)

ntdsutil
metadata cleanup
connections
connect to server HEALTHYDC01
quit
select operation target
list domains
select domain 0
list sites
select site 0
list servers in site
select server [number of dead DC]
quit
remove selected server
quit
quit

Clean Up AD Sites and Services

Even after metadata cleanup, the dead DC often leaves behind entries in Sites and Services that must be removed manually.

# Open AD Sites and Services
dssite.msc

Navigate to: Sites → [Site Name] → Servers. Find the dead DC's server object. Expand it — you'll see an NTDS Settings child object. Delete NTDS Settings first, then delete the server object. Order matters — deleting the server object before NTDS Settings can fail.

# Alternatively via PowerShell
$configNC = (Get-ADRootDSE).configurationNamingContext
$deadDCDN = "CN=DEADDC01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,$configNC"
Get-ADObject -Identity "CN=NTDS Settings,$deadDCDN" | Remove-ADObject -Confirm:$false
Get-ADObject -Identity $deadDCDN | Remove-ADObject -Confirm:$false

Clean Up Stale DNS Records

A dead DC leaves behind A records, NS records, and SRV records in DNS. These cause clients to try reaching a DC that doesn't exist.

# On a healthy DC running DNS — list all records for the dead DC
Get-DnsServerResourceRecord -ZoneName "corp.local" |
  Where-Object {$_.RecordData -like "*DEADDC01*" -or $_.HostName -like "*DEADDC01*"} |
  Select HostName, RecordType, RecordData

# Remove the A record
Remove-DnsServerResourceRecord -ZoneName "corp.local" -Name "DEADDC01" -RRType A -Force

# Remove from _msdcs zone (critical — this is what clients use to find DCs)
Remove-DnsServerResourceRecord -ZoneName "_msdcs.corp.local" -Name "DEADDC01" -RRType A -Force

# Check for orphaned SRV records pointing to the dead DC
Get-DnsServerResourceRecord -ZoneName "corp.local" -RRType SRV |
  Where-Object {$_.RecordData.NameTarget -like "*DEADDC01*"} |
  Remove-DnsServerResourceRecord -Force

TipAfter removing DNS records, restart the Netlogon service on a healthy DC to re-register the correct SRV records: net stop netlogon && net start netlogon

Verify Replication is Clean

# Verify the dead DC no longer appears as a replication partner
repadmin /showrepl

# Check for replication errors referencing the dead DC
repadmin /replsummary

# Force replication to all remaining DCs to propagate the cleanup
repadmin /syncall /AdeP

The dead DC's name should not appear anywhere in the repadmin /showrepl output. If it still does, the Sites and Services cleanup in section 4 didn't complete — go back and verify the server object and NTDS Settings are both deleted.

Check for Lingering References

# Verify the DC no longer appears in the domain controllers OU
Get-ADDomainController -Filter * | Select Name, Site

# Check Kerberos KDC references
Get-ADObject -Filter {objectClass -eq "nTDSDSA"} -SearchBase (Get-ADRootDSE).configurationNamingContext |
  Select DistinguishedName

# Verify FSMO roles are all held by living DCs
Get-ADDomain | Select PDCEmulator, RIDMaster, InfrastructureMaster
Get-ADForest | Select SchemaMaster, DomainNamingMaster

Final checkRun dcdiag /test:Replications and dcdiag /test:FSMOCheck on a healthy DC. Both should pass cleanly. If FSMOCheck fails, a role is still assigned to the dead DC — seize it.

AD Artifacts Left After a Domain Controller Wasn't Properly Decommissioned