Fix AD Replication ERROR_DS_DRA_MISSING_PARENT 0X0000210C

Active Directory replication fails because the destination domain controller is missing a required parent object. The source DC tries to replicate an object whose parent doesn't exist.

What triggers this error

You see ERROR_DS_DRA_MISSING_PARENT (0X0000210C) during Active Directory replication. Typical scenario: a domain controller (say, DC-01) tries to replicate to another DC (DC-02), but the object it’s sending has a parent that doesn’t exist on DC-02. This happens most often after a failed object deletion or when an Organizational Unit (OU) or container is removed without properly cleaning up its children. I’ve seen it after restoring a single DC from backup without doing an authoritative restore — the restored DC has objects whose parent was never restored.

Root cause

Active Directory uses a hierarchical namespace. Every object (user, group, OU) has a distinguishedName like CN=JohnDoe,OU=Sales,DC=contoso,DC=com. The parent here is the OU=Sales container. If a replication update for JohnDoe arrives on DC-02, but OU=Sales doesn’t exist there yet (or got deleted), AD replication throws 0X0000210C. The source DC says “here’s an object”, but the target DC can’t place it because the parent container is missing. The real problem is almost always a lingering object — an object that was deleted on the source but the deletion never replicated to the target, or vice versa. When the object’s parent gets cleaned up on one DC but the child sticks around, replication breaks.

Fix: Remove the orphaned child object

The only clean fix is to delete the orphaned child object from the destination DC. Do not try to recreate the parent — that makes a mess. Here’s how, using repadmin.

Identify the stuck object. On the destination DC (the one reporting the error), run this in an elevated command prompt:
repadmin /showrepl * /csv > repl.csv
Then open repl.csv and look for lines with status “0x210c”. The failing source DC and partition will be listed.
Find the exact object. Run:
repadmin /syncall /AdeP
This lists objects that failed to replicate. Look for an object with a status of 0x210c. The DN (distinguished name) is what we need. Example: CN=JohnDoe,OU=Sales,DC=contoso,DC=com where OU=Sales is missing.
Check if the parent really is missing. On the destination DC, query the parent: dsquery * -filter "(name=Sales)". If nothing returns, the parent’s gone.
Delete the orphaned child object. Use ldp.exe or ntdsutil. I prefer ldp.exe because it’s more direct.
Open ldp.exe, connect to the destination DC, bind as an admin. Browse to the DN of the orphaned object (even if it’s not visible in the tree, you can type the DN in the “Browse” dialog). Select it, right-click → Delete. Confirm.
Force replication. After deletion, run:
repadmin /syncall /AdeP
Check for errors again. The 0x210c should resolve.

If repadmin doesn’t show the object

Sometimes the orphaned child is in the Deleted Objects container. Use this command on the destination DC to list all objects with missing parents:
repadmin /removelingeringobjects * "DC=contoso,DC=com" /advisory_mode
This scans the entire partition for lingering objects without deleting them. The output shows DNs of objects that are stuck. Replace /advisory_mode with nothing to delete them — but be careful. Make sure the object is genuinely orphaned. If the parent exists on other DCs, an authoritative restore might be safer.

Still failing? Check these

Replication topology. Run dcdiag /test:replications on both DCs. If there are other errors, fix them first — 0x210c often masks deeper issues like ERROR_DS_DRA_BAD_DN.
Time sync. AD replication relies on Kerberos. If the source and destination DCs are more than 5 minutes apart in system time, replication fails. Check with w32tm /query /status.
Lingering objects due to tombstone mismatch. If the DCs have different tombstone lifetimes (default 180 days in 2016+), you can get orphaned objects. Verify with repadmin /showattr . "CN=NTDS Settings,CN=YourDC,CN=Servers,CN=SiteName,CN=Sites,CN=Configuration,DC=contoso,DC=com" -atts:tombstonelifetime.
DNS. Make sure both DCs can resolve each other’s GUID-based CNAME records. Run nslookup -type=srv _ldap._tcp.dc._msdcs.contoso.com. If that fails, replication doesn’t even start.

If none of this works and the object is system-critical (like a built-in container), you might need to force an authoritative restore of the parent from a known good backup. That’s a last resort — it involves booting into Directory Services Restore Mode and using ntdsutil to mark the object as authoritative. Don’t go there unless you’ve tried everything.