Fix Active Directory replication error 0x00002101 (DS_DRA_REF_NOT_FOUND)

Error 0x00002101 - what's really going on

You're running repadmin /replsum or repadmin /syncall on a domain controller and you see 0x00002101 with the message "The replication reference information for the target server does not exist". I've seen this a dozen times since Windows Server 2012. The error basically means: one domain controller tried to replicate with another, but the destination DC isn't listed in the source DC's replication topology. It's like trying to call someone whose number you don't have.

If you ignore this, replication breaks silent. That means password changes won't sync, group policies won't update, and users get locked out randomly. Not fun.

Cause #1: The target DC is offline or dead and its metadata is stale

Most common cause. A domain controller got decommissioned wrong, or it just died and nobody cleaned up its metadata. AD still thinks that DC exists and tries to replicate to it. The error shows up on the remaining healthy DCs.

How to check for it

Open Active Directory Sites and Services (dssite.msc). Expand Sites, then your site, then Servers. Look for a server that's grayed out or shows an error icon. In the right pane, check the NTDS Settings object – if it shows a broken arrow, that's your stale DC.

The fix

You need to remove the dead DC's metadata manually. Don't use ADSI Edit on a whim – use the official command:

ntdsutil.exe
metadata cleanup
connections
connect to server LivingDC.contoso.com
quit
select operation target
list domains
select domain 0 (or the domain number that matches)
list servers for site Default-First-Site-Name
select server 1 (the dead DC's number)
quit
remove selected server
quit
quit

Replace LivingDC.contoso.com with a healthy DC's FQDN. I lost track of how many times this fix saved a client's butt. Had a client last month whose entire print queue died because their old DC's metadata was still active – took me 10 minutes to clean it up.

After removal, run repadmin /syncall /AdeP on all remaining DCs. Should be clean. If error persists, move to cause #2.

Cause #2: DNS records point to a non-existent DC

Second most common. AD relies on DNS to find other DCs. If a dead DC's SRV records (especially _ldap._tcp. or _kerberos._tcp.) still linger in DNS, replication tries to contact that IP and fails.

How to find it

On a healthy DC, open DNS Manager (dnsmgmt.msc). Expand Forward Lookup Zones > > _msdcs > dc > _tcp. Look for SRV records pointing to a server that's now gone. You can also use the command line:

nslookup -type=srv _ldap._tcp.

If it lists a dead hostname, bingo.

Fix: delete stale DNS records

Right-click the bad record in DNS Manager and delete it. Then run ipconfig /registerdns on all healthy DCs to refresh their records. After that, force replication:

repadmin /syncall /AdeP

Important: if you're using a split DNS or conditional forwarders, check those too. Had a client where the forwarder pointed to a dead DC – took forever to trace.

Cause #3: Lingering objects on a destination DC

Third cause. A DC has an object (like a user or computer) that doesn't exist in the source DC's directory. This happens if a DC was offline for a long time and missed tombstones. The source DC tries to replicate and can't find the parent reference. Less common on modern Windows Server 2016+ due to strict replication consistency checks, but still happens.

How to check

Use repadmin /showobjmeta * across all DCs. If one DC shows version numbers way older than others, it's a candidate. Or run repadmin /removelingeringobjects * /advisory_mode to list lingering objects without deleting them. I usually run this first:

repadmin /removelingeringobjects * /advisory_mode /objectserver:SourceDC.contoso.com

Replace SourceDC with a healthy DC. It'll tell you what's lingering.

Fix: remove lingering objects

Once you confirmed, run the actual removal:

repadmin /removelingeringobjects DestinationDC.contoso.com  /objectserver:SourceDC.contoso.com

For example, if a user account on a remote DC is lingering:

repadmin /removelingeringobjects RemoteDC.contoso.com "CN=JohnDoe,OU=Users,DC=contoso,DC=com" /objectserver:HealthyDC.contoso.com

If there are many objects, do it for the whole naming context with /gc flag – but I'd only do that if you're sure. I had a server where a bulk removal fixed replication but broke some user logins. So careful.

Quick-Reference Summary Table

If you still see 0x00002101 after trying all three, check firewall rules between DCs (port 135, 389, 636, 445, 49152-65535 for Windows Server 2012+). But honestly, in my experience, it's always one of the above three. Start with metadata cleanup – it's the quickest win.