Recovery Procedures
This chapter gives the step-by-step procedures for recovering Active Directory with Cygna Forest Recovery, from one domain controller to a whole forest. Each procedure lists what you need before you start, the exact console steps, what happens while the recovery runs, how to stop it, and the equivalent cdr commands. To decide which procedure fits, read Choosing a Recovery Approach first.
Pick the procedure
| Situation | Procedure |
|---|---|
| Changes to accounts, groups, or other objects have replicated across a healthy domain and must be undone, for example a mass password reset. A domain controller of the domain still starts Windows, and you have its backup from before the changes. | Restoring a DC with DC State Recovery |
| One domain controller's directory or Windows installation is damaged or untrustworthy, but the machine can still start Windows once. | Full System Recovery in Place |
| One domain controller will not start, or its hardware or virtual machine is gone. | Full System Recovery onto a Candidate, or, on Hyper-V, Full System Recovery onto a New VM |
| Every domain controller of one domain is lost or compromised, and the forest root and the other domains are still running. | Recovering a Domain |
| The forest root domain is lost, the whole forest is compromised, or the forest has only one domain. | Recovering a Forest |
A single-DC full system recovery is non-authoritative: the machine returns to its backup and then catches up from its healthy peers. A single-DC DC state recovery is authoritative for the subtrees and objects you name: they go back to the backup on every domain controller of the domain, and everything else catches up from the peers. Do not use either when the whole domain is suspect. If a domain controller cannot be restored, for example a read-only domain controller or one whose operations master roles were seized by another domain controller after its backup, rebuild it instead: remove it from the directory and promote a new domain controller. For more on the scopes, see Recovery Scopes.
How every recovery runs
All procedures follow the same stages, shown as a stepper at the top of the recovery's page:
- Plan—you choose what to recover, from which restore point, and onto which machine. Planning writes nothing to any machine.
- Preflight—the Manager checks the plan against the restore point and the live estate. Hard checks block approval; advisory checks tell you what the recovery costs; a restore can also raise checks the approver must accept by name. A domain or forest plan's checks of candidate machines run again at approval. See Preflight Check Reference.
- Approve—an operator with approval rights records that the plan has been reviewed.
- Execute—an operator with execution rights starts the recovery and confirms it by typing a name.
- Monitor (or Run)—you follow progress and respond when the recovery waits for you. A domain or forest plan can instead run unattended, and can email its halts, waits, and final recovery report.
Approval and execution are separate capabilities. The Restore Operator role holds both; no other role, including System Admin, can run a recovery. You can split them between two people so that every recovery is seen by two operators. Every action is recorded in the audit trail. For the full lifecycle, see Recovery Lifecycle.
While a recovery runs, a banner on every other console screen links to it and says when a recovery is waiting for you.
Before any recovery
- Read Recovery Requirements and confirm the requirements for your procedure. For a domain or forest recovery, also prepare the isolation described in Isolating Recovery Targets.
- Know what the recovery does not bring back, such as certificate services or DHCP on the same machine. See What Recovery Does Not Cover.
- If the incident is an attack, choose restore points from before the compromise.
