ERROR_DS_COULDNT_IDENTIFY_OBJECTS_FOR_TREE_DELETE (0x2137) Fix

You right-click an OU in Active Directory Users and Computers, pick Delete, confirm the "are you sure" prompt, and instead of the tree vanishing you get a dialog that says Windows cannot delete the object because the directory service couldn't identify the objects for the tree delete. The error string is ERROR_DS_COULDNT_IDENTIFY_OBJECTS_FOR_TREE_DELETE and the hex code is 0X00002137. I've seen this most often on OUs that were recently moved between domains, OUs full of objects created by a script that ran against a decommissioned DC, and OUs where someone hardened the parent ACL and forgot the child objects inherit from a different path. It also shows up right after a replication stall — you delete from DC1 but the child objects only exist on DC2, and DC1 has no idea they're there.

What's actually going wrong

AD doesn't delete an OU in one shot. It walks the subtree, enumerates every child object (users, groups, computers, sub-OUs, contacts, whatever), and deletes each one before removing the OU itself. That enumeration step is where 0x2137 fires. The DC performing the delete can't "identify" one or more of the children — meaning it either can't see them, can't read their attributes, or the objects are in a state (phantom, lingering, orphaned) that makes the tree-walk bail out.

Three things cause this in practice:

1. Missing or broken permissions on a child object. You have delete rights on the OU but not on something buried inside it. The delete-allow ACE on the parent doesn't automatically grant delete on children unless inheritance is intact.
2. Replication lag or lingering objects. You're deleting against a DC that hasn't received the child objects yet, or has tombstones for objects that were reanimated elsewhere.
3. Orphaned objects left over from a failed script or a DC that died mid-write. These have a parent reference that points somewhere the DC can't resolve.

The good news: the directory database is almost never corrupt when you see this. It's a visibility or rights problem, and both are fixable.

The fix, in order

1. Confirm the DC you're deleting from has the full subtree

Run this against the domain controller you're connected to in ADUC (check the title bar — ADUC shows the DC in parentheses):

dsquery ou -name "YourOUName" -s dc01.domain.local
repadmin /showobj "CN=YourOUName,OU=Parent,DC=domain,DC=local" -s dc01.domain.local

If the object list looks short, or repadmin /replsummary shows replication failures, force a sync from a healthy partner before you touch the delete again:

repadmin /syncall dc01 /AdeP

Give it 5–10 minutes on a busy domain, then retry the deletion from ADUC. I'd say a third of the tickets I've worked on this error resolved here.

2. Check permissions on the OU and on its children

Open ADUC → View → Advanced Features. Right-click the OU → Properties → Security → Advanced. Look for one of these on the OU itself:

• Delete — allows deletion of the OU only
• Delete Subtree — allows deletion of the OU and everything underneath

You want Delete Subtree and you want it applied to This object and all descendant objects. If it's only on "This object", the child enumeration will fail with exactly this error.

Also click the Effective Access tab (Server 2016+ ADUC has it), pick your account, and confirm Delete Subtree is allowed on a child user object. If it's denied somewhere along the inheritance chain, that's your culprit. Fix the ACE on whichever object breaks inheritance — usually someone ticked "Disable inheritance" on a nested OU years ago and forgot.

3. Delete the subtree bottom-up

If the OU is small, this is honestly the fastest path. Expand the OU, delete every child OU and object first, then delete the parent OU. Tedious, but it works when the tree-walk is failing and you don't want to chase ACEs.

For big subtrees, script it. PowerShell with the AD module:

Import-Module ActiveDirectory
$ou = "OU=Target,DC=domain,DC=local"
Get-ADObject -SearchBase $ou -Filter * -SearchScope Subtree |
  Sort-Object -Property @{Expression={($_.DistinguishedName -split ',').Count}} -Descending |
  Remove-ADObject -Recursive -Confirm:$false

That -Recursive flag is doing the same tree delete ADUC tries, but through the AD Web Service (or the local DC via the module) and it surfaces a clearer error if one object blocks. Run it from a DC if you can.

4. If it's still stuck, use ntdsutil

Last resort before opening a case with Microsoft. From an elevated command prompt on a DC, in a maintenance window:

ntdsutil
activate instance ntds
metadata cleanup
connections
connect to server dc01.domain.local
quit
select operation target
list domains
select domain 0
list naming contexts
select naming context 0
list ou
select ou 3
quit
remove selected objects
quit
quit

Walk the menu carefully — list ou numbers the OUs and you'll pick by index. This does an authoritative remove at the DIT level and skips the normal tree-walk that's failing. It's not something to do casually, because if you pick the wrong index you'll delete the wrong OU. Double-check the DN the tool prints before you commit.

If it still fails after all that

Check these before you escalate:

• Tombstone lifetime. If lingering objects exist past the default 180 days (or whatever your forest set), replication refuses to delete them and the tree-walk sees phantoms. Run repadmin /removelingeringobjects against the affected DC to clean them out, then retry.
• FSMO holder down. The Infrastructure Master and PDC emulator both matter for cross-domain deletes. If either is offline, deletes across domains will fail with odd errors. Confirm both are reachable with netdom query fsmo.
• Protected objects. Objects with AdminSDHolder-protected ACLs (Domain Admins, Enterprise Admins, etc.) can't be deleted by the normal tree-walk if your account isn't a direct member. Either add the OU to the Protected Objects exceptions via dsacls, or delete those objects individually first.
• Recycle Bin disabled. If AD Recycle Bin is off and something in the subtree was already tombstoned, the enumeration may skip it inconsistently. Enable Recycle Bin if you haven't — it makes this class of error far more recoverable.

If you're still staring at 0x2137 after all of this, grab the DN of the OU, the exact DC you're connected to, and the output of repadmin /showobj for the OU, and open a case. Nine times out of ten the answer is a broken inheritance somewhere deep in the subtree, and once you find it the delete goes through on the first try.