Active Directory (AD) Forest Recovery is a critical operation used to restore your entire directory structure in the event of a catastrophic failure or ransomware attack.

This process involves selecting specific domains, identifying healthy target hosts, and applying snapshots to restore data integrity.

📝Note: Forest recovery is a critical, non-reversible operation. Ensure you have reviewed all settings and have the necessary administrative permissions before starting.

The recovery wizard will open to the Select Domains tab. Choose which parts of your network you want to restore.

In this step, you verify the connectivity of the servers where the data will be restored.

Specify which point-in-time snapshot to use for each domain.

Before the recovery starts, you will see a final summary.

After initiating the recovery, you can track the progress of each domain restoration:

This section outlines the procedures for recovering Active Directory from Druva System State backups. It covers two scenarios — recovering a single Domain Controller and recovering an entire Active Directory forest. It is designed for Active Directory administrators and security incident response teams.

Before initiating the recovery process, use the following questions to determine the appropriate scenario and recovery path.

Step 1: Assess the Scope of the Failure

Step 2: Determine Hardware Availability (for Forest Recovery)

Here is a quick summary to help you determine the scenario and correct recovery path:

The following infographic outlines the process for selecting the appropriate recovery path.

These prerequisites apply to all recovery scenarios:

Ensure the DSRM password is known. If it is not, reset the password immediately using the following command:

The following information must be captured while the forest is healthy and stored in a secure offline location (physical binder or encrypted password manager).

Before a forest failure, if the necessary documentation has not been collected, execute the following command on a healthy Domain Controller (DC):

No additional software installation is required. The following tools are available on every Windows Server Domain Controller:

Once you have ensured the pre-requisites are met, perform the following steps based on the scenario you are in.

Scenario: The Active Directory (AD) forest remains operational and healthy. A small number of Domain Controllers (DCs) have become unavailable and require restoration using Druva backup. The remaining Domain Controllers in the forest are functioning correctly and maintaining normal replication.

Distinction from Forest Recovery: Since the forest is operational, the restored Domain Controller (DC) will automatically synchronize and replicate data from its healthy peers upon returning online. Consequently, critical post-restoration steps typically associated with a full forest recovery—such as seizing Flexible Single Master Operation (FSMO) roles, invalidating the Relative ID (RID) pool, resetting the Kerberos Key Distribution Center (krbtgt) account password, or re-establishing trusts are unnecessary.

Ensure the failed DC is ready for restore.

Verify the DSRM password is known. If unknown, reset it on a healthy DC using the following command:

Druva copies system state files (NTDS.dit, SYSVOL, registry) from cloud to the Domain Controller (DC). The Active Directory (AD) state remains unchanged at this juncture.

Initiate Forest Recovery -System State Recovery from the Druva management console. See, how to initiate forest recovery from Druva console.

Proceed directly to Phase 3; do not reboot the Domain Controller (DC) at this time.

A3.1 Boot into DSRM

Use one of the following methods:

A3.2 Apply the System State

Log in with DSRM credentials (.\Administrator with the DSRM password), then run:

After the reboot, press Enter to continue. (Note: You are still in DSRM Mode after reboot).

A3.3 Set Registry Key

Prevent the DC from waiting for an initial replication sync (it will sync from healthy peers after normal boot):

Mark SYSVOL as ready so Netlogon can advertise the DC:

Verify the change using the following command:

A3.4 Restart into Normal Mode

Exit DSRM and restart the system into normal mode.

Or use msconfig: Boot tab → Uncheck "Safe boot" → OK → Restart.

A4 Verify and Rejoin

After the restart, confirm that the following four services are operational before continuing.

A4.1 Verify Core Services

All four services must show status "Running" before proceeding.

A4.2 Force Replication from Healthy Peers

Expected: zero failures in the replication summary and no errors in showrepl output.

A4.3 Verify DNS

If SRV records are missing, restart the Netlogon service to re-register them:

A4.4 Verify DC Health

A4.5 Single DC Recovery Validation Checklist

Scenario: The entire AD forest is down or compromised. All Domain Controllers need to be recovered from Druva backups.

❗Important: Always recover the forest root domain first, followed by child domains (Parent → Child). Child domains at the same level may be recovered concurrently.

Section B is divided into two sub-sections:

The original DC hardware is available. No additional machine-preparation steps are needed.

Confirm you have the pre-disaster baseline documentation (see Pre incident documentation). If available, locate the saved baseline JSON file (e.g.,PRE_DISASTER_BASELINE_DC1.json).

Druva copies system state files (NTDS.dit, SYSVOL, registry) from cloud to the Domain Controller (DC). The Active Directory (AD) state remains unchanged at this juncture.

Initiate Forest Recovery -System State Recovery from the Druva management console. See, how to initiate forest recovery from Druva console.

3.1 Boot into DSRM

Use one of the following methods:

3.2 Apply the System State

Log in with DSRM credentials (.\Administrator with the DSRM password), then run:

After the reboot, press Enter to continue. (Note: You are still in DSRM Mode after reboot).

3.3 Set Registry Key

Registry Key 1 — Skip initial replication sync. In forest recovery, no healthy replication partner exists. Without this setting, NTDS waits indefinitely for a sync partner that will never respond.

Registry Key 2 — Mark SYSVOL as ready. Netlogon requires SYSVOL to be flagged as ready before it will advertise the DC. Since there is no DFSR partner to sync from, this must be set manually.

Verify the change:

3.4 Stop Services to Prevent Premature Activity

Stop the Group Policy client to prevent GPO processing before SYSVOL is stable:

3.5 Exit DSRM and Restart to Normal Mode

3.6 Verify Core Services After Normal Boot

Confirm all four services are running before proceeding to Phase 4:

All must show the status "Running".

Start with the forest root domain and perform these steps on the first recovered Domain Controller (DC) in each domain.

4.1 Verify FSMO Roles

Verify:

4.2 Raise and Invalidate the RID Pool

After a restore, the RID pool may overlap with RIDs that were already issued before the backup was taken. Raising the pool by 100,000 prevents SID duplication for newly created objects.

Invalidate the current pool to force the DC to request a fresh pool from the RID Master:

Verify the RID pool is healthy:

4.3 Reset Computer Account Password twice

Enter the password when prompted for each reset.

4.4 Reset DSRM Password

Security best practice — always change the DSRM password after any recovery.

Reset the DSRN password using the following command.

Enter the new password when prompted.

4.5 Reset krbtgt Password twice

This invalidates any Kerberos tickets that were issued before the disaster. Two resets are required because AD retains both the current and previous password (N and N-1) for backward compatibility.

Wait 10 seconds between resets to allow the first change to propagate

4.6 Sync Time Service

Kerberos authentication requires time to be synchronized within 5 minutes across all DCs. The PDC Emulator is the authoritative time source for the forest.

On the PDC Emulator (forest root DC):

Verify:

This phase applies only if your forest contains multiple domains.

❗Important:

Example: For a forest with root domain usa.com and child domains california.usa.com, newyork.usa.com, and chicago.usa.com:

5.1 Repeat Recovery Phases on Each Child Domain DC

For each child domain DC, repeat Phases 2 through 4 (Restore from Druva → Apply in DSRM → Post-Restore Configuration).

5.2 Validate Trust Relationships

After each child domain is recovered, verify the trust between child and parent:

If the trust is broken, reset it:

5.3 Verify Cross-Domain DNS Delegation

From the forest root DC, verify that child domain DNS resolves correctly:

6.1 Re-Enable Network Connectivity

Reconnect the DC to the network by re-enabling the NIC, plugging in the network cable, or removing firewall rules.

6.2 Verify Replication

Expected Result: Zero failures in the replication summary. No output from the errors-only command.

Check the event viewer for any warnings or failures:

6.3 Verify DNS & DC Advertising

If SRV records are missing:

6.4 Verify Global Catalog

In AD Sites and Services: NTDS Settings → Properties → check Global Catalog → OK

Check the Directory Service log for Event ID 1119; this verifies that the Global Catalog (GC) is ready.

Verify GC is advertising:

Execute this runbook on every recovered Domain Controller (DC). Do not declare the recovery complete until all listed items have passed.

For automated validation, run the project script after_recovery.ps1 with appropriate parameters (see Section 6).

Post-Recovery Actions

This section covers the additional prerequisites required when the original DC hardware is unavailable and you are restoring onto a new or different server.

📝Note: Follow Phases 1 through 7 in Section B1 after completing the necessary prerequisites mentioned below.

The new machine must run the exact same Windows Server version and build number as the original DC. A mismatch can cause the system state restore to fail or produce an unstable configuration.

Check the current OS on the new machine:

If the build does not match the original DC:

The new machine's disk configuration must be compatible with the original DC.

Windows Update must be disabled on the new machine before restoring the system state. This prevents any configuration changes (patches, feature updates) that could create a mismatch between the restored state and the running OS.

Verify it is stopped:

Also disable auto-updates via registry:

Complete this checklist before starting Phase 1 from Section B1.

Once all checks pass, proceed to Phase 1 — Prepare for Recovery in Section B1.

# FSMO roles

# Replication health

# DNS SRV records

# DC health

# Services

# GC status

# Event log errors

# Force replication