Fix ERROR_DS_INIT_FAILURE_CONSOLE 0x2171 on Windows Server

Quick answer: Boot into Directory Services Restore Mode (DSRM), check the Directory Services event log for the root cause, and if it's SYSVOL-related, restore SYSVOL from a good backup or force an authoritative restore. If the database itself is corrupt, you may need to rebuild the DC.

What's actually happening here is that the Local Security Authority (LSASS) process is trying to start the NTDS service, but the Directory Service (DS) fails during initialization. The error 0x2171 (ERROR_DS_INIT_FAILURE_CONSOLE) is what you see on the console when the system is in DSRM and the DS can't start. It's not a specific root cause—it's a symptom. The real reason is usually one of three things: the Active Directory database (ntds.dit) is corrupt, SYSVOL is missing or inconsistent, or the DC is in an inconsistent state after an improper shutdown or restore.

I've seen this on Windows Server 2016 and 2019 DCs after a power outage, or when someone tries to clone a DC without properly using the cloning features. The reason step 3 works is that DSRM gives you a minimal environment to repair the DS without the normal boot sequence interfering.

Before you start

You'll need the DSRM password. If you don't have it, you're stuck—there's no backdoor. If you're not sure, ask whoever built the DC. If it's a virtual machine, you might be able to reset it via the hypervisor if you have a snapshot, but that's rare.

Step-by-step recovery

Boot into DSRM. Restart the server and press F8 before the Windows logo appears (on older systems) or use Shift+Restart from the login screen if you can get there. Choose Directory Services Repair Mode.
Check the event logs. Once in DSRM, open Event Viewer (or run eventvwr) and look under Windows Logs > Directory Service. Look for events around the time of the failure. Event IDs 1000, 1168, or 1699 are common. They'll tell you exactly what failed—don't skip this. For example, event 1699 says the DS couldn't start because the SYSVOL replica set is in a bad state, while 1168 indicates a Jet database error.
If it's a database corruption error (Jet errors like -1018, -1022), you have options: run esentutl /p /o <path_to_ntds.dit> (but that's a last resort—it can cause data loss), or restore the system state from a recent backup. If you have a system state backup, restore it using Windows Server Backup or another tool. After restore, reboot normally—if the error persists, you may need to do an authoritative restore of SYSVOL.
If it's SYSVOL-related (events about SYSVOL state, or the DFS Replication service fails), the fix is to restore SYSVOL. First, check if the SYSVOL folder exists on disk (C:\Windows\SYSVOL\sysvol\). If it's empty or has inconsistent data, you need to recover it. If you have a recent backup of the SYSVOL share from another DC, you can copy it over (after stopping the DFS replication service). If you're in a multi-DC environment, you might be better off forcing an authoritative sync using ntfrsutl (for FRS) or dfsrmig (for DFSR). But honestly, if it's a single DC, restoring from backup is the simplest.
Reboot normally. After any repair, restart the server without DSRM. Watch the boot process—if it hangs or shows the error again, you're back to square one.

If the main fix doesn't work

Sometimes the DS is too far gone. If you can't repair the database or SYSVOL, consider rebuilding the DC. Since this error usually appears on a DC, you can demote it (if you can get into normal mode, which you can't if the DS won't start), so you might need to force-remove AD from another DC or do a clean install. In a multi-DC domain, you can seize the FSMO roles and let this server die. But if this is your only DC, you're looking at a rebuild and restoring AD from backup—or if no backup exists, you're facing a full domain rebuild. That's harsh, but it's the reality.

One alternative I've used successfully: if the database is corrupt but you have a second DC, you can perform a non-authoritative restore of AD from backup and then let replication fix the rest. The reason that works is because replication will overwrite the restored database with current data from the other DC, effectively healing the corruption.

Prevention for next time

Always have at least two DCs per domain. This error is a nightmare on a single DC.
Take regular system state backups—weekly minimum, but daily is better. Use Windows Server Backup or a third-party tool that supports VSS.
Monitor the Directory Service event logs for early warnings, like event 1173 (database might be corrupt) or 2095 (SYSVOL issues). Catching these early can save you from a full outage.
Never force a shutdown on a DC. If you must, use shutdown /s /t 0 from an admin prompt, but that's still not ideal. Clean shutdowns prevent Jet database corruption.
If you're virtualizing DCs, avoid taking snapshots and restoring them without proper preparation—snapshots can cause USN rollback, which leads to this exact error.

This error is one of the few that can take down a whole domain if you're not careful. The key is to stay calm, get into DSRM, and read the logs before touching anything. Most of the time it's recoverable with a backup or a bit of SYSVOL surgery.