Failover test brings a protected domain controller onto the live network because the VPG test network is set to production

Failover test brings a protected domain controller onto the live network because the VPG test network is set to production

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

Applies to: Zerto Virtual Replication (version not specific) protecting VMs, particularly domain controllers or other identity and stateful servers, where VPG NIC settings define separate failover and failover test networks.

Symptom: Around the time of a Zerto failover test, Active Directory on a production domain controller reports that another domain controller has been restored (for example USN rollback or restore detection events), even though no restore, snapshot or backup rollback was performed. Other services may also be affected by duplicate machines appearing on the live network.

Cause: In the VPG NIC settings, the failover test network for one or more NICs was set to the live or production network (VLAN or segment) instead of an isolated test network. During the failover test the recovered copy of the domain controller was powered on and connected to production, where the live domain controllers saw it as a restored or rolled back replica. A misconfiguration like this can stay hidden if the test network was previously unreachable (for example because of an incorrect VLAN) and only shows itself once that underlying network issue is fixed.

Resolution: 1. Confirm which VPG contains the affected VM and check the Zerto task history for a failover test at the time of the event. 2. Edit the VPG, open the NIC settings for each VM, and make sure the failover test network points to an isolated test network (VLAN or segment) that cannot reach production. Keep the live network for the failover (live) setting only. 3. Save the VPG and review every other VPG in the same environment for the same misconfiguration. 4. Fix the Active Directory impact using standard Microsoft procedures (for example forcibly demoting or rebuilding the affected domain controller and cleaning up metadata), as appropriate for the damage. 5. As a preventive measure, check test network mappings whenever networks, VLANs or VPGs change, and take particular care with VPGs that contain domain controllers.