STATUS_DS_CANT_ON_NON_LEAF (0XC00002AC) fix in Active Directory

What You're Seeing

You're trying to delete or rename an AD object — an OU, a group, or a user — and you get the error STATUS_DS_CANT_ON_NON_LEAF (0XC00002AC). The message says "The directory service can perform the requested operation only on a leaf object." Frustrating, but it's a one-minute fix once you know what's going on.

The culprit here is almost always a container that still has child objects. Active Directory won't let you delete or move a parent if its children are still attached. You need to clear them out first.

The Quick Fix

Step 1: Identify the offending object

Open Active Directory Users and Computers (ADUC). Navigate to the object that threw the error. Look for the plus sign (+) next to it — that means it has children.

Step 2: Remove all child objects

You've got three routes:

• Manual: Select each child, right-click, and delete or move it. Works for a handful of objects.
• PowerShell (fastest for bulk): Get-ADObject -Filter * -SearchBase "OU=ParentOU,DC=domain,DC=com" | Remove-ADObject -Recursive -Confirm:$false
• ADSI Edit: Connect to the partition, browse to the object, right-click and choose Delete but check the cascade delete option if available (some LDAP clients don't offer this by default).

Don't bother with manual delete in ADUC for containers with hundreds of nested OUs — it'll time out. Use the recursive PowerShell command above.

Step 3: Retry the operation

Once the children are gone, the parent object is now a leaf object. Delete or rename it. Done.

Pro tip: If you're renaming, not deleting, you can often rename a parent with children just fine — the error only blocks delete or move operations. So if the error pops up during a rename, check that you're not actually moving the object to a different OU.

Why It Works (the Short Version)

Active Directory uses a hierarchical tree structure. The LDAP protocol — the underlying language AD speaks — has a rule: you can't delete a container that still has children. This prevents orphaned objects and keeps the database consistent. The error code 0XC00002AC maps to STATUS_DS_CANT_ON_NON_LEAF, which is Windows telling you "I see kids under this object — deal with them first."

Once you remove the children, the object becomes a leaf (no descendants). Leaf objects can be deleted or moved freely.

Less Common Variations of This Issue

Sometimes the error isn't about visible children. Check these:

• Protected objects: If you're trying to delete a default container (like Users or Computers), AD blocks it even if empty. You'll need to use ADSI Edit and change the isCriticalSystemObject attribute to FALSE — but don't do that unless you're sure you need to break AD.
• Replication lag: If you just deleted children manually but still get the error, wait for replication to finish. Run repadmin /syncall /AdeP from a domain controller to force sync.
• Permission issues: The error can also show if your account doesn't have delete permission on the parent object but does on the children. Check delegation in ADUC.
• Third-party tools: Some backup or sync tools hold a handle on the object. Disable them temporarily and retry.

Prevention: Don't Let It Happen Again

Three things:

1. Plan your OU structure before you start creating objects. Once you have thousands of users under an OU, cleaning it out is a Sunday outage waiting to happen.
2. Use PowerShell scripts for bulk operations. The recursive flag in Remove-ADObject handles children automatically — but test on a non-production OU first.
3. Set permissions correctly from day one. If you delegate delete rights to a container, make sure the delegated group can also delete children. Otherwise they'll hit this error and call you at 2 AM.

That's it. Next time you see 0XC00002AC, you'll know exactly where to look.