Fix 0x000020EA: AD Hierarchy Table Build Failed

The 30-Second Fix: Reboot and Check Basic Services

I know, I know — everyone says reboot. But I've seen this error pop up after a domain controller runs for months without restart, and a simple reboot cleared it. Here's what you do:

Restart the domain controller showing the error.
After reboot, hit Start > Run > services.msc. Make sure Active Directory Domain Services, Kerberos Key Distribution Center, and Netlogon are all running.
Run dcdiag /q in an elevated command prompt to see if the error persists.

If the error's gone, you're done. If not, move on. Most times this isn't the fix, but it's free and fast.

The 5-Minute Fix: Check Replication Health with repadmin

This error often means replication broke somewhere. I had a client last month whose entire print queue died because a single domain controller couldn't sync its hierarchy table — turned out a firewall rule blocked RPC traffic between sites. Here's how to check:

Open an elevated command prompt.
Run repadmin /showrepl. Look for any lines that say "Last success" older than a few days, or "Last failure" with error codes.
Run repadmin /replsummary. This gives you a quick table of all domain controllers and their replication status. If one DC shows all failures, you've found your problem child.
If you see specific failures, try repadmin /syncall /AdeP to force a full replication cycle.

Still failing? Check if the KB5008325 patch is installed — that one caused hierarchy table issues on Windows Server 2019. Had a client uninstall it and the error vanished within 15 minutes.

The 15+ Minute Fix: ntdsutil Database Repair

If replication's healthy but the error won't die, the NTDS database (ntds.dit) itself is corrupted. This is where the real fix lives. I'll walk you through a safe repair — but only do this if you've got a backup of that DC, or you're okay rebuilding it if things go sideways.

Step 1: Boot into Directory Services Restore Mode (DSRM)

You can't touch the database while AD is live. Restart the server and press F8 during boot. Choose Directory Services Restore Mode. Log in with the DSRM password (set when you promoted the DC).

Step 2: Run ntdsutil to Repair

Open an elevated command prompt.
Type ntdsutil and press Enter.
At the ntdsutil prompt, type activate instance ntds (or activate instance "NTDS" if your instance name has spaces).
Type files to enter file management mode.
Type info to see the current database path (usually C:\Windows\NTDS).
Type compact to C:\temp\ntds (or another drive with free space). This creates a compacted copy of the database — it won't alter the original until you swap it.
If compaction succeeds, type quit twice to exit ntdsutil. Copy the compacted ntds.dit from C:\temp\ntds back to C:\Windows\NTDS (overwrite the old one).

Step 3: Reboot Normally

Restart the server in normal mode. Run dcdiag again. The error should be gone. If not, you've got a deeper issue — likely hardware (bad RAM) or a disk that's throwing read errors. I've seen failing RAID controllers cause this on Server 2016. Check the Event Viewer under System for disk errors like 11 or 153.

When to Give Up and Demote

If you've done the repair and the error returns within a week, that DC's database is toast. Demote it using dcpromo /forceremoval (or Server Manager), clean up metadata with ntdsutil metadata cleanup, and rebuild a fresh DC. Takes a couple hours but beats fighting database corruption every month.

Quick tip: Always keep at least two domain controllers per domain. When one goes down, you don't panic. Learned that the hard way after a hurricane took out a single DC in a client's office — took two days to rebuild.

That's it. Start with the restart, check replication, then hit the database. Most people stop at step two. You won't need the advanced fix unless you're unlucky.