Fix 0X0000218E: Directory service single-user mode failed

You're rebooting a domain controller after pushing a schema extension — maybe installing Exchange or a third-party management tool — and instead of the directory service starting clean, you get this error in the System event log: Active Directory Domain Services failed to enter single-user mode. Error: 0X0000218E. The server boots fine, but no domain logons work. The real trigger here is that the NTDS database or its log files got corrupted during the schema update process, or the server was forced to shut down while applying schema changes.

What's actually causing 0X0000218E?

Single-user mode is AD's version of read-only startup. It lets one administrator make critical changes — like schema modifications — without interference. When the database engine (Extensible Storage Engine, or ESE) detects internal inconsistencies or damaged log sequences, it refuses to open the database even in that restricted mode. The root cause is almost always a corrupted transaction log file, a dirty shutdown of the database, or a failed schema write that left the database in an inconsistent state.

In my experience, the most common scenario is a schema update that gets interrupted by a power loss or a forced restart before the changes fully commit. The ESE then sees a missing or truncated log file and throws the 0X0000218E error rather than risk data integrity.

Before you start: backup and prepare

Don't skip this. You're about to work directly on the AD database. If something goes wrong, you'll need a fallback. Boot into Directory Services Restore Mode (DSRM) — that's the only way to get access to the database files when AD won't start.

Restart the domain controller and press F8 during the boot process.
Select Directory Services Restore Mode from the Advanced Boot Options menu.
Log in with the local Administrator account using the DSRM password you set when promoting this domain controller. If you don't know it, you'll need to reset it from another admin's tool like ntdsutil in a different DC — but that's a separate process.
After logging in, open Command Prompt as Administrator.
Make a folder to hold backups, like C:\ADBackup.
Copy the entire C:\Windows\NTDS folder to C:\ADBackup. That includes the ntds.dit file and all .log and .jrs files. Use this command:
```
xcopy C:\Windows\NTDS C:\ADBackup\NTDS /E /I /H
```
Wait until it finishes. Then verify the backup folder has all the files.

The fix: repair the NTDS database

The real fix is to run ESEUTIL — Microsoft's database repair tool — directly on the ntds.dit file. This is not something you do while AD is running; you must be in DSRM.

Open Command Prompt as Administrator in DSRM.
Navigate to C:\Windows\NTDS:
```
cd /d C:\Windows\NTDS
```
First, run a check on the integrity of the database. This doesn't fix anything, but it tells you how bad the damage is:
```
esentutl /g ntds.dit
```
Look for output that says Integrity check completed or lists errors. If it shows corruption, move to repair.
Run the repair command. This rewrites the database, discarding any corrupt pages:
```
esentutl /p ntds.dit
```
You'll get a big warning that the repaired database might have data loss. Accept it. This is the only way to get AD back up without restoring from backup.
After the repair finishes (it may take 10–30 minutes depending on database size), run a defrag/compact to rebuild the internal indexes:
```
esentutl /d ntds.dit
```
This compacts the database and can also fix remaining logical inconsistencies.
Restart the server normally — don't press F8 this time.
After reboot, open Event Viewer and check the Directory Service log. You should see event ID 1006 or similar saying the directory service started successfully.

If the repair fails — or you still get the error

Sometimes ESENTUTL can't fix the database because the log files themselves are too far gone. In that case:

Boot back into DSRM.
Use ntdsutil to perform a semantic database analysis:
```
ntdsutil
activate instance ntds
files
semantic database analysis
go
quit
quit
```
This checks for orphaned objects and directory reference problems. If it finds issues, run semantic database repair the same way — but know that this can delete objects that have broken references.
If still no luck, you're looking at a restore from a system state backup. On a non-critical DC, you can also demote it using dcpromo /forceremoval (in DSRM), then promote it fresh from another DC. This is faster than chasing a hopeless database.
Check the hardware: bad RAM or a failing hard drive can cause ESE corruption. Run chkdsk /f C: to check for disk errors, and test memory with Windows Memory Diagnostic.

My opinion: Don't waste time trying to fix the corrupted schema itself — just restore from backup if you have a recent system state backup. The ESENTUTL repair works maybe 70% of the time, but the remaining 30% will eat your whole shift. Always have a backup strategy that includes daily system state backups for domain controllers.

Preventing 0X0000218E from ever coming back

After you're up and running:

Never reboot a domain controller while a schema update is in progress. Watch the event log for event ID 1000 (schema update starting) and wait for event ID 1005 (schema update completed).
Use a UPS on every domain controller — power loss during schema writes is the #1 cause of this error.
Run ntdsutil integrity checks quarterly as part of routine maintenance. It won't corrupt anything, and it catches problems early.

That's the whole process. Start with the backup, run the repair, and if it doesn't work, restore or re-promote. You shouldn't need to go beyond these steps for 9 out of 10 cases.