Fix ERROR_DS_LOOP_DETECT 0X00002036 in AD

You'll see ERROR_DS_LOOP_DETECT (0X00002036) when you run repadmin /syncall or check the Directory Service event log (event ID 1988 or 2042 usually). It's almost always triggered after you've added a new domain controller (DC) and created site links that connect back to each other in a circle, or when a DC that was decommissioned still has lingering objects in the configuration partition. The Knowledge Consistency Checker (KCC) detects the loop and refuses to build replication connections.

Root Cause

Active Directory's replication topology uses a ring structure. If site links form a cycle (A→B→C→A), the KCC stops replicating on the offending edge. This prevents data corruption from multiple write conflicts. The real culprit is either a misconfigured site link cost or a DC that hasn't been properly removed—its NTDS Settings object still references a site link that doesn't exist anymore.

Fix Steps

Identify the loop. Open Command Prompt as admin and run:
```
repadmin /showrepl * /csv > repl.csv
```
Open the CSV and look for any destination DC showing Error: 0X00002036. That's the DC where the loop was detected.
Check site links in AD Sites and Services. Go to Sites → Inter-Site Transports → IP. Look for any site link that connects three or more sites in a triangle. For example, a link named DEFAULTIPSITELINK that includes SiteA, SiteB, and SiteC. If you see that, right-click each link and check the Sites in this link list. If any site appears in more than one link that's also connected to the other sites, you've got a loop.
Remove the duplicate or unnecessary site link. Delete the extra link or break it into two separate links. For example, if you have SiteA→SiteB and SiteB→SiteC and SiteC→SiteA, delete the SiteC→SiteA link. Adjust costs so the shortest path is clear. Standard rule: set cost based on bandwidth—lowest cost for fastest link.
Check for orphaned DC objects. Sometimes a decommissioned DC leaves its NTDS Settings behind. Run:
```
repadmin /options * +DISABLE_NTDSCONN_XLATE
```
to see all connection objects. Then open ADSI Edit, connect to the Configuration partition, and drill down to CN=Sites,CN=Configuration,DC=yourdomain,DC=com. Look for servers that no longer exist. Right-click and delete the NTDS Settings object under the dead server.
Force KCC recalculation. On the DC that reported the error, run:
```
repadmin /kcc
```
Wait 5 minutes, then run:
```
repadmin /syncall /AdeP
```
If it comes back clean, you're good.
Check event logs. Look for Directory Service event ID 1988. It gives you the exact source and destination DC involved in the loop. That saves you time hunting.

Still Failing?

If the error persists, you've probably got a DFSR or FRS issue alongside the loop. Run dcdiag /test:replications /v and look for failing tests. If you see an access denied error in addition to the loop, check that the Kerberos delegation between DCs isn't broken—reset the machine account password with netdom resetpwd /s:server /ud:domain\user /pd:*. Also verify that the time on all DCs is within 5 minutes of each other. Loops plus time skew equals a hard fail.

One more thing: if you're running a multi-domain forest and someone created cross-domain site links manually, delete those. The KCC handles trusts automatically. Don't create site links between domains unless you really know what you're doing.