Recovered Windows VMs need manual 'boot normally' selection during failover test, resolved by force sync

Recovered Windows VMs need manual 'boot normally' selection during failover test, resolved by force sync

Machine-distilled from a resolved support ticket on 2026-09-28. Source ref: c6273fef43f8. Verify before relying on it.

Applies to: Zerto (version not confirmed) protecting Windows VMs on vSphere, seen during failover testing

Symptom: During scheduled failover test (boot test) of protected Windows VMs, several recovered VMs did not boot straight into Windows. They stopped at the Windows recovery or startup options screen and needed someone to choose the option to start Windows normally. After that they booted and ran with no further problems. The same VMs booted cleanly in the source environment, including after reboots and hard resets.

Cause: Not formally identified. The most likely cause is an inconsistency between the replica disks at the recovery site and the source disks, which makes Windows on the recovered copy behave as if the last shutdown or boot did not complete properly. Because the source VMs boot normally, the problem is in the replicated data, not in the guest OS.

Resolution: 1. Confirm with the VM owner that the affected VMs boot normally at the source and that nothing has recently changed on them. 2. Because a force sync triggers a full comparison of source and target data and can affect RPO while it runs, get approval first and, where possible, start with a non-production VM. 3. Run a force sync on the affected VPG or VMs and wait for it to finish and for the VPG to return to a healthy, meeting SLA state. 4. Run the failover test again and check that the VM boots straight into Windows with no manual step. 5. If it works, repeat the force sync and retest for the other affected VMs. 6. If the problem continues after a force sync, investigate further (for example, the checkpoint used for the test and the guest boot configuration).