Fix ERROR_DS_CODE_INCONSISTENCY (0X000020D8) - Active Directory

What Actually Triggers 0X000020D8

I've seen this error pop up more times than I can count. It's almost always tied to a botched domain controller promotion or a schema update that didn't finish cleanly. You'll see it in the Directory Services event log with event ID 1168 or 1126, and sometimes right in the DCPromo wizard when you're trying to add a new DC. The exact message reads: "An internal error has occurred." That's about as helpful as a screen door on a submarine.

The error code 0X000020D8 translates to ERROR_DS_CODE_INCONSISTENCY. Under the hood, it means the Active Directory database engine (ESE) found data that doesn't match its schema definitions. Maybe a record got half-written, maybe a schema class got updated but the attributes didn't follow. Whatever the cause, the directory service won't start until you fix the inconsistency.

Don't panic. I've walked dozens of techs through this. Here's the order of battle — start with the most common fix first, then move down the list.

Cause #1: Incomplete Schema Update

The #1 reason I see this error: someone ran a schema update (like for Exchange, Skype for Business, or a Windows Server feature pack) and it didn't finish. Maybe the server rebooted mid-update, or the LDAP connection dropped. You end up with schema objects that reference attributes that don't exist yet — classic inconsistency.

Fix: Run Schema Validation with ntdsutil

1. Open a command prompt as Administrator. No PowerShell shortcuts — use cmd.exe.
2. Type ntdsutil and press Enter. You'll see the ntdsutil prompt: ntdsutil:
3. Inside ntdsutil, type schema management and press Enter. The prompt changes to schema management:
4. Now type validate schema and press Enter. Watch the output — it'll list any missing or broken cross-references.
5. If you see errors, type fix schema and press Enter. This forces ntdsutil to repair the schema partition. After you hit Enter, you should see green text saying "Schema fix completed." If you see red errors, the schema is too far gone — move to Cause #2.
6. Type quit twice to exit ntdsutil.

After the fix, restart the Active Directory Domain Services service. Open Services.msc, find Active Directory Domain Services, right-click it, choose Restart. Wait 60 seconds. Check Event Viewer under Directory Service — you should see event ID 1000 with a clean start.

Cause #2: Corrupted Database Page

If schema validation didn't work, you're looking at a corrupted database page. This happens more on older hardware or after a dirty shutdown (power loss, hard crash). The ESE database has a checksum check — if a page's checksum doesn't match, you get error 0X000020D8.

Fix: Repair with esentutl

1. Stop the Active Directory Domain Services service first. Run net stop ntds as Administrator. The service should stop in about 10 seconds. If it hangs, use net stop ntds /y.
2. Open an elevated command prompt and change to the NTDS folder: cd %windir%\NTDS. The database file is ntds.dit. Before doing anything, copy it: copy ntds.dit ntds.dit.bak. Always do this — you'll thank me.
3. Run a repair: esentutl /p ntds.dit. The /p flag is the offline repair switch. You'll see a warning telling you to use this only as a last resort. That's right — it is a last resort, but it's the one that works when nothing else does. Type y to confirm.
4. The repair takes anywhere from 2 minutes to 20 minutes depending on database size. When it finishes, you'll see "Done. Repair completed." If you see any errors, the database is beyond repair — you'll need to restore from backup.
5. After repair, run a consistency check: esentutl /g ntds.dit. You should see "Database is consistent!" at the bottom. If not, the repair didn't fully fix it — restore from backup.
6. Start the AD DS service: net start ntds.

Check the Directory Service event log. If you see event ID 1000 with no errors, you're good. If the error returns, you've got a hardware issue — check the disk for bad sectors with chkdsk /f /r.

Cause #3: Failed Domain Controller Promotion

This is the sneaky one. You try to promote a new server to a domain controller, the wizard fails halfway through, and you're left with a partial AD installation. The error shows up when the server tries to start the directory service after reboot.

Fix: Force Demotion and Re-promote

1. Boot into Directory Services Restore Mode (DSRM). Restart the server and press F8 before the Windows logo appears. Select Directory Services Restore Mode.
2. Log in with the DSRM password — the one you set during promotion. If you don't remember it, you'll need to reset it using ntdsutil set dsrm password from another DC (if any remain).
3. Open an elevated command prompt. Run dcpromo /forceremoval. This forcefully demotes the server without talking to the network. You'll be prompted to confirm — type Y.
4. The server will reboot after demotion. Now it's a member server again — no directory service present.
5. Clean up leftover metadata. On another DC, open Active Directory Users and Computers. Right-click the domain, choose Operations Masters, go to the RID Pool tab, change the RID master to a different DC if needed. Then open Active Directory Sites and Services, expand the site, find the old server, right-click and delete it.
6. Now re-promote the server. Run dcpromo again from the clean server. Make sure you pick the right domain and site. When the wizard finishes, you should see green checkmarks and a reboot prompt.

I've had to do this on Server 2012 R2 through 2022. The /forceremoval switch is your friend — it doesn't care about network connectivity or replication status. Use it when the normal demotion won't work because the directory service won't start.

Quick-Reference Summary Table

One last thing — if none of these work, check your backups. Restore a clean AD database from before the error appeared. I've seen cases where the hardware itself was failing (bad RAM, failing disk) and no software fix could hold. Run a memory test and check the disk SMART status if this keeps happening.