Fix ERROR_DS_DRA_SINK_DISABLED (0X00002109) in 3 Steps

What's happening here?

This error pops up when a domain controller tries to replicate to another DC, but the destination's NTDS Settings object is marked as disabled. That flag tells Active Directory to refuse any inbound replication requests. I've seen this after botched demotions, failed metadata cleanup, or when someone manually toggled the option in ADSI Edit.

The nasty part? You might not notice until a tombstone or password change stops flowing. The error text is blunt: "The destination server is currently rejecting replication requests." Your job is to flip the switch back on.

Here's the fix path, fastest to slowest. Stop when replication succeeds.

Quick fix (30 seconds): Restart the Active Directory Domain Services service

Sounds too simple, but I've seen this error appear after a service hiccup and a restart clears the stale state. On the destination server (the one getting the error), do this:

1. Open PowerShell as admin.
2. Run Restart-Service NTDS -Force.
3. Immediately try replication again from the source with repadmin /replsummary.

If the error goes away, you're done. If not, the NTDS Settings object is actually disabled, which the next step covers.

Moderate fix (5 minutes): Re-enable the NTDS Settings object

This is the real fix in most cases. The flag lives on the connection object's parent, the NTDS Settings object. You'll use ADSI Edit or PowerShell. I prefer PowerShell because it's faster and scriptable.

First, identify the destination DC's NTDS Settings object. The distinguished name follows the pattern CN=NTDS Settings,CN=,CN=Servers,CN=,CN=Sites,CN=Configuration,DC=,DC=. You can grab it with:

Get-ADObject -Filter {objectClass -eq "nTDSDSA"} -Property * | Where-Object {$_.Name -eq $env:COMPUTERNAME}

Look for the options attribute. A value of 1 means the object is disabled. A healthy value is 0.

To fix it, run:

Set-ADObject -Identity "CN=NTDS Settings,CN=YourDCName,CN=Servers,CN=YourSite,CN=Sites,CN=Configuration,DC=yourdomain,DC=com" -Replace @{options = 0}

If you can't use the AD module, ADSI Edit works too:

1. Open ADSI Edit, connect to the Configuration partition.
2. Drill to CN=Sites → CN=YourSite → CN=Servers → CN=YourDCName → CN=NTDS Settings.
3. Right-click → Properties. Find options. Set it to 0.
4. Click OK.

After changing it, wait a couple of minutes for the change to replicate, then force replication with:

repadmin /syncall /AdeP

Advanced fix (15+ minutes): Force metadata cleanup and manual replication

If re-enabling didn't work, the object might be genuinely orphaned — left over from a failed DC demotion. The NTDS Settings object still exists but has no corresponding server. In that case, you'll need to remove the ghost and let replication rebuild it.

Here's my go-to sequence:

1. Identify the offending DC with repadmin /showrepl and note the DSA object.
2. Use ADSI Edit to delete the NTDS Settings object for that DC. Right-click → Delete. Confirm.
3. Wait for replication to propagate the deletion (or force it with repadmin /syncall).
4. If the DC still exists physically, re-add it via Active Directory Sites and Services or let it recreate the object on next service start.

But sometimes the object is still there and the flag is stuck. Try setting options to 0 again after a forced replication. I've also seen cases where the enabledConnection attribute on connection objects matters. Check all connection objects under that NTDS Settings object — if they're disabled, enable them:

Get-ADObject -Filter {objectClass -eq "nTDSConnection"} -SearchBase "CN=NTDS Settings,CN=YourDCName,..." | ForEach-Object { Set-ADObject -Identity $_ -Replace @{enabledConnection = $true} }

Finally, if all else fails, restart the destination DC. That's the nuclear option, but it clears any lingering state in the KCC and forces a fresh view of the topology. Do that after verifying DNS and connectivity, because a restart won't fix a broken object.

When does this error actually happen?

I've debugged this on a Windows Server 2016 DC that failed demotion during a server migration. The old DC's NTDS Settings object stayed behind with options = 1, and every new DC trying to replicate in got the error. The same thing happens if someone mistakenly runs Set-ADObject -Replace @{options = 1} during maintenance. It's not common, but when it hits, it stops replication across the whole site.

Final thoughts

Start with the service restart, then check the options attribute, then go nuclear. In my years on the help desk, the middle step fixed 9 out of 10 cases. If you're in a rush, skip the restart and go straight to PowerShell — it's safe and takes under a minute.

Keep repadmin handy. repadmin /showrepl will show you the exact error and which DC is failing, so you're not guessing. Good luck.