Full System Recovery onto a Candidate

A full system recovery onto a candidate restores a whole domain controller from a full system backup onto a different machine: a new virtual machine or a replacement server that runs Windows and has the DC agent installed, but is not a domain controller. The candidate's agent stages the recovery image and restarts the candidate into it, and the recovery agent restores the domain controller's critical volumes onto the candidate's disks. When it finishes, the candidate 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. The restore is non-authoritative: the domain controller catches up from its healthy partners afterward. The storage machine and Isolated Recovery Hosts are never offered as candidates, even with a DC agent installed. To check a backup without touching a machine, run a test restore instead.

To recover onto an empty virtual machine instead, with no Windows or agent installed on it first, see Full System Recovery onto a New VM.

Before you begin

You need the Restore Operator role, or one operator who can approve and another who can execute.
A recovery image exists for the original domain controller's operating system. Check the Recovery image column on the OS Media screen.
You have a Full system restore point of the domain controller, younger than the tombstone lifetime.
You have a candidate machine prepared as described below.
You can power off or isolate the original domain controller. Two machines with one identity damage a domain rather than recover it, so the Manager does not approve the recovery while the original still answers.
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.

Prepare the candidate

The candidate must be shaped like the backup:

Firmware—the same firmware type as the original, UEFI or BIOS. A restored system on the other firmware does not start. On Hyper-V, a generation 2 virtual machine is UEFI and generation 1 is BIOS. Recovery onto either firmware type is supported.
Disks—at least as many disks as the backup, each the same size or larger. wbadmin recreates each critical disk at its recorded size and refuses a smaller one, after the machine has already restarted into the recovery image.
Memory—enough to load the recovery image into a RAM disk, about the image size plus 1 GB. Less memory than the original works but may run slowly.
Storage controller—preferably one the restored Windows already has a driver for. Otherwise it stops at INACCESSIBLE_BOOT_DEVICE. If the candidate's boot controller differs from the original's, install its driver on the original domain controller before the backup. Built-in drivers cover common virtual controllers.
Network—the candidate can reach the Manager and the storage machine. The storage machine is reached at its advertised address, its IP address by default; if it is advertised by name, the candidate must resolve it through DNS alone. The recovery environment needs a driver for the candidate's network adapter. Add any driver it lacks to the storage agent's Driver folder, so that it is built into the recovery image.

Create a virtual machine with cdr dc rebuild

cdr dc rebuild creates a virtual machine shaped from the domain controller's newest restore point—firmware generation, memory, processors, and disk sizes—and attaches matching installation media from the OS media library. On Hyper-V, it creates the machine on the Hyper-V host where you run the command, which must run elevated. For ESXi, it writes a PowerCLI script that you run in your own PowerCLI session; cdr never runs an ESXi build itself.

cdr dc rebuild dc01.corp.example.com --plan
cdr dc rebuild dc01.corp.example.com --switch "Recovery" --start
cdr dc rebuild dc01.corp.example.com --hypervisor esxi --datastore ds01 --vmhost esx01.corp.example.com --script C:\Temp\dc01-rebuild.ps1

--plan shows what would be built without creating anything. For the other options, including --memory, --iso, and --manifest, see Inventory Commands. With --restore-run, the same command builds a VM for a recovery onto a new VM, which needs no Windows installation; see Full System Recovery onto a New VM.

Install Windows and the DC agent

To make a machine a candidate:

Create the virtual machine with cdr dc rebuild, or prepare a virtual machine or server by hand that meets the shape above.
Install Windows Server on it. Do not promote it to a domain controller.
Install the DC agent on it with the hand-install command shown on the Administration > Agents screen, for example:
```
msiexec /i CygnaDR.DcAgent.msi /qn MANAGERADDRESS=https://10.0.0.10:5211 MANAGERCAFINGERPRINT=<fingerprint> ENROLLMENTTOKEN=<token>
```
The agent enrolls and describes the machine's hardware to the Manager.
Confirm that the candidate is listed in Restore destination on the New single-DC restore page, or with cdr recovery candidates.

For installation details, see Deploying DC Agents.

Power off the original

Power off the original domain controller, or isolate it so that the candidate cannot reach it. The candidate checks every address the original used; while the original answers, preflight shows a hard check that blocks approval. 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 candidate in Restore destination, the console lists every domain controller with a restore point, whether or not its own agent is connected; one whose agent is down is marked agent not connected. The original's agent is not needed for a recovery onto a candidate.

To plan a full system recovery onto a candidate:

Go to Recovery > Recovery Plans, and under Active Directory recovery, select Single-DC recovery.
In Recovery mode, select Full system.
In Restore destination, select the candidate.

The list also offers the domain controller's own machine, a new VM booted from a recovery ISO, and a test restore on an Isolated Recovery Host; the candidates follow them.
In Source domain controller, select the original domain controller, and in Restore point, select a full system restore point.
Optionally, expand Advanced: the restored system's network and check Restored system address.

Windows binds a static address to the adapter it was set on, and the candidate's adapter is a different device. The default, Automatic, carries the backup's own static address onto the candidate's adapter when the backup recorded exactly one; the run's page says what it chose. Select The backup's own address to require it, As the backup left it to leave the restored domain controller on DHCP, or Another address if it moves to a new subnet. For all options, see Full System Recovery in Place.
If the candidate's network has no DHCP, expand Advanced: the recovery environment's network and set Another address for the recovery environment.
Select Plan this restore.

Survey, approve, and execute

To approve and execute the recovery:

On the restore's page, review The machine, as it described itself.

This is the candidate's own survey: firmware, memory, disks, free space, adapters, whether it reaches the storage machine, and whether the original still answers.
If you have powered off the original or changed the candidate since it described itself, select Ask the machine again.
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.
Select Execute…, enter the domain controller's short name in capitals, and select Restore NAME now.

Note: Important: Once wbadmin begins writing, the recovery cannot be stopped safely. The candidate's own Windows installation is overwritten and the candidate becomes the domain controller.

What happens during the recovery

The recovery runs as described in Full System Recovery in Place, on the candidate: its agent fetches and stages the recovery image, restarts into it, and the recovery agent checks the firmware and disks it can see against the backup before wbadmin restores every critical volume. Once the Manager has recorded success, the candidate restarts into the restored domain controller, whose agent applies the planned address and reconnects. When it first reconnects, the Manager removes the candidate's own agent record, because the operating system it described no longer exists. The run completes when validation passes.

After the restore, the candidate starts the DC agent build that staged the restore rather than the older one in the backup, and that agent checks that the domain controller works before the run completes. If the checks show Not checked, update the agent and select Validate again, or run cdr restore validate.

To stop, discard, or abandon the recovery, use the same actions as for an in-place recovery. Stopping works only before wbadmin starts writing.

Using the command line

cdr recovery candidates
cdr restore plan dc01.corp.example.com --version "09/02/2026-23:00" --mode server --onto <candidate-agent-id>
cdr restore show <run>
cdr restore survey <run>
cdr restore approve <run>
cdr restore run <run> --wait
cdr restore validate <run>

cdr recovery candidates lists each candidate's agent ID and the shape it reported. For every option, see Restore Commands and Recovery Plan Commands.

Result and next steps

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

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.