This means all the other sites think that this domain controller has been removed, but this local sites think the "removed " domains which has failed is still valid and cannot be override with a site link connection, so have have an isolated site with no replication occurring which sounds like a recipe for disaster.
Imagine your company has offices across multiple cities, with your main IT infrastructure in New York and your PDC Emulator located in London. Your New York site has two domain controllers:
- NYC-DC01: Primary domain controller for the New York office
- NYC-DC02: Secondary domain controller for redundancy
Everything's running smoothly until disaster strikes. NYC-DC02 suffers a catastrophic hardware failure and goes completely offline. You quickly perform metadata cleanup from your PDC Emulator in London to remove the dead server from Active Directory.
Problem solved, right?
Wrong.
When Everything Goes Sideways
Here's where things get messy. You successfully cleaned up NYC-DC02's metadata from London, but NYC-DC01 doesn't know its partner is dead.
Before the failure, your replication topology in New York looked like this:
- NYC-DC01 ↔ NYC-DC02 (bidirectional intrasite replication)
After you removed NYC-DC02 from London, the cleanup happened in the global catalog, but NYC-DC01 is still living in the past:
- It's still trying to replicate TO the dead NYC-DC02
- It expects to receive replication FROM NYC-DC02
- Its connection objects are still pointing to a server that no longer exists
The Replication Death Spiral
This creates a localized but critical failure within the New York site:
- Stale Information: NYC-DC01 stops receiving updates from its local partner
- Authentication Delays: Users may experience slower authentication as NYC-DC01 struggles with failed replication attempts
- Inconsistent Data: Any changes made locally don't replicate properly within the site
- Resource Waste: The server continuously tries to contact a dead partner, consuming CPU and network resources
- Monitoring Alerts: Your replication monitoring tools start screaming about failures
The worst part? Running repadmin /kcc on NYC-DC01 doesn't fix it because the connection objects are corrupted and still pointing to the dead server.
The Diagnostic Commands That Reveal the Mess
When you run repadmin /showrepl NYC-DC01, you see the problem:
Base DN: CN=New York,CN=Sites,CN=Configuration,DC=bear,DC=local
==== KCC CONNECTION OBJECTS ============================================
Connection --
Connection name: ce958954-6a17-407c-995b-785c04fb1fbf
Server DNS name: NYC-DC01.bear.local
Server DN name: CN=NTDS Settings,CN=NYC-DC01,CN=Servers,CN=New York,CN=Sites...
Source: New York\NYC-DC02
******* 15 CONSECUTIVE FAILURES since 2025-07-01 14:30:15
Last error: 1256 (0x4e8):
The remote system is not available. For information about network troubleshooting, see Windows Help.
TransportType: intrasite RPC
ReplicatesNC: DC=bear,DC=local
ReplicatesNC: CN=Configuration,DC=bear,DC=local
ReplicatesNC: CN=Schema,CN=Configuration,DC=bear,DC=local
Translation: NYC-DC01 is desperately trying to replicate with a server that no longer exists, failing every few minutes.
Execute : Recovery Plan
Even though you cleaned up the metadata from London (the PDC Emulator), you need to also run the cleanup locally from the surviving server in New York. Each domain controller maintains its own view of the directory, and local cleanup ensures the surviving DC gets the message.
Phase 1: Local Metadata Cleanup
Run metadata cleanup from the surviving NYC server:
ntdsutil
metadata cleanup
connections
connect to server NYC-DC01
quit
select operation target
list sites
select site 0 (New York site)
list servers in site
select server NYC-DC02
remove selected server
quit
quit
Phase 2: Remove Broken Connection Objects
Check current connections:
repadmin /showconn NYC-DC01
If you still see connections to the dead server, remove them:
repadmin /delete CN=NTDS Settings,CN=NYC-DC01,CN=Servers,CN=New York,CN=Sites,CN=Configuration,DC=bear,DC=local CN=NTDS Settings,CN=NYC-DC02,CN=Servers,CN=New York,CN=Sites,CN=Configuration,DC=bear,DC=local
Phase 3: Rebuild Replication Topology
Force the Knowledge Consistency Checker to rebuild:
repadmin /kcc NYC-DC01
Force immediate replication with other sites:
repadmin /syncall NYC-DC01 /AeD
Verify replication health:
repadmin /replsummary
repadmin /showrepl NYC-DC01
The Key Lessons
- Metadata cleanup from a remote site (like London) updates the global directory but doesn't immediately fix local connection objects
- Connection objects are sticky - they don't automatically disappear when a server is removed
- Local directory views can become inconsistent with the global view
The Critical Mistake
I would appear that sometimes people think that cleaning up metadata from the PDC Emulator is sufficient. It's not. You must also run cleanup from the surviving domain controllers that were directly replicating with the dead server, or in this case perform it again on the orphaned server.
Conclusion
Removing a domain controller is a two-step process:
- Global cleanup from the PDC Emulator (what you did from London)
- Local cleanup from surviving DCs that were replicating with the dead server
Don't let a dead server continue to haunt your Active Directory environment. Clean up locally, rebuild the connections, and restore proper replication flow.