Full System Recovery onto a New VM

A full system recovery onto a new VM restores a whole domain controller from a full system backup onto an empty virtual machine. Nothing is installed on the VM first: no Windows and no agent. When you execute the recovery, the storage agent builds a recovery ISO for this run only, and the VM boots from it. The recovery agent on the ISO enrolls with the Manager, checks the VM's firmware and disks against the backup, and restores the domain controller's critical volumes onto the VM's disks. When it finishes, the VM is the domain controller, with the original's name, identity, and directory as of the restore point.

Use it when a domain controller will not start, or when its hardware or virtual machine is gone or must not be trusted, and you do not want to prepare a candidate machine with Windows and the DC agent first. On Hyper-V, cdr dc rebuild builds the VM from the restore point and boots it from the ISO in one step. The restore is non-authoritative: the domain controller catches up from its healthy partners afterward.

Before you begin

  • You need the Restore Operator role, or one operator who can approve and another who can execute. Fetching the recovery ISO to build the VM needs the plan.execute capability.
  • You have a Full system restore point of the domain controller, younger than the tombstone lifetime.
  • The installation ISO for the domain controller's operating system is in the OS media library. The storage agent builds the recovery ISO from its boot files. See OS Media.
  • A recovery image exists for the domain controller's operating system. Check the Recovery image column on the OS Media screen.
  • For the automated VM build, a Hyper-V host where you can run cdr elevated. On another hypervisor, build the VM by hand. Keep the Hyper-V host on current Windows updates. A host that is behind can give new virtual machines firmware that will not start an up-to-date restored system: the restore completes, and the restored system does not start.
  • The VM's network reaches the Manager and the storage machine.
  • You can power off the original domain controller. Two machines with one identity damage a domain rather than recover it.
  • If volumes in the backup were protected by BitLocker, have the recovery keys at hand. A TPM protector belongs to the original machine.

For the full list, see Recovery Requirements. To compare this method with the others, see Restore Methods.

How the recovery media works

The recovery ISO holds the installation media's boot files, the recovery image, and the job for this run. It carries only three things that identify the run to the Manager: a single-use enrollment token, the Manager's address, and the fingerprint of the Manager's CA. The credential that reads the vault stays in the Manager's memory, and is handed to the recovery environment over its session after the recovery agent on the ISO enrolls.

  • The media lives for the run's read lease, 8 hours. If no VM has booted it and enrolled by then, the run fails; nothing has been written, and the VM can be deleted.
  • If the Manager restarts after the media is built and before the VM enrolls, it no longer holds the vault credential. Cancel the run and plan it again.
  • A copy of the ISO holds the run's enrollment token until the run ends. Delete every local copy afterward.

Power off the original

Power off the original domain controller, or disconnect it. The new VM comes up as the same machine, with the same name and the same SID. While the original's agent is connected to the Manager, preflight shows the hard check target.original-running, which blocks approval, and execution is refused. If the original's hardware or virtual machine still exists, make sure it cannot be started again on the production network after the recovery.

Plan the recovery

Once you choose a new VM in Restore destination, the console lists every domain controller with a restore point, whether or not its own agent is connected. The original's agent is not needed.

To plan a full system recovery onto a new VM:

  1. Go to Recovery > Recovery Plans, and under Active Directory recovery, select Single-DC recovery.

  2. In Recovery mode, select Full system.

  3. In Restore destination, select Onto a new VM booted from a recovery ISO — nothing installed on it first.

  4. In Source domain controller, select the original domain controller, and in Restore point, select a full system restore point.

  5. Optionally, expand Advanced: the restored system's network and check Restored system address. The VM's adapter is a different device from the original's, so the options are the same as for a candidate; see Full System Recovery onto a Candidate.

  6. If the VM's network has no DHCP, expand Advanced: the recovery environment's network and set Another address for the recovery environment.

  7. Select Plan this restore.

Approve and execute

Nothing runs on the new VM before the recovery ISO boots, so there is no survey of it, and Ask the machine again is not offered. Preflight shows the advisory check target.new-vm instead: the recovery agent checks the VM when it boots.

To approve and execute the recovery:

  1. On the restore's page, resolve every hard check on the Preflight card, accept or refuse each check that asks for your acceptance (see Full System Recovery in Place), and then select Approve this restore.

  2. Select Execute…, enter the domain controller's short name in capitals, and select Restore NAME now.

    The storage agent builds the run's recovery ISO. When it is ready, the Recovery media card on the run's page shows the ISO, its SHA-256 hash, where it is exposed, and the command that builds the VM.

Build and boot the VM

On Hyper-V, build the VM with cdr dc rebuild --restore-run. Run it in an elevated PowerShell on the Hyper-V host that will run the VM, signed in to the Manager. Copy the command with the copy button on the Recovery media card, or from cdr restore show, and replace <SWITCH> with the host's virtual switch. The command names the Manager with --manager, so cdr on the host does not look for it on localhost. cdr refuses the command while the placeholder is unchanged:

cdr dc rebuild dc01.corp.example.com --restore-run <run> --switch "Recovery" --start

The command:

  • Shapes the VM from the run's restore point: firmware generation, memory, processors, and disk sizes. The disks are blank.
  • Copies the run's recovery ISO to the Hyper-V host, to %ProgramData%\CygnaDR\RecoveryMedia unless you give --media-dir, and checks its SHA-256 hash against the media's.
  • Attaches the ISO with the disk first in the boot order, so the blank VM boots the ISO, and the restored system boots from its disk afterward.
  • With --start, starts the VM. The restore then runs unattended.

--plan shows what would be built, and copies nothing. For the other options, see Inventory Commands.

On another hypervisor, build a VM by hand with the same firmware type as the original, at least as many disks as the backup, each the same size or larger, and enough memory; see Full System Recovery onto a Candidate for the shape. Attach the ISO shown in Exposed at on the Recovery media card, and start the VM.

Note: Important: The local copy of the ISO holds the run's enrollment token until the run ends. Delete it after the recovery.

What happens during the recovery

The VM boots the recovery ISO, and the recovery agent enrolls with the Manager, which then hands it the vault credential. The Recovery media card's Vault credential fact changes to handed to the recovery environment over its session. Before wbadmin writes anything, the recovery agent checks the VM's firmware and disks against the backup; if they do not fit, it stops with nothing written. wbadmin then restores every critical volume. Once the Manager has recorded success, the VM restarts into the restored domain controller, whose agent applies the planned address and reconnects. The run completes when validation passes, as described in Full System Recovery in Place.

The run's timeline shows the steps Recovery ISO built, Waiting for a VM booted from the recovery ISO, and Vault credential handed to the recovery environment. If the recovery image has never been proven by a restore and the VM does not boot it, nothing enrolls, and the run fails when its media expires; nothing will have been written, and the VM can be deleted.

Note: Important: Once wbadmin begins writing, the recovery cannot be stopped safely. To discard or abandon the recovery, use the same actions as for an in-place recovery. To stop it before then, power the VM off from its hypervisor: once the VM's recovery environment has connected, the Manager cannot tell it to stop, and Ask the machine to stop… is refused with The recovery environment on the new VM cannot be told to stop. When the recovery environment has been silent past its allowance, cancelling closes the run.

Using the command line

cdr restore plan dc01.corp.example.com --version "09/02/2026-23:00" --mode server --onto-new-vm
cdr restore approve <run>
cdr restore run <run>
cdr dc rebuild dc01.corp.example.com --restore-run <run> --switch "Recovery" --start
cdr restore show <run> --wait

cdr restore run builds the recovery ISO. cdr restore show then gives the media's file, size, SHA-256 hash, and location, whether the vault credential has been handed over, and the cdr dc rebuild command to run. Run cdr dc rebuild from another terminal on the Hyper-V host. For every option, see Restore Commands.

Result and next steps

The VM now runs as the domain controller from the restore point and catches up from its partners. Next:

  • Delete the local copy of the recovery ISO.
  • Check the domain controller's address, DNS records, and site membership, especially if the restored network was left as the backup had it.
  • Make sure the original machine is wiped or cannot return to the network.
  • Take a fresh backup and complete the follow-ups in After a Recovery.

To prove that backups restore this way without touching production, run a test restore on an Isolated Recovery Host. It uses the same recovery ISO and new-VM path. See Test Restores.