Guest OS corruption or BSOD on Active Directory Domain Controllers during vSphere Site Recovery replication

Products

• VMware vSphere ESXi

Issue/Introduction

Symptoms

• Microsoft Active Directory Domain Controller (DC) virtual machines recovered at a secondary site via vSphere Replication fail to boot.
• The Guest OS enters a Blue Screen of Death (BSOD) loop or a forced File System Repair (chkdsk) immediately following recovery/power-on.
• Non-DC virtual machines using the same replication schedule recover and boot successfully.
• The issue persists regardless of whether "Guest OS Quiescing" is enabled or disabled in the vSphere Replication job configuration.
  
  

Below error is reflected on the Domain Controller VM on Boot:

Stop code 0xc00002e2 indicates a Windows Domain Controller failure caused by Active Directory database corruption or an old backup

Environment

vSphere Replication
VMware Live Site Recovery

Cause

The issue is caused by an application-level inconsistency within the Active Directory database (NTDS.dit).

vSphere Replication provides asynchronous, block-level replication which is crash-consistent but not natively "application-aware" for the multi-master replication logic of Active Directory. 

No issues were identified at the vSphere Replication or ESXi hypervisor layers; manual verification (e.g., vmkfstools -x check) typically confirms the virtual disk descriptor and flat files are healthy.

Resolution

Active Directory is a distributed database designed to handle its own replication. To ensure transactional integrity and avoid block-level corruption, follow these recommendations:

1. As per Microsoft recommendation's native AD replication should be used for Domain Controller VM's.

• Deploy a persistent, "always-on" Domain Controller at the Disaster Recovery (DR) site.
• Utilize Microsoft Active Directory native replication (RPC over IP) to synchronize objects between sites.
• This ensures that the AD database maintains its own consistency logic and avoids "split-brain" risks inherent in external block-level replication.

2. Guest OS Remediation

• If a recovered Domain Controller is already in a corrupted state and native replication is not feasible, engage Microsoft Support to attempt a Directory Services Restore Mode (DSRM) repair.

3. Review Protected Workloads

• Verify that Domain Controllers are excluded from block-level replication plans in VMware Live Site Recovery.

Additional Information

Related Information

• Virtual Machines that must not be protected by VMware Live Recovery
• Site Recovery Manager and Active Directory Domain Controllers