After a Recovery

A recovery ends when its run shows Restored or its plan shows Completed, but the directory is not fully back in service until you finish the work Cygna Forest Recovery does not do for you. Use this checklist after every recovery. The longer items apply to domain and forest recoveries; after a single-DC restore, most of the work is a fresh backup and a check of the machine's health.

Before you begin

Taking backups needs the Backup Operator role. Reviewing the audit trail needs an operator who can view it, such as the Viewer / Auditor role.
Keep the recovery's page open. Its steps, transcripts, and outcome are the record you work from.

1. Review the outcome

For a single-DC restore, open the run on the Recovery Plans screen and confirm the outcome Restored and validated. If it reads Restored, but a validation gate did not pass, check replication and dcdiag on the domain controller before you rely on it, then select Validate again. If its checks show Not checked, the restored DC agent could not make them: update the agent and select Validate again, or run cdr restore validate.
After a full system recovery that changed the restored system's address, check Post-recovery directives on the run's Preflight card. A directive that failed is also written to POST-RECOVERY-README.txt on the restored machine.
For a domain or forest recovery, confirm that every step is Done.

2. Read the recovery report and complete its follow-ups

The last step of a domain or forest recovery produces the recovery report and emails it to the plan's notification addresses, with a PDF attached. The Manager makes the PDF itself, with the PDF renderer installed beside it, so there is nothing to set up. If it cannot make one, the email goes without it. The report is built from the plan's own records each time you ask for it, so you can also open it at any time after the plan starts: select Open report, PDF, or Email… on the plan's page, or run cdr recovery report. Emailing it needs plan.execute. For the email settings, see Settings Reference.

The report has these sections:

Summary—who built and approved the plan, when it ran and how long it took, how long the directory was live on reduced domain controllers, and how many steps finished.
Domain controllers—what happened to each one, at which step, where, and from which restore point, including whether a restored domain controller came back on a current DC agent.
Manual follow-ups—the work the recovery left for you, grouped by area.
Decisions and interventions—acknowledgments, retries and what each had failed with, wait overrides, rejections, credentials supplied (by whom, never the secret), acceptances made by an unattended plan, and any abort.
Steps—every step, with its detail and each check that did not pass.

The follow-ups come only from what this plan did. Work through each one:

Plan—if the plan did not complete, the steps that did not finish. Everything else is as far as it got.
Domain controllers—on each rebuilt domain controller, the roles that were reinstalled without their configuration and data, such as Active Directory Certificate Services or DHCP, to restore from their own backups; the programs it had, to reinstall if still needed; insecure features left out, such as SMB 1.0; and anything the reinstall could not install. On each restored domain controller, colocated services to check, including directory synchronization services, which need their password synchronization run again after the krbtgt resets. A domain left on a single domain controller needs another one. See What Recovery Does Not Cover.
FSMO roles—the operations master roles were seized onto the restored domain controllers. Move them to their final placement now that the other domain controllers are back.
DNS—return each domain controller's DNS client to your final design, and remove name server and glue records, and WINS records if WINS is in use, that still name removed domain controllers.
Trusts—external and outgoing trusts are not restored from backup. Re-create them with each partner's administrator.
Agents—a restored domain controller that kept the DC agent from its backup. Update it.
Backups—take a fresh backup of every domain controller you back up, rebuilt ones first. If an unattended plan passed over the backup checkpoint, this backup stands in for it.
Unattended—any other step an unattended plan passed over without carrying it out. Carry it out by hand now.
Timing—a gap between the krbtgt resets that someone overrode. Record it if your policy required the gap.
Not confirmed—each check a step could not confirm, for example a time source the root PDC emulator could not reach. Check it by hand.

Beyond the report:

DSRM password—the plan set the new DSRM password you supplied on every domain controller it recovered. Make sure it is stored per your policy; Cygna Forest Recovery does not keep it.
Trusts after a forest recovery that was not a breach response—no trust was reset: each side kept the trust password its own restore point held. If the plan warned that the two sides of a trust were restored from points 30 days or more apart, check that the trust authenticates, for example with nltest /sc_verify:<domain>, and reset it if it does not.
Breach response only—plan the remaining password resets for users and services, and update the hosts that use the re-created group managed service accounts.

3. Take fresh backups

Backups taken before the recovery describe the directory as it was before the recovery. Take a new backup of every recovered and rebuilt domain controller as soon as it is healthy, and do not plan another recovery from an older restore point without a reason. A rebuilt domain controller's next backup also records the roles and features a future rebuild reinstalls. A backup taken while the recovery was still changing the directory is labeled with the plan and step, and restoring it raises a warning.

When a recovery plan completes, every domain controller it restored or rebuilt that has an enabled backup policy is made due for a backup at once. Each backup starts when the domain controller's agent connects; if the agent has not connected within 2 hours, the backup is refused and recorded like any other refused backup. While a recovery is still working on a domain controller, its backups wait.

On the Backup Jobs screen, check that the backup of each recovered domain controller completed. Where one did not start or did not complete, run Back up now — Full system. See Running a Backup Now.
Check that every rebuilt domain controller has an enabled backup policy; a domain controller without one is not backed up when the plan completes. See Managing Backup Policies.
After a full system recovery, install any patches released since the restore point, and then take another backup.

4. Reconnect and clean up machines

Make sure that none of the original machines a recovery replaced can return to the network. Power each one off, wipe it, or reinstall it cleanly.
Check that the DC agent on every recovered domain controller is connected on the Agents screen. If an agent restored from an old backup is behind the Manager's agent package, update it. If it trusts a previous Manager certificate authority, re-point it; see Maintaining Agents.
Record domain controllers that no longer exist as removed, and remove their backup policies. See Excluding and Retiring Objects.
If you moved a domain controller to a new subnet, add the subnet to its site and update anything that reached it by its old address.

5. Re-enable what you paused

Enable any backup policies you disabled during the incident.
Clear or update exclusions you added during the incident, so the affected objects count again.
Restore any operator accounts you disabled, and change passwords that were shared during the recovery, including the break-glass account if it was used. See Managing Operators and Roles.

6. Review the audit trail and readiness

On Monitoring > Audit Trail, filter by the recovered machines or the time of the recovery, and review every approval, acknowledgment, attestation, wait override, and abort. Keep the record with your incident notes. See Auditing Operator Activity.
On the Dashboard, confirm that each recovered domain and forest is back to fully recoverable, and resolve any alerts.
If you also run Cygna Auditor, review its change history for the recovered directory, and its Risk Radar posture assessment for privileged groups, delegation, and other settings an attacker may have changed before the backup was taken. See Related Cygna Products.

Using the command line

cdr recovery report <plan> --pdf recovery-report.pdf
cdr backup start dc01.corp.example.com --wait
cdr policy list --disabled
cdr exclusion list --active
cdr audit list --from 2026-09-02 --subject dc01
cdr alert list

See Recovery Plan Commands, Backup Commands, and Alert, Audit, and Report Commands.