Fix ERROR_DS_ROOT_REQUIRES_CLASS_TOP (0x000020F0)

You're stuck with error 0x000020F0 when promoting a domain controller

I get it — you've run dcpromo or installed the AD DS role, clicked through the wizard, and bam: ERROR_DS_ROOT_REQUIRES_CLASS_TOP. The fix is straightforward once you know where to look. Let's get your domain controller running.

The Real Fix: Add the 'top' Object Class via ADSI Edit

The culprit here is almost always a corrupted or incomplete root domain naming context. This happens when a previous domain controller was demoted improperly, or someone restored AD data from an older backup. The root object (the entry named after your domain) must have objectClass: top — without it, AD DS promotion refuses to continue.

Step 1: Open ADSI Edit

Click Start, type adsiedit.msc and hit Enter.
If you don't see ADSI Edit, install it via Server Manager > Add Features (it's part of AD DS and AD LDS tools).

Step 2: Connect to the Root Domain Naming Context

Right-click ADSI Edit in the left pane, choose Connect to.
In the dialog, under Connection Point, select Select a well-known Naming Context.
Choose Root Domain Naming Context from the dropdown. Click OK.

Step 3: Find the Root Object

Expand the tree — you'll see an entry like DC=yourdomain,DC=com.
Right-click that root object, then choose Properties.

Step 4: Add the 'top' Class

In the Attribute Editor, scroll to objectClass.
Click Edit. You'll see a list of existing classes. If top is missing here, that's your problem.
Click Add, type top, and hit OK. (Case doesn't matter here.)
Make sure top appears in the list, then click OK twice to close.

Step 5: Retry the Domain Controller Promotion

Close ADSI Edit. Run the AD DS installation again. The error should be gone — if it isn't, reboot the server first. It usually sticks.

Why This Works

Every object in Active Directory has an objectClass attribute that defines what it is. The top class is the abstract base class for all AD objects. Without it, the root domain naming context isn't recognized as a valid directory partition. The promotion process checks this during the prerequisite validation — it's a hard stop.

Most admins waste time checking DNS, replication, or burning out a clean OS reinstall. Those aren't the issue here. The root object lost its top class during a botched cleanup or restore. Adding it back is the only real fix.

Less Common Variations of This Error

You'll see error 0x000020F0 in three main scenarios. Here's how they differ:

Scenario	What's Different	Fix
After a forced demotion	dcdiag /q might show orphaned partitions	Same ADSI Edit fix — the root is usually intact, just missing top class
Restored from system state backup	AD database restored from a backup of a different server	Requires a metadata cleanup first, then add top class
Cross-forest migration failed	ADMT or similar tool left the naming context incomplete	Use ntdsutil to seize roles, then apply the same ADSI Edit change

In all these cases, the root object itself is the problem. Don't bother checking DNS forwarders, firewall rules, or time sync — they won't generate this specific error code.

Prevention: How to Keep This From Coming Back

Three rules I've learned the hard way:

Never force-demote a domain controller without proper cleanup. Always run dcpromo /forceremoval as a last resort, but clean up metadata in AD Sites and Services afterward. Or use Remove-ADDomainController in PowerShell.
Don't restore AD from backups of other DCs. If you need an authoritative restore, use the correct backup from the same server. Cross-server restores break the root object class.
Script your domain promotions. Save a step-by-step or PowerShell log. When something goes wrong, you'll see exactly where it failed.

Stick to those, and you'll never see 0x000020F0 again. If you do — well, now you know the fix.