Forest recovery is for the point where ordinary replication and single-controller repair are no longer trustworthy: widespread corruption, catastrophic loss or compromise of the identity control plane.

It is not “restore the PDC from last night’s snapshot”. Microsoft describes recovery as restoring at least one writable domain controller in every domain from trusted backups, in a controlled sequence, then rebuilding the remaining forest around that state.

Prepare before the incident

Maintain an offline recovery pack containing:

  • forest/domain/site topology and one preferred restore DC per domain;
  • OS versions, roles, DNS/GC/FSMO state and unique services;
  • tested full-server/system-state backups and recovery media;
  • backup dates relative to tombstone/deleted-object lifetimes;
  • DSRM plus built-in/domain administrative credential history protected offline;
  • BitLocker/storage/hypervisor recovery material;
  • Microsoft forest-recovery procedure version and environment-specific runbook;
  • isolation networking, clean admin workstations and secure communications; and
  • owners for identity, DNS, PKI, applications and business acceptance.

Restore tests—not backup-job success—prove the pack.

Declare the recovery scope

Confirm why normal repair is unsafe and define the trusted point in time. A full recovery rolls each domain back to its selected backup: objects created later disappear and later updates to users, groups, passwords, schema and configuration are lost.

Document:

  • estimated data-loss window;
  • malicious or corrupt changes that must not return;
  • systems that must remain disconnected;
  • password/trust/key resets required;
  • business-service recovery order; and
  • authority to isolate and rebuild identity infrastructure.

If only one healthy domain/DC is affected, the dedicated single-domain or DC-rebuild path may be safer than a full forest rollback.

Select trusted backups

For every domain, choose one writable DC backup that predates the failure/compromise, remains inside supported lifetime and has passed restore validation. Prefer a recovery candidate with DNS and GC capabilities and a known reproducible configuration; Microsoft does not recommend choosing a FSMO holder merely for convenience because roles are seized during forest recovery.

Security matters as much as age. A recent backup containing an attacker or corrupt schema is not the better backup.

Isolate the recovery

Recover on a physically or virtually isolated network. Microsoft prefers all writable production DCs offline before the first recovered DC returns, preventing dangerous data from replicating into the clean forest.

Block Internet and production connectivity except tightly controlled dependencies. Use clean administrative credentials/workstations and preserve forensic evidence separately. Do not let monitoring, backup agents, sync engines or management tools reconnect automatically.

Recover the forest root first

Follow Microsoft’s current guide and the documented backup-product procedure exactly. Restore the chosen writable root-domain DC, recover AD DS/DNS/SYSVOL, seize required roles and perform the prescribed cleanup and credential resets.

Validate locally in isolation:

  • AD database and service health;
  • DNS zones/locator registration;
  • SYSVOL policy/object consistency;
  • FSMO/GC state;
  • privileged-group and persistence review; and
  • ability to create/read a synthetic object.

Do not add old writable DCs back. Rebuild additional root-domain DCs from the trusted recovered directory.

Recover each remaining domain

Restore one trusted writable DC per child/tree domain in the Microsoft sequence, then reconcile domain-specific DNS, SYSVOL, FSMO, trusts and credentials. Only after the first trusted DC works should clean additional DCs be promoted/rebuilt.

Record the chosen restore point for each domain; cross-domain objects and group membership may reflect different moments and need reconciliation.

Reset the identity control plane

For compromise, follow the incident-specific credential/key plan. Microsoft’s recovery procedures include resets for krbtgt, DC accounts and trust passwords in defined sequences. Also rotate privileged/service credentials, certificates/secrets and federation/cloud sync authorities according to scope.

Do not improvise repeated krbtgt resets without replication and ticket-lifetime planning. A reset recorded on only one isolated DC is not forest-wide protection.

Rebuild integrations from clean evidence

Reconnect services in dependency order: DNS/time, PKI, identity sync/federation, DHCP/NPS, file/app services, endpoint management, backup and monitoring. Validate each with dedicated test identities before broad production access.

Recreate rather than trust old DCs and management hosts unless the recovery plan explicitly proves them clean. Remove stale metadata/DNS for retired controllers.

Prove recovery before reconnecting users

Acceptance includes:

  • healthy replication of every naming context among newly rebuilt DCs;
  • consistent DNS and SYSVOL across sites;
  • correct FSMO/GC/time state;
  • privileged and persistence review;
  • successful synthetic sign-in, password change, Group Policy and application authentication;
  • trust, sync and mail/service tests where relevant;
  • reconciliation of changes lost after backup; and
  • a new trusted backup plus a second restore test.

Finally document the recovery point, known loss, rebuilt assets, rotated secrets, residual risk and owner acceptance.

Forest recovery succeeds when the organisation has a trusted identity system again—not when one restored DC reaches a desktop.