You're mid-way through an Active Directory migration, promoting a new domain controller, or forcing replication after a failed uninstall—and then it hits. The event log throws ERROR_DS_SUBREF_MUST_HAVE_PARENT (0X000020A4). The exact message: "The parent of a new subreference must exist." You see it in dcdiag or when running repadmin /syncall.
I've seen this most often after someone force-deletes a domain controller from AD Sites and Services without properly demoting it. Last month, a client had a server that died mid-demotion—restarted, forgot it was still a DC, and then they tried to add a new domain controller to replace it. Boom, 0X000020A4 started appearing on every replication attempt.
What's Actually Happening
Active Directory stores objects in a hierarchy. Under CN=Partitions,CN=Configuration, there are cross-reference objects (also called subreferences) that point to naming contexts—like your domain partition or the Configuration partition. When AD needs to add a new subreference to a parent container, it expects that parent container to already exist.
The error means AD is trying to create a subreference under a parent object that doesn't exist in the current copy of the directory. Usually this happens because the parent object was deleted (or never replicated) on the source DC that's pushing the change. The other DCs still have the subreference in their local copy, but the parent is missing—so replication keeps failing.
The root cause is almost always a lingering object—a remnant of a deleted DC or partition that wasn't cleaned properly. Replication tries to reconcile, hits the missing parent, and throws the error instead of just skipping it.
Fix It: Recreate the Parent or Clean Metadata
There are two paths depending on whether you need the parent object or want to purge it. Here's the practical workflow I use.
Step 1: Identify Which Parent Is Missing
Open ADSI Edit on a healthy DC (run adsiedit.msc). Connect to the Configuration partition. Navigate to:
CN=Partitions,CN=Configuration,DC=<yourdomain>,DC=<com>Look for any crossRef objects that have a nCName attribute pointing to a partition that doesn't exist. A common culprit is an old domain partition like DC=olddomain,DC=local. Also check under CN=Infrastructure for orphaned entries.
Step 2: If You Can Recreate the Parent
If the missing parent corresponds to a domain that still exists (you just haven't replicated it yet), force replication and see if it resolves:
repadmin /syncall /AdePIf that fails, use ntdsutil to do a metadata cleanup for the old DC— but only if that DC is permanently gone. On a healthy DC, run:
ntdsutil
metadata cleanup
remove selected server <name>Step 3: If You Need to Force-Delete the Orphaned Subreference
When the parent is truly gone (e.g., a deleted domain partition), you must remove the leftover subreference. This is delicate—back up the AD database first.
In ADSI Edit, locate the crossRef object with the missing parent. Right-click it, select Properties. Find the showInAdvancedViewOnly attribute and set it to TRUE—this exposes the object for deletion.
Then right-click the object and choose Delete. ADSI Edit will warn you—proceed. After deletion, run repadmin /syncall again. The error should stop.
Step 4: Clean Up DNS and Sites
After removing the orphan, delete any leftover DNS records for the dead DC and remove it from Sites and Services. Otherwise you'll chase the same error on the next replication cycle.
Still Failing?
If the error persists, you're probably dealing with a lingering object that normal cleanup won't touch. You'll need to use the Lingering Object Removal tool (repadmin /removelingeringobjects) on each DC that holds a copy:
repadmin /removelingeringobjects <DC> <partition> /advisory_modeRun it in advisory mode first to see what it would remove. If it lists the object that's causing your error, remove the /advisory_mode switch and run again.
I've also seen cases where a third-party AD cleanup tool (like Quest or Netwrix) did the job when ntdsutil was too stubborn. If you're out of options, that's worth a try.
One last thing—check your replication topology. If you have a DC that's been offline for months, its uptodateness vector might be stale. Force a full sync with repadmin /syncall /e after cleanup. That usually flushes it.
If nothing works, worst-case scenario: as a last resort, you can remove the offending DC from AD (metadata cleanup), then demolish its role with dism and reinstall it fresh. That's drastic, but it cleans everything. And honestly, sometimes that's faster than fighting a ghost.
Remember—0X000020A4 is a sign of a half-deleted object. Fix the deletion, and the replication will follow.