0X00002015

Active Directory 0x00002015: Fix Non-Leaf Object Error

Server & Cloud Intermediate 👁 1 views 📅 May 27, 2026

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

  1. 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.
  2. 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.
  3. Use the dsmod command (the real fix). Open PowerShell as Administrator. Run:
    dsmod "OU=Sales-Temp,DC=contoso,DC=com" -subtree yes -delete
    This forces deletion of the container and everything inside it. Confirm the Y/N prompt. Done.
  4. Verify with repadmin. After deletion, run repadmin /showrepl to 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 ntdsutil to 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 dsquery to 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?