Fix ERROR_DS_CHILDREN_EXIST 0x0000208C in Active Directory

What's Going On?

You tried to delete an Active Directory object—maybe a user, a group, or an OU—and got that 0x0000208C error. Windows is telling you: "Nope, this thing has kids." It's a safety net AD has to stop you from nuking an entire branch by accident. But if you meant to delete it, you just need to clear out the children first.

I saw this last week with a client who'd created a bunch of test OUs under a single container during a migration. When they tried to clean up, AD refused. The fix took about two minutes once we knew where to look.

The 30-Second Fix: Check What's Inside

Open Active Directory Users and Computers (dsa.msc). Go to View and make sure Advanced Features is checked. Now right-click the object you're trying to delete and choose Properties. Click the Object tab. You'll see a count of child objects next to "Object class." If it says anything above zero, that's your problem.

But this doesn't tell you what the children are. For that, you need the next step.

The 5-Minute Fix: ADSI Edit

ADSI Edit gives you a raw look at the directory. It's the surgical tool for this.

Open ADSI Edit (adsiedit.msc). If you don't have it installed, go to Server Manager > Add Roles and Features > Remote Server Administration Tools > AD DS and AD LDS Tools.
Right-click ADSI Edit in the console tree and choose Connect to. Leave the defaults (it'll connect to your domain).
Navigate to the object that's failing. For example, if it's an OU called "TestOU" under your domain, browse to DC=yourdomain,DC=com then find the OU.
Right-click the object and choose New > Object. No, wait—actually, right-click and pick Properties. Look for the children count attribute. But the real trick: right-click the object and choose Move. If it won't move because of children, you know you've got hidden stuff.
To see all children, use the Filter option in the console—set it to show everything, including system objects.

Once you spot the children, delete them one by one (right-click > Delete). If they also have kids, you'll get the same error—so delete from the bottom up.

Quick shortcut: open a command prompt and run ntdsutil. Type list children after connecting to the domain. Yes, it's ugly, but it shows you every single child object.

The 15+ Minute Fix: PowerShell Bulk Remove

When you've got dozens or hundreds of child objects, ADSI Edit isn't practical. Use PowerShell instead.

Get-ADObject -Filter * -SearchBase "OU=ProblemOU,DC=yourdomain,DC=com" |
    Sort-Object -Property ObjectClass, Name -Descending |
    ForEach-Object {
        try {
            Remove-ADObject -Identity $_.DistinguishedName -Confirm:$false -Recursive
        } catch {
            Write-Warning "Failed to delete $($_.DistinguishedName): $($_.Exception.Message)"
        }
    }

This command gets all objects under that OU, sorts them by type (so containers come last), and recursively deletes each one. The -Recursive flag is key—it tells AD to delete children of children, all the way down. Without it, you'll get the same error.

Test with -WhatIf first if you're nervous:

Get-ADObject -Filter * -SearchBase "OU=ProblemOU,DC=yourdomain,DC=com" | Remove-ADObject -WhatIf -Recursive

This shows you what would be deleted without actually doing it.

When All Else Fails: Boot into Directory Services Restore Mode

If the object is a system-critical container (like a domain controller's computer object), you can't delete it normally. Boot the DC into Directory Services Restore Mode (press F8 during startup). Log in with the DSRM admin password. Then use ntdsutil to forcibly remove the object:

ntdsutil
metadata cleanup
connections
connect to server localhost
quit
remove selected server

This is extreme. Only do it if the object is a dead DC that won't replicate. Otherwise, stick with ADSI Edit or PowerShell.

Prevent This from Happening Again

Before deleting any AD object, run Get-ADObject -Filter * -SearchBase "distinguishedname" to see children first.
Use Group Policy to disable accidental deletions. In AD Users and Computers, enable Protect object from accidental deletion on critical OUs. Then when you need to delete, uncheck that box first.
If you're cleaning up a bunch of test objects, write a PowerShell script that deletes from the bottom of the tree upward. Don't try to delete a container with children—it'll always fail.

That 0x0000208C error is just AD being cautious. Now you know how to get past it.