AD can't retrieve child object? Here's the fix (0x20e6)

1. Replication conflict — the usual suspect

Nine times out of ten, this error means two domain controllers disagree about a child object's existence. One DC thinks it's there, the other doesn't. The conflict usually shows up after a failed replication attempt, often when you're running DCDIAG or REPADMIN.

Here's the quickest fix: force replication from a known good DC.

repadmin /syncall /AdeP

Run that on the DC giving you trouble. The /AdeP flag tells it to check for cross-site links and push changes aggressively. If you still see the error after that, check the replication queue:

repadmin /queue

If the queue is backed up with pending operations, clear it:

repadmin /syncall /A /d /e

This forces a full sync. Don't bother restarting the NetLogon or KDC services — that's a waste of time here. The culprit is almost always a stuck replication cycle.

When replication doesn't clear it

If syncing doesn't fix it, you've got a deeper issue. Look for the object DN in the event log. The error message usually includes the object path. Once you have it, check if it's a lingering object — a deleted object that another DC still references.

repadmin /removelingeringobjects DC=yourdomain,DC=com /advisory_mode

This scans for lingering objects without removing them. If it finds any, remove them:

repadmin /removelingeringobjects DC=yourdomain,DC=com

Do this on every writable DC in the domain. Lingering objects love to hide in GCs.

2. Sysvol or NTDS database corruption

If the replication fix didn't work, the database on that DC might be corrupted. You'll know because the error shows up consistently, not just during replication.

Run a database integrity check first:

ntdsutil
activate instance ntds
integrity

This scans for low-level corruption. It takes a while on large databases. If it reports any errors, you need a repair:

ntdsutil
activate instance ntds
files
recover

The recover command fixes minor corruption by replaying transaction logs. If that fails, you're looking at a restore from backup or a rebuild.

But before you go nuclear, check if the database is just too big. Anything over 20 GB on a Windows Server 2012R2 or older box starts causing performance issues. On Server 2019 or 2022, you can push to 40 GB, but I wouldn't. If your database is bloated, demote the DC and rebuild it with a clean database.

The snapshot trick

One thing I've seen work twice: take a snapshot of the DC's system state (if you're on virtual hardware), then do a non-authoritative restore of the AD database via Directory Services Restore Mode (DSRM).

ntdsutil
activate instance ntds
authoritative restore
restore subtree "DN=corrupted,DC=yourdomain,DC=com"

This forces that specific object to be treated as authoritative. Use it only if you're sure all other DCs have the correct version. Otherwise you'll replicate bad data everywhere — ask me how I know.

3. Tombstone lifetime mismatch between DCs

This one's sneaky. If you have DCs running different Windows Server versions (like 2008R2 and 2019), or if someone changed the tombstone lifetime manually, older DCs might think an object is still alive while newer ones have already deleted it.

Check the tombstone lifetime on every DC:

repadmin /showattr . "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=yourdomain,DC=com" -filter:"(objectClass=ntdsDSA)" -atts:tombstonelifetime

The default is 60 days for pre-2008R2 DCs, 180 days for anything newer. If you see a mismatch, standardize on the higher value:

repadmin /setattr . "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=yourdomain,DC=com" tombstonelifetime:180

Then wait for replication. This won't fix objects that already crossed the tombstone boundary — those need the lingering object removal from fix #1.

Quick-reference summary

Start with fix #1. It's the most common by a mile. If you still get the error after that, move to #2. And if you're mixing old and new DCs, jump straight to #3 first — it'll save you time.