Active Directory forest recovery, part 1: planning, backups and readiness

A forest-wide Active Directory failure is rare, but when it happens every sign-in, file share, mail flow and management tool stops with it. Whether you are back in hours or in days is decided long before the incident: by the backups you kept, the passwords you can still find, and whether anyone has ever practiced the restore. In this post I'll cover when a full forest recovery is (and isn't) the right answer, and how to get your backups, documentation, people and lab ready for it. Part 2 walks through the step-by-step execution.

When a forest recovery is (and isn't) the right call#

Restoring a forest means rolling every domain back to the moment of its backup and rebuilding every other domain controller (DC). That makes it the last option, not the first one. Microsoft positions it as the answer only when a forest-wide failure leaves the DCs unable to work normally and other remedies have been ruled out, ideally together with Microsoft Support.

Situations that can justify it:

• Every DC is logically corrupted or physically damaged and AD-dependent applications no longer work.
• A script, a bad schema extension or a rogue administrator has spread damage to the directory across the whole forest.
• An attacker has planted malware on DCs and support has advised a restore from backup.
• No DC can replicate, no change can be written anywhere and no new DC can be promoted.

Situations that usually don't:

• One or a few DCs are broken while others are healthy. Repair or rebuild the broken ones; see my replication error codes quick reference.
• Deleted objects or OUs. Use the Active Directory Recycle Bin or an authoritative restore of the affected subtree.
• A DC backup or database copy was exposed, but the leaked credentials haven't been used to change anything. Resetting passwords for users, computers, trusts and (group) managed service accounts can be enough.
• Damage limited to one domain of a multi-domain forest. Microsoft documents a separate single-domain recovery path.

Prerequisites: what has to exist before the bad day#

Beyond the backups, passwords, documentation and network covered in the steps below, you need a written recovery plan that covers forest, domain, object and SYSVOL recovery and is reviewed at least once a year. Also make sure anything that protects DC disks, such as BitLocker recovery keys, can be retrieved without Active Directory.

Step 1: Back up the right DCs, often enough#

Back up at least two writable DCs in every domain on a schedule, so you can fall back to a second backup if the first one fails to restore. A read-only DC (RODC) backup can't be used to restore a writable DC, so don't count RODCs. Use an Active Directory-aware tool such as Windows Server Backup; a hypervisor snapshot alone is not a substitute.

Capture both a system state backup (which holds the directory database and SYSVOL) and a full server or bare-metal backup if you may need to restore onto different hardware. A system state backup can't be restored onto a fresh Windows installation or another server.

REM System state backup of a DC to a dedicated backup volume
wbadmin start systemstatebackup -backuptarget:E:

REM List the backups you can restore from
wbadmin get versions

Backup age matters. A backup is only usable within the tombstone lifetime (or the deleted object lifetime, if the Recycle Bin is enabled, whichever is shorter). Check the value instead of assuming the default:

$config = (Get-ADRootDSE).configurationNamingContext
Get-ADObject "CN=Directory Service,CN=Windows NT,CN=Services,$config" -Properties tombstoneLifetime |
    Select-Object tombstoneLifetime

Keep a local copy for speed and an offline or immutable copy that a domain admin can't delete. Log AD DS health daily so you can later tell when the damage started.

Step 2: Secure the passwords you will need#

You need the password of a Domain Admin account in every domain (preferably the built-in Administrator) and the DSRM password of each DC you might restore. Archive the history of both for as long as your backups are valid: a two-month-old backup needs the DSRM password from two months ago.

To make DSRM passwords manageable, synchronize them with a dedicated domain account in advance. Run this on each DC:

ntdsutil "set dsrm password" "sync from domain account DSRMSync" q q

Keep them in an offline vault that doesn't need Active Directory to open.

Step 3: Document the forest#

Write down the structure you will rebuild. For each domain, list every DC with:

Add the trusts (direction, type, partner domain), the DNS zones and forwarders, and the applications that write to AD: Microsoft Entra Connect or Entra Cloud Sync, Exchange Server, Configuration Manager, PKI and backup software. The forest root list matters most, because the root domain is recovered first.

Step 4: Choose the DC to restore in each domain#

You restore exactly one writable DC per domain and rebuild the rest. Ideally, nominate a dedicated restore DC per domain and test with it, so the real recovery uses the same configuration you rehearsed. Good candidates are:

• Writable (mandatory), with a good full server backup.
• Virtual, on a hypervisor that supports VM-GenerationID, so it can later be the source for cloning.
• Running a current Windows Server version with the desktop experience.
• A DNS server that hosts the forest and domain zones.
• Easy to isolate, typically in a datacenter.
• Not dependent on BitLocker Network Unlock as its only key protector: on the first restored DC there is no working AD to unlock it.

Don't pick a FSMO role holder just to avoid seizing roles; you seize all roles anyway. The exception is SYSVOL: the PDC emulator usually holds the best copy of the Group Policy files. Choose a backup taken a few days before the failure: newer backups lose less data but are more likely to contain whatever caused the failure.

Step 5: Prepare an isolated recovery network#

The restored DCs must never talk to a surviving, possibly damaged writable DC. Plan for this up front:

• A virtual network or VLAN with no route to production, sized for one DC per domain plus admin workstations.
• Out-of-band or remote management access to shut down every writable DC, including those in remote sites.
• A time source for the forest root PDC emulator inside the isolated network.

RODCs can keep serving cached sign-ins in branch sites during the recovery, because no DC replicates changes from them. They are rebuilt once the writable DCs are back.

Step 6: Assign roles on the recovery team#

Name people, and a deputy for each, before you need them:

• Incident lead: owns the go/no-go decision, the chosen backup date and stakeholder updates.
• AD recovery engineers: one per domain, following the runbook in order.
• Backup and virtualization admins: locate backups, restore VMs and manage snapshots.
• Network team: builds and polices the isolated network and the reconnection.
• Security team: decides which credentials, trusts and gMSAs must be reset if the cause was an attack.
• Application owners: Entra Connect, Exchange, Configuration Manager and others, ready for their own clean-up.

Step 7: Test the plan in a lab#

Practice at least once a year, and again after major changes such as new domains, OS upgrades or changes to Enterprise Admins or Domain Admins membership. Restore real production backups into a fully isolated lab, follow the runbook word for word, time each phase and fix the gaps. It is also the only real proof that your backups restore.

Verify your readiness#

You are ready when you can answer yes to each of these:

• Every domain has at least two writable DCs with restorable backups younger than the tombstone lifetime.
• The DSRM and Administrator passwords for those backups can be retrieved without Active Directory.
• The forest map, FSMO layout and trust list are current, and a restore DC is named per domain.
• The isolated network exists and the team has restored the forest in the lab within the last year.

Tips and gotchas#

• Include the Microsoft Entra Connect server in your plan; a staging server lets you preview changes before anything reaches the cloud.
• Agree up front who recovers Exchange and Configuration Manager; see the Exchange Server outage recovery guide and the Configuration Manager site recovery guide.
• If the cause may be a compromise, plan to create a new KDS root key and recreate gMSAs after recovery.
• Keep the SYSVOL health checks handy: SYSVOL DFSR event IDs.

References#

• Active Directory forest recovery guide
• AD Forest Recovery - Prerequisites
• AD Forest Recovery - Determine how to recover the forest