Active Directory tree delete fails with 0X00002170

1. The object is protected from accidental deletion

This is the one I see most often, and it's the easiest to overlook. Some AD objects — especially privileged ones like Domain Admins, Enterprise Admins, or built-in security groups — have the protect from accidental deletion flag checked. When you try a tree delete on an OU that contains one of these, you'll hit 0X00002170 immediately. The system won't let you nuke a protected object, even as part of a larger delete.

I had a client last month trying to clean up a test domain. They built a whole OU structure under a root called "LegacyApps," and buried deep inside was a group they'd copied from Domain Admins. Tree delete failed every time until we found it. The fix is straightforward.

How to fix it

1. Open Active Directory Users and Computers (dsa.msc).
2. Turn on Advanced Features from the View menu.
3. Find the object that's blocking the delete — usually a group, user, or computer that's been marked protected. You might need to check each object in the subtree.
4. Right-click the object, go to Properties, then the Object tab.
5. Uncheck Protect object from accidental deletion.
6. Apply, OK, then retry your tree delete.

If you've got a lot of objects, use PowerShell to find them fast:

Get-ADObject -Filter 'ProtectedFromAccidentalDeletion -eq $true' -SearchBase "OU=LegacyApps,DC=domain,DC=com" | Select-Object Name, DistinguishedName

This lists every protected object in that subtree. Unprotect them all, then the tree delete should work.

2. nTSecurityDescriptor blocks deletion on system objects

Even after you unprotect accidental deletion, some objects have a second layer of defense: the nTSecurityDescriptor attribute explicitly denies delete permissions to SYSTEM or administrators. This is common for objects like the Builtin container, Domain Controllers OU, or any object that's part of the adminSDHolder process. The error code is the same: 0X00002170.

This happened in a lab I was cleaning last week — a weirdly orphaned computer object under the Domain Controllers OU that a junior admin had dragged there by mistake. Tree delete on the parent OU failed, but a targeted delete on the computer object alone worked fine.

How to fix it

Don't try to change the security descriptor on system objects — that can break the domain. Instead, change your approach:

• Use a targeted delete instead of a tree delete. Right-click the object and delete it directly. If the object is protected, you might need to unprotect it first (see fix #1).
• If a targeted delete also fails, use ADSI Edit (adsiedit.msc) to delete the object. Connect to the domain partition, navigate to the object, right-click and delete. This bypasses some interface-level protections.
• For stubborn objects that refuse deletion even in ADSI Edit, use the Remove-ADObject PowerShell cmdlet with the -Recursive flag — but only on isolated objects you're sure are safe to remove:

Remove-ADObject -Identity "CN=OrphanedComputer,OU=Domain Controllers,DC=domain,DC=com" -Recursive -Confirm:$false

But seriously, don't blindly delete things under Domain Controllers or Builtin. If you're deleting a whole OU, move those protected objects out first, then delete the OU.

3. AdminSDHolder privilege propagation is blocking the delete

This one's trickier. The adminSDHolder process runs every 60 minutes on a domain controller and resets the security descriptor on any object that's a member of a privileged group (like Domain Admins, Enterprise Admins, etc.). If you try to delete an OU that contains a user who's a member of Domain Admins, the adminSDHolder process can interfere. The error appears sporadically — sometimes the delete works, sometimes it doesn't, depending on timing.

Real-world scenario: a company reorganizing their AD structure had a legacy OU with a service account that was mistakenly added to Domain Admins. Tree delete worked in test but failed in production. The adminSDHolder had reset the security descriptor between attempts.

How to fix it

1. Remove the object from all privileged groups first. Use this PowerShell to find them:

Get-ADUser -Identity "problemUser" -Properties MemberOf | Select-Object -ExpandProperty MemberOf

Check for groups like Domain Admins, Enterprise Admins, Schema Admins, Administrators, Backup Operators, etc.

1. Remove the user from those groups: Remove-ADGroupMember -Identity "Domain Admins" -Members "problemUser"
2. Wait for the adminSDHolder cycle to complete (you can trigger it manually if you're impatient, but it's safer to wait 60 minutes).
3. Then retry your tree delete.

If you can't wait, you can temporarily disable the adminSDHolder process by stopping the Microsoft Exchange Active Directory Topology service on the DC — but that's risky and I don't recommend it. Just remove the privileged membership and move on.

Quick-reference summary table

In most cases, fix #1 will solve it. If not, check for privileged group membership and use a targeted delete. The 0X00002170 error is AD's way of saying "I'm not going to let you break this." Respect that, and you'll get through it clean.