Fix ERROR_DS_CANT_DELETE (0x20CE) in Active Directory

Cause 1: The object is protected from accidental deletion

Most of the time, this error isn't a real permissions problem—it's Active Directory's built-in safety switch. Windows Server 2008 and later add a ProtectedFromAccidentalDeletion flag to most directory objects. If that flag is set, the delete operation returns ERROR_DS_CANT_DELETE (0x20CE) even if you're a domain admin.

You'll see this most often when you try to delete an OU or a user account that's nested inside a protected container. The error message doesn't tell you which object is protected, so you have to check.

How to fix it

Open Active Directory Users and Computers (ADUC). Enable Advanced Features under the View menu, then right-click the object, go to Object tab, and uncheck Protect object from accidental deletion. Apply and try the delete again.

If you're deleting via PowerShell, you need to clear the same flag with the -ProtectedFromAccidentalDeletion $false parameter. Here's a one-liner that strips it off a specific OU and removes it:

Set-ADOrganizationalUnit -Identity "OU=OldDepartment,DC=contoso,DC=com" -ProtectedFromAccidentalDeletion $false
Remove-ADOrganizationalUnit -Identity "OU=OldDepartment,DC=contoso,DC=com" -Confirm:$false

Do the same for users or groups with Set-ADObject. Just remember—you're turning off a safety net, so be sure you're deleting the right thing.

Cause 2: Lingering objects from a failed domain controller

Here's the sneaky one. If you've ever decommissioned a domain controller without properly removing it from Active Directory, you get lingering objects. These are objects that exist on one DC but not the rest, and they block deletes because the directory service thinks another DC might still reference them.

Typical scenario: You force-demoted a DC with dcpromo /forceremoval or just wiped the server. The metadata stays behind. Later, you try to delete the old computer account or a user tied to that server, and boom—0x20CE.

How to find lingering objects

Use repadmin /removelingeringobjects on each DC. But first, you need to know which DC has the offending object. Run this on a healthy DC to list all DCs and their GUIDs:

repadmin /showrepl

Then, for each DC, query the object's existence:

repadmin /showobjmeta <DC-name> "<DN of the object you're trying to delete>"

If the command returns metadata, the object exists there. If it comes back with an error, that DC has a lingering object.

The fix

On the DC that holds the lingering object, run:

repadmin /removelingeringobjects <DC-name> <object-DN> /advisory_mode

First run it in advisory mode to see what it would remove. If it looks right, drop /advisory_mode and let it clean up. After that, the delete should go through.

If you don't care about preserving the object, you can also use ntdsutil to do a metadata cleanup. But honestly, repadmin is faster and less likely to mess things up.

Cause 3: ACLs blocking the delete operation

Less common but still real. Even if you're a domain admin, the object's DACL might not grant you the DELETE permission. This happens when a parent OU has inherited permissions that deny delete on child objects, or when someone customized the ACL and removed the default “Domain Admins” entry.

I've seen this on service accounts that were created by third-party apps that lock down their own OU. The app's installer set a deny ACE for delete on all child objects, and now you can't clean up after the app was uninstalled.

How to fix it

Open ADUC, enable Advanced Features, right-click the object, go to Security tab, click Advanced, and look for any deny entries. If you see one for “Delete” or “Delete subtree”, remove it or change it to allow.

You can also use dsacls to reset the ACL back to defaults:

dsacls "<DN of object>" /reset

That resets the DACL to the default inherited permissions. After that, try the delete again.

If the object is an OU and you want to delete everything inside it, you might need to reset ACLs on each child object first. Use dsacls with the /inheritance:descend option to propagate permissions down the tree.

Quick-reference summary table

That's the whole playbook. Start with the protection flag—it's the most common and the quickest to rule out. Then check for lingering objects if you've recently decommissioned a DC. ACLs are last because they're rare, but they happen. Good luck.