Recovery Scopes

A recovery has one of three scopes: a single domain controller, one domain in a running forest, or the whole forest. The scope decides which procedure runs, what it is allowed to change, and what it refuses to do. You choose the scope on the Recovery Plans screen, under Active Directory recovery.

Single domain controller

Use a single-DC recovery when one domain controller is damaged and the rest of its domain is healthy. The domain controller keeps its identity, and its directory goes back to the restore point. After the restore, Active Directory and SYSVOL converge from the domain's healthy domain controllers, so everything they hold that this domain controller missed comes back through replication. Anything written only to this domain controller after the restore point and not yet replicated away is lost.

A DC state recovery of a single domain controller also undoes changes that have already replicated: the subtrees and objects you name are marked authoritative after the restore, and replicate out to every domain controller of the domain as they were at the restore point. A full system recovery marks nothing.

The restore runs in three stages:

Preflight—Confirms that the restore point is usable and that this domain controller may be restored at all.
Restore—Restores the domain controller by DC state recovery or full system recovery. The stage passes when Active Directory starts and both the directory and SYSVOL begin converging from healthy peers. For a DC state recovery, the named subtrees and objects must also have been marked authoritative before the restart, their back-links imported after it, and their raised versions read back from replication metadata.
Validation—Checks the secure channel and replication against a healthy domain controller in the same domain. The restored domain controller's machine account password is reset against a healthy peer when needed.

A single-DC recovery never seizes roles, removes other domain controllers' metadata, resets trust passwords, or raises the RID pool. Those steps belong to domain and forest recovery. It resets krbtgt only after a DC state recovery whose subtree holds the krbtgt account, such as CN=Users, and only when you choose the reset. It then resets it twice: first once the rollback validates, and again after the first reset has reached every writable domain controller.

A single-DC restore is refused when:

The domain controller is a read-only domain controller. Rebuild it instead.
Its operations master roles were seized by another domain controller after the backup was taken. Rebuild it; never restore it.
The restore point is older than the tombstone lifetime, has been pruned, or has no version identifier.
The domain replicates SYSVOL with FRS.
Another restore of the same machine is already in progress.
A DC state recovery names nothing to roll back, or names a subtree or object it does not accept. See Restoring a DC with DC State Recovery.

One domain in a running forest

Use a domain recovery when one domain is damaged or compromised and the other domains of the forest are healthy. The rest of the forest stays live, and the plan writes to it: it resets the domain's trusts on both sides and reconciles every global catalog in the forest with the restored domain. The plan shows these effects outside the domain before you approve it.

In the plan, you choose for each domain controller in the domain whether it is restored, rebuilt, or excluded. An excluded domain controller is neither restored nor rebuilt: its metadata is removed from the directory along with the domain's other domain controllers, and it is not brought back, so keep the machine off the network. By default, one writable domain controller is restored and the rest are rebuilt. The recovery then runs in this order:

Plan and preflight, including the global catalog strategy.
Isolate the domain's restore targets from production, with firewalled paths only to the Manager and the storage machine. You attest to this. See Isolating Recovery Targets.
Restore the chosen domain controller and make its SYSVOL authoritative, then verify that the restored data is from before the damage. You attest to this.
Reset and secure the domain: apply the breach resets if the security breach flag is set, seize the domain-wide operations master roles, remove the metadata of the domain's other domain controllers, repair DNS, raise the RID pool, reset the domain controller's machine account password twice, reset krbtgt twice while the domain is still isolated, and reset each of the domain's trusts on both sides.
Reconnect the domain to the production network and the rest of the forest. This is a point of no return that you acknowledge.
Check health: inbound replication from the live forest converges and dcdiag passes.
Confirm that the default administrator of every domain in the forest is enabled and its password known, because the next step can briefly disrupt logons that need a global catalog.
Reconcile every global catalog outside the domain, one site at a time. By default, lingering objects are removed with each global catalog staying online, in advisory mode first. For small forests you can choose instead to unhost the domain's partition from every global catalog and rehost it.
If the security breach flag is set, re-create the domain's group managed service accounts under a new KDS root key, before any domain controller is rebuilt.
Add the global catalog back on the restored domain controller if it was one, take a fresh backup of it, rebuild the domain's other domain controllers, clean up and set the new DSRM password you supplied, and produce and email the recovery report of manual follow-ups.

A domain recovery is refused when:

The domain is the forest root. Domain recovery never seizes the forest-wide roles, which live in the root, so recovering the root is a forest recovery.
The forest has only one domain. Recovering it is a forest recovery.
A global catalog outside the domain has no DC agent. The reconciliation runs through the agent on every global catalog.
Another recovery in the same forest, whether of the forest or of any domain in it, is already active.

Whole forest

Use a forest recovery when the forest as a whole cannot be trusted or does not work, for example after a ransomware attack or a compromise of the forest root. Every domain is brought back from backup on isolated targets, the forest root first and each child domain after its parent. Only when the recovered forest has passed its health checks and been backed up is it reconnected to production.

In the plan, you choose for each domain controller whether it is restored, rebuilt, or excluded. An excluded domain controller is neither restored nor rebuilt: its metadata is removed from the directory along with the domain's other domain controllers, and it is not brought back, so keep the machine off the network. By default, in each domain, the connected writable PDC emulator is restored and every other domain controller is rebuilt, except domain controllers excluded from protection, which start as excluded. You also give at least one external time source reachable from the isolated network, and choose whether to set the security breach flag.

Forest recovery phases

A forest recovery runs in these phases:

Prepare—Plan, clear every hard check, and approve. Isolate every restore target from production on a recovery network that still reaches the Manager and the storage machine.
Restore each domain—Forest root first, then each child after its parent: restore one domain controller and verify that its data is from before the damage.
Fence each domain off from its old state—Seize the operations master roles, remove the other domain controllers' metadata, repair DNS, raise the RID pool, and reset the machine account and krbtgt passwords. If the security breach flag is set, also apply the breach resets and reset every trust; without it, no trust is reset, and each side keeps the trust password its own restore point holds.
Bring the forest together—Join the restored domain controllers on the isolated network, pass the forest health check, add the global catalog back, and take a fresh backup of every restored domain controller.
Go live—Reconnect to production. This is a point of no return.
Finish—Rebuild the remaining domain controllers, clean up and set the new DSRM password you supplied, and produce and email the recovery report of manual follow-ups.

Some steps are carried out or checked by you rather than by the agents; the plan waits for you to attest to them, unless it was built to run unattended. A trust reset carried out by hand, such as this forest's side of an external trust, always waits for a person. For every step and what it needs from you, see Recovering a Forest.

A forest recovery is refused when:

The forest root domain is not known.
No external time source is given.
The designated global catalog is not a restored domain controller of the forest root.
Another recovery of the same forest is already active.

Refusals shared by domain and forest recovery

These checks apply to every domain in a domain or forest plan:

Every domain in scope must restore one writable domain controller with a usable restore point.
A read-only domain controller can only be rebuilt or excluded.
Every restore needs a restore point, and something to carry it out: the domain controller's own agent, or a candidate machine bound to it.
A DC state recovery can only restore in place. Use full system recovery for a candidate machine. In a plan, a DC state recovery is non-authoritative and names nothing to roll back.
Exactly one domain controller per domain is restored from backup, with or without the security breach flag. The others are rebuilt, and replicate the whole directory from the restored one.
A machine bound to a restored or rebuilt domain controller must be a candidate: an enrolled DC agent on a machine that is not itself a domain controller. Each machine can be bound to only one domain controller.
Two domain controllers cannot be planned onto the same isolated address.
The RID pool increase must be positive.

Advisory findings include restore points from different backup windows (more than 6 hours apart), which Microsoft warns can introduce lingering objects; rebuilds with no machine bound yet; trusts whose far side must be reset by hand; and, in a forest plan without the security breach flag, trusts whose two sides are restored from points 30 days or more apart. For a domain controller restored onto a candidate machine, the plan also checks the candidate's firmware and disks against the restore point, when the plan is built and again at approval; a blocking result refuses approval. For every check, see Preflight Check Reference.