Active Directory 0x00002015: Fix Non-Leaf Object Error
You tried to move or delete an AD object that has children. Quick fix: delete child objects first or use dsmod with the right flags.
Quick Answer
Run dsmod <DN> -subtree yes -delete on the offending object, or manually delete all child objects using ADSI Edit.
What's Actually Happening
You're trying to delete or rename an Active Directory container (like an OU, a container, or a domain partition object) that still has child objects inside it. AD won't let you because it's not a leaf object — it's a branch. This isn't a bug; it's protection against accidentally wiping out a whole organizational unit and all its users, computers, and groups in one shot.
I saw this last week with a client who tried to delete an old OU called "Sales-Temp" from 2015. Two hundred orphaned computer accounts were still buried in it. AD said nope.
Steps to Fix It
- Identify the exact object. Write down its distinguished name (DN). Example:
OU=Sales-Temp,DC=contoso,DC=com. You can get this from AD Users and Computers by enabling "Advanced Features" and looking at the object's attribute editor. - Delete child objects first. Open ADSI Edit (part of Remote Server Administration Tools). Connect to the partition containing the object, navigate to it, then go through each child object — delete them one by one. For hundreds of objects, this sucks. Skip to step 3.
- Use the dsmod command (the real fix). Open PowerShell as Administrator. Run:
This forces deletion of the container and everything inside it. Confirm the Y/N prompt. Done.dsmod "OU=Sales-Temp,DC=contoso,DC=com" -subtree yes -delete - Verify with repadmin. After deletion, run
repadmin /showreplto check replication hasn't failed on other domain controllers. If you see lingering objects, do a metadata cleanup.
Alternative Fixes If the Main One Fails
Sometimes dsmod won't work because of replication conflicts or orphaned objects. Here's what else to try:
- ADSI Edit again: Right-click the container, choose "Delete", then check "Delete subtree". If it's greyed out, the object has protected ACLs — take ownership first.
- NTDSUTIL metadata cleanup: If the object is orphaned (shows up but doesn't exist on any DC), use
ntdsutilto remove it from the directory. Connect to the problem DC, select the object, and remove it. - Check if it's a system container: Some containers like Builtin or LostAndFound can't be deleted. You'll get this error if you tried — stop, you don't need to delete those.
Prevention Tips
- Never create nested OUs without a cleanup plan. If you use temporary OUs for project groups, schedule a script to delete them after a year.
- Use
dsqueryto find empty containers regularly. Example:dsquery * OU=Test,DC=contoso,DC=com -scope base -attr name | find /i "count=0". - Train your junior admins: always check for child objects before deleting anything.
Pro tip: If you're managing a domain with 10,000+ objects, write a PowerShell script that recursively deletes OUs older than 90 days. Saved a client 4 hours of manual clicking last month.
Was this solution helpful?