Active Directory Replication Fails: ERROR_DS_DRA_SOURCE_DISABLED (0x2108)

1. The NTDS Settings Object Is Disabled

This is what hits you 9 times out of 10. The source domain controller's NTDS Settings object under its server object in AD Sites and Services has been marked as disabled. That stops the Knowledge Consistency Checker (KCC) from generating replication topology for that server—so replication never starts.

How does it get disabled? Usually an admin clicks the wrong checkbox in the GUI, or a script that demotes a DC leaves the object in a disabled state instead of removing it cleanly. I've seen it happen when someone runs ntdsutil metadata cleanup but doesn't finish the job—the object stays but the isDisabled attribute gets set to TRUE.

Here's how to check and fix it:

1. Open Active Directory Sites and Services.
2. Expand the site containing the source DC, then Servers, then the server name.
3. Right-click NTDS Settings and pick Properties.
4. If Disable the NTDS Settings object is checked, uncheck it. Click OK.

That re-enables the object. Wait a few minutes (or run repadmin /syncall /AeD) and replication should start. If the checkbox is greyed out or doesn't exist, the object's disabled attribute is set directly via LDAP—you'll need adsiedit.msc to fix it:

Open ADSI Edit, connect to the Configuration partition.
Navigate to: CN=NTDS Settings,CN=ServerName,CN=Servers,CN=SiteName,CN=Sites,CN=Configuration,DC=domain,DC=com
Right-click the NTDS Settings object, Properties.
Find msDS-EnabledFeature — if it's set to a GUID that refers to a disabled state, clear it.
Or directly check the attribute options — value 1 means disabled. Set to 0.

Set the options attribute to 0 and you're back in business.

2. Stuck Disabled State From an Incomplete Demotion

This one's trickier. The NTDS Settings object looks fine in the GUI, but the DC itself was partially demoted—someone ran dcpromo and cancelled halfway, or the metadata cleanup left a disabled replica. What's actually happening here is the source DC's own NTDS Settings object on itself is disabled, but the remote DC trying to replicate from it sees the disabled flag and refuses.

You'll see this after a server rename or an IP change that confused the AD topology. The KCC marks the source as unreachable, then disables the object automatically—self-preservation. The fix is to run repadmin /options to check for disabled replication:

repadmin /options <SourceDC>

Look for DISABLE_NTDSCONN_XLATE or DISABLE_OUTBOUND_REPL in the output. If either is set, the source is blocking outbound replication. To clear them:

repadmin /options <SourceDC> -DISABLE_NTDSCONN_XLATE
repadmin /options <SourceDC> -DISABLE_OUTBOUND_REPL

After that, force a KCC recalculation and try again:

repadmin /kcc
repadmin /syncall /AeP

The KCC will rebuild the connection objects, and replication should flow again. If the demotion was truly a mess, you might need to clean the metadata manually with ntdsutil — remove the server metadata, then re-add the DC properly.

3. Lingering Database Flags (drsEnabledFlag or dsServiceFlags)

This is the rarest cause, but I've hit it on a Windows Server 2016 DC that had been restored from a bad backup. The msDS-isGC flags were fine, but the msDS-ReplAttributeMetaData showed the source as drsDisabled. The error code 0x2108 appears in the event log under source NTDS Replication, event 1925 or 2042.

What's actually happening here is the AD database (ntds.dit) has a persistent flag in the system state that marks the source DC as disabled at the database level, not just the object level. The object in AD says enabled, but the on-disk flag says disabled. The replication engine checks both, and the db flag wins.

To find this, run repadmin with the showrepl verb and look for the source DC's GUID:

repadmin /showrepl * /csv | findstr 0x2108

If the source shows Last failure status: 0x2108 but the NTDS Settings object is enabled, you're in this bucket. The only reliable fix I know is to demote the source DC cleanly, remove its metadata, and re-promote it. Yes, it's heavy. But the database flag won't clear with a GUI toggle or an LDAP attribute change—it's baked into the DIT's replication metadata.

If you can't demote (single DC domain), you can try forcing the KCC to rebuild the connection with a new invocation ID:

repadmin /rehost <SourceDC> <NamingContext> <DestDC>

But I've seen cases where that still fails. The honest fix: backup, demote, clean metadata, promote again. Test in a lab first.