Active Directory & Power Outages

A power outage is not a USN rollback

Active Directory's database engine (ESE / JET Blue, the same technology family used by Exchange) is built on a transactional, write-ahead-log architecture: changes are written to the transaction log before they're applied to the database file (ntds.dit). That's exactly what this design is for — after a hard crash, the engine replays the logs on next start and reconstructs a consistent, up-to-date state. A single, cleanly isolated power outage on a domain controller, by itself, normally does not trigger a USN rollback.

A real USN rollback is caused by something different: when a domain controller comes back up with a database whose update sequence number is lower than the one other domain controllers already received and processed from it. That typically happens when an older backup or snapshot gets restored — not from plain power loss.

When a checkpoint gets applied instead of a normal boot

The classic trigger for a real USN rollback on a virtualized domain controller is an applied Hyper-V checkpoint — someone snapshots the DC VM "just in case" before a risky change, and later restores it without handling the DC correctly afterward. The VM then boots with a USN state that, from its replication partners' point of view, lies in the past — exactly what triggers rollback detection (event ID 2095) and disables replication on the affected DC until it's manually cleaned up.

Windows Server has shipped a built-in safeguard for this since Server 2012: the VM Generation ID. Hyper-V changes this ID whenever a checkpoint is applied, and Active Directory detects the change on next start — instead of a silent, dangerous rollback, the DC automatically triggers a non-authoritative resynchronization. That's a genuine safety net, but not a free pass: Microsoft's own guidance remains never to use regular Hyper-V checkpoints on domain controller VMs — use a VSS-based, app-consistent system state backup instead (Windows Server Backup, or an equivalent third-party tool with AD VSS writer support).

Four things that matter during a real outage

1. Storage write cache without power-loss protection
   The actual danger isn't the ESE engine, it's the storage path underneath it: if a RAID controller or SSD reports a write as complete while the data is still sitting in volatile cache, even the best transaction logging can't help — recovery replays logs on top of a state that was never physically written. Battery-backed or flash-backed write cache is the real safeguard here, not the AD engine.
2. SYSVOL/DFSR journal, not USN rollback
   If SYSVOL replication (group policy, logon scripts) over DFSR falls out of sync, that can trigger a journal wrap requiring a non-authoritative resync — a separate problem from USN rollback, but with similar practical consequences (replication stalls until manually addressed).
3. FSMO roles during the outage window
   If the PDC emulator specifically is unreachable during an outage, time-critical operations (time sync, urgent password changes) get delayed until it's back — an availability problem, not a corruption one.
4. The reflex to restore a snapshot under pressure
   The biggest practical risk factor is often human: a DC doesn't come back up cleanly after a chaotic outage, and in the rush someone reaches for an old checkpoint as the apparent fastest way back online — which is exactly where the real rollback risk from section 02 comes from. A predictable, orderly shutdown and restart process removes that time pressure in the first place.

Check before the next power outage

1. Never take regular Hyper-V checkpoints on DC VMs — not even "just in case" before a maintenance window. VM Generation ID catches most of it, but it's a safety net, not a substitute for doing it right.
2. App-consistent backups instead of snapshots — plan system state backups with AD VSS writer support as the regular backup method for DC VMs.
3. Check the storage write cache — battery-backed or flash-backed cache on the RAID controller, no unprotected write-back without power-loss protection under the DC VMs.
4. At least two DCs, physically/electrically separated — ideally not on the same UPS or circuit, so a single outage never hits all DCs at once.
5. Graceful shutdown instead of a hard cut — the real benefit isn't rollback protection itself, it's a faster, cleaner restart with no ESE repair needed and no reason to reach for a snapshot under pressure.
6. Document the time hierarchy and PDC emulator — know which DC holds the PDC emulator role and how long its unavailability is tolerable before time-critical operations on the network start to suffer.