Overview
Active Directory (AD) is the centralized directory that manages user identity, authentication, and authorization across your entire organization. When your AD forest fails due to ransomware, accidental deletion, or schema corruption, no users can log in and business operations grind to a halt.
Druva's Automated Forest Recovery replaces Microsoft's complex manual recovery process with a guided, orchestrated workflow. Instead of running dozens of PowerShell commands and configuration steps, Druva automates most of the recovery work while keeping you in control at key decision points.
❗Important:
Ensure that you have the latest version of the Microsoft Active Directory agent installed for a successful Forest Recovery. Click here to download and install the latest Druva Active Directory agent.
Forest recovery is a major, largely irreversible operation. Ensure you have the necessary administrative permissions, have carefully reviewed all settings, and have confirmed this is the right recovery path before starting.
Imagine an attacker gains enterprise domain administrator access to your Active Directory and modifies the forest schema, deletes critical user accounts, and replicates these changes across all domain controllers. Your entire organization can no longer log in.
With Druva’s Advanced Automated Forest Recovery Process, you :
Isolate all domain controllers from the network to stop further damage.
Perform required prerequisites.
Launch the Druva Automated Forest Recovery Wizard
Initiate the recovery workflow within the Druva console to begin the orchestrated restoration of the Active Directory forest.
Select the Pre-Incident Known-Good System State Snapshot
Choose an uncompromised System State / Active Directory restore point generated prior to the security incident to avoid reintroducing malicious persistence or compromised credentials.
Configure Target Settings for Domain Controllers across Selected Domains
Specify the target host parameters, isolated staging VLANs, and network configuration settings for each domain controller (DC) within the targeted domains.
Execute Dual KRBTGT Account Password Reset
Select the option to perform a double reset of the KRBTGT account password to invalidate all existing Kerberos Ticket Granting Tickets (TGTs) and remediate potential Kerberos-based persistence.
Initiate Orchestrated Recovery and Monitor Progress
Execute the automated recovery process—allowing Druva to restore the primary DC, isolate replication topology, reset RID pools, and update metadata—while actively monitoring execution logs.
Re-promote and Replicate Additional Domain Controllers
Once the authoritative primary Domain Controller (PDC Emulator) is successfully restored and verified, promote additional Domain Controllers into the restored domain via standard AD DS installation (
Install-ADDSDomainControlleror IFM) to rebuild full domain redundancy.In hours (instead of days of manual work), your forest is restored and users can log in again.
Without Druva backups in place, recovering from this scenario would be extremely difficult or impossible.
Pre-requisites for automated forest recovery
❗Imporant: It is highly recommended to ensure that at least one recent snapshot or backup is available using the new Active Directory agent version 2.0.0.
Common Pre-requisites for forest recovery
These prerequisites apply to all recovery scenarios:
DSRM Password
Ensure the DSRM password is known. If it is not, reset the password immediately using the following command:
ntdsutil
set dsrm password
reset password on server <DCName>
quit
quit
Pre-Incident Documentation
The following information must be captured while the forest is healthy and stored in a secure offline location (physical binder or encrypted password manager).
Entity | How to capture | Why does it matter? |
FSMO role holders |
| Identifies which DC holds each role |
Global Catalog (GC) server names |
| GC must be restored first |
DC hostnames and IP addresses |
| Required for network configuration during restore |
Domain SID |
| Validates identity after restore |
Backup snapshot dates | Druva Console | Selects the correct restore point |
OS version and build number |
| Required if restoring to a new machine |
Before a forest failure, if the necessary documentation has not been collected, execute the following command on a healthy Domain Controller (DC):
netdom query fsmo
Get-ADDomainController -Filter * | Select Name, IPv4Address,
IsGlobalCatalog, OperatingSystem, Site
Required Access and Credentials
Access Required | Details |
Enterprise Admins credentials | Full forest-level administrative access |
DSRM password | Required to boot into Directory Services Restore Mode |
Druva Console access (Cloud Admin role) | Required to initiate system state restore from cloud |
Built-in tools on every Domain Controller (DC)
No additional software installation is required. The following tools are available on every Windows Server Domain Controller:
dcdiag, netdom, nltest, repadmin, wbadmin, ntdsutil, nslookup, w32tm
Once you have ensured the pre-requisites are met, perform the following steps based on the scenario you are in.
Scenario 1: Forest Recovery on the Same Machine
The original DC hardware is available. No additional machine-preparation steps are needed.
Scenario 2: Forest Recovery on a Different / New/Alternate Machine
Prerequisite 1 — Match OS Version and Build
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:
[System.Environment]::OSVersion
Get-ComputerInfo | Select-Object OsName, OsVersion, OsBuildNumber
If the build does not match the original DC:
Install the exact same Windows Server version.
Apply the same cumulative updates to match the build number.
Then proceed to Prerequisite 2.
Prerequisite 2 —Match Hardware and Disk Size
The new machine's disk configuration must be compatible with the original DC.
Get-Disk | Select-Object Number, Size, PartitionStyle
Get-Volume | Select-Object DriveLetter, Size, SizeRemaining
The system drive (C:) must be equal to or larger than the original DC's system drive.
If the original DC had separate drives for the NTDS.dit database or transaction logs, create matching drive letters with sufficient space.
Prerequisite 3 — Stop Windows Update
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.
Stop-Service wuauserv -Force
Set-Service wuauserv -StartupType Disabled
Verify it is stopped:
Get-Service wuauserv | Select-Object Name, Status, StartType
Also disable auto-updates via registry:
reg add
"HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v NoAutoUpdate /t REG_DWORD /d 1 /f
Prerequisite 4 — Verification Before Proceeding
Check | Command | Expected Result |
OS version matches original DC |
| Same version |
Build number matches original DC |
| Same build |
Windows Update stopped and disabled |
| Stopped, Disabled |
Disk space is sufficient |
| Equal or larger than original |
Role required
In order to trigger automated forest recovery, you should be a cloud administrator in Druva portal
Druva Forest recovery runs under the domain admin. During the setup, you should configure administrative account credentials for each domain.
Your organization must have a AD Standard License.
Target servers - You can choose a current server or a brand new server as the recovery host. Please note that each recovery target must have:
The latest Druva Active Directory agent installed and connected. Click here to download and install the latest Druva Active Directory agent.
A clean Windows Server installation (not running production workloads) with the same OS version and build number as the original domain controller’s backup.
Sufficient disk space for staging backup data (specified by your shared folder path).
How Automated Forest Recovery Works
Druva guides you through a structured 6-step workflow:
Step 1: Preparation and Isolation (Your Action)
📝Note: This is exclusively required during Alternate Host Recovery.
You prepare your environment for safe recovery:
Isolate domain controllers from your production network to prevent further corruption or re-infection.
Stop replication on all domain controllers to freeze the compromised state.
Verify recovery environment — Ensure target servers are clean, isolated, and ready.
Identify last known-good backups — Druva shows available snapshots for each domain.
Prepare for your primary DC to run initial recovery. Other DCs will be added to the domain once the recovery process is completed.
Step 2: Target Host Mapping (Your Action)
For each domain you are recovering, designate where it should be restored:
Original Host: Restore on the same physical or virtual machine (default option).
Alternative Host: Select a different, clean server from your available infrastructure. Provide the Hostname details. You can select either the available hostnames or you can add and register a new host.
Note that the scope is restricted to domain registration only, excluding domain configuration and management. Check the pre-requisites.
Connection status and agent version verification: Druva checks that the latest agent is installed and connected on your chosen target server. If in Not Connected state, use the Sync Now option to sync the connection and agent version status. If not, upgrade the agent.
Step 3: Recovery Configuration (Your Action)
Select snapshots and provide credentials for each domain:
Snapshot selection: Choose the last known good backup point for each domain to continue with recovery configuration.
Shared folder path — Specify a network location with sufficient disk space to stage recovery data. The path must be restricted to the local machine and configured in one of the following two formats:
Drive Root Only: C:\ (nested folders are not permitted when specifying the drive directly)
UNC Path: \\127.0.0.1\c$\backup (nested folder locations are supported when using this method)
Note that all configurations must target the local machine exclusively and cannot point to a shared network path.
Credentials: This can be for Original Host or Alternative Host based on selection in Step 2.
Domain credentials: Provide domain administrator and password (from the time the snapshot was taken). This can be for Original Host or Alternative Host based on selection in Step 2.
DSRM credentials: Provide the Directory Services Restore Mode username and password for booting into recovery mode.
Step 4: Recovery Policies (Your Action)
Configure how your forest should be reconstructed. You choose:
DNS Recovery:
Use existing settings: Restore DNS configuration from your backup.
Auto-configure: Druva configures the root domain DC as the DNS server for the forest.
Enter IP address: Specify a custom DNS server IP.
Global Catalog:
Preserve existing configuration: Keep the current global catalog settings from your backup.
Disable and rebuild automatically: Temporarily remove the GC role, then rebuild it on recovered DCs.
Metadata Cleanup for unselected domains:
Preserve: Keep existing metadata and clean up manually later if needed.
Remove automatically: Automatically clean up metadata for domains not being recovered.
Kerberos Ticket (KRBTGT) Password:
Keep current: Use the existing password.
Reset: Generate a new password to invalidate all Kerberos tickets (recommended after security incidents).
Trust Password:
Keep current: Use the existing password.
Reset: Reset passwords for all trust relationships (recommended after security incidents).
Step 5: Execute Recovery (Automated by Druva)
Once you click Start Recovery, Druva orchestrates the forest recovery automatically.
For each domain (starting with the root), the system:
Copies the system state recovery data to the chosen target machine at the path designated in step 3.
Boots the DC into Directory Services Restore Mode.
Restores the system state from your backup using wbadmin system state recovery. You must manually login with DSRM credentials.
Reboots into normal mode.
Performs metadata cleanup for unselected domains.
Removes the Global Catalog role (to be re-promoted later). This happens only if you have selected and defined the recovery policy for Global Catalog using the Disable & Rebuild automatically option.
Validates the domain controller is healthy.
Child domains are recovered in parallel after the root domain succeeds, speeding up multi-domain forests.
📝Note: The entire recovery process will fail if the root fails.
Step 6: Monitor Progress (Automated by Druva)
Track recovery status on the Jobs > All Domains and Forest Recovery tab page.
See each domain and forest's status: Running, Queued, Successful, Failed, Cancelled, Successful with Errors, or Waiting for retry.
Download detailed logs and execution steps during or after the recovery using the Download Logs option.
❗Important:
The complete job will remain in a pending state for up to 48 hours, allowing time for all required manual interventions to be performed so that the job can successfully finish.
If the necessary manual intervention is not completed within this 48-hour window, the job will ultimately fail.
Procedure
The Automated Forest Recovery wizard walks you through a guided workflow:
Log into your management console.
On the Cloud Platform dashboard, navigate to the Global Navigation icon and click Microsoft Active Directory. The Microsoft Active Directory landing page appears. Navigate to Forests.
Locate the forest you need to recover and click Recover Forest. A Forest Recovery Workflow overview modal appears, showing all recovery steps and which are automated versus requiring your action.
Target Host Mapping — For each domain, choose an original or alternative host to restore to. Druva automatically checks agent connectivity and version. If an agent is outdated or missing, you can use a Reregister button to install or upgrade it. Use Sync Now to refresh connection status.
Recovery Configuration — Select the backup snapshot timestamp for each domain (or accept the most recent) and click Configure Now. Provide the shared network folder path, domain administrator credentials (username/password from the time the snapshot was taken), and DSRM username and password.
Recovery Policies — Configure DNS recovery (auto-configure, IP address, or existing settings), Global Catalog rebuild strategy (disable and rebuild or preserve), metadata cleanup (remove or preserve), KRBTGT password handling (keep or reset), and trust password handling (keep or reset).
Review Summary — Review all your selections. The wizard displays a Forest Recovery Impact warning listing what will happen during recovery:
Active Directory replication will be suspended.
Domain controllers may be unavailable during recovery.
New backups and restores will be blocked.
Existing backup and restore jobs will be stopped.
Authentication services may be temporarily affected.
Click Start Recovery — Druva begins the automated orchestration and two types of Jobs are initiated - All Domains and Forest Recovery.
Monitor the recovery job on the Forest Recovery tab under Jobs. You can view each domain and forest name, status (Running / Queued / Successful / Failed), and timing. Expand a domain to drill into its sub-steps (Boot into DSRM mode, Restore system state using webadmin, Reboot into normal mode, Metadata cleanup, Seize FSMO role, Raise and invalidate RID pool, Remove Global Catalog, Validate DC). A Stop Recovery button is available if you need to halt the workflow; when you stop, you are prompted to provide a reason, which is logged for later review.
Manual Steps Required post forest recovery (By Recovery Location)
Depending on where you are restoring the server, follow the instructions for your scenario:
Original Host: Log in during Phase 3 using your Directory Services Restore Mode (DSRM) password.
Alternate Host: Log in during Phase 3 using your Directory Services Restore Mode (DSRM) password.
Alternate Host (Isolated Network): Log in during Phase 3 using your Directory Services Restore Mode (DSRM) password.
Crucial Action: Reconnect the Network After Recovery
Once the server is restored, it will automatically be disconnected from the internet for safety. To finish the recovery process successfully, you must manually fix the server's network settings (for example, assign it a fixed static IP address and set the correct DNS server addresses).
Fixing the network ensures the agent can communicate with the server to report its progress.
❗Important:
If you do not restore network connectivity, the system cannot verify that the job finished. The recovery process will sit stuck in "in progress" status for several hours until it times out and fails. A failure here will block any secondary (child) domains from being recovered.
Jobs page
The Jobs page is accessed by selecting Jobs from the left-hand navigation pane under the Microsoft Active Directory section.
The interface is divided into two primary tabs, each tailored to a specific scope of operations:
All Domains
Forest Recovery
1. All Domains Tab
The All Domains tab is the default view and displays tasks executed at the domain level. It shows the progress of downloading your backed-up data to the target host.
The data table in this view includes the following columns:
Job ID: A unique identifier for each task.
Job Type: The classification of the operation, such as System State Download or Granular Backup, and so on.
Domain: The specific domain associated with the job.
Start Time: The timestamp indicating when the job was initiated.
End Time: The timestamp indicating when the job concluded.
Status: The final outcome of the job. For example: Successful, Failed, Cancelled, Successful with Errors, Waiting retry.
Click on the Job ID to get a detailed view of the job. The Job Details window for All Domains tab displays summary metrics for a specific domain task—including job type, target domain, execution timestamps, administrator, and error status—while providing an option to download logs. This pop-up allows administrators to track progress, verify the completion of operations like System State downloads, and troubleshoot any runtime errors.
2. Forest Recovery Tab
The Forest Recovery tab displays a detailed, step-by-step view of the recovery process for every domain in your organization, including the main (root) domain and all secondary (child) domains.
The data table in this view modifies the scope column and includes:
Job ID: A unique identifier for the recovery task.
Job Type: Displays Forest Recovery for these operations.
Forest: The target forest for the operation, such as "pune.com" or "capCorp.local".
Start Time: The initiation timestamp of the recovery job.
End Time: The conclusion timestamp, which remains blank (indicated by a hyphen) if the job is still active or did not properly execute.
Status: The current state of the recovery process. For example: Successful, Failed, Cancelled, Successful with Errors, Waiting retry.
Click on the Job ID to get a detailed view of the job. The Job Details window for Forest Recovery tab provides a summary of the forest recovery task, including its overall status, target forest, and administrator details. It features an expandable timeline detailing each phase executed across root and child domains—such as DSRM boot, system state restoration, metadata cleanup, and KRBTGT resets—with an option to download logs.
Important Things to Know
Backups and restores are blocked during recovery: While forest recovery is running, new backups and restores cannot be triggered and existing backup/restore jobs in progress are stopped with an error. The error message states either "Forest recovery in progress. This action is blocked for now." or "Forest recovery in progress. Domain backup is temporarily unavailable," depending on where you try to initiate the operation. Once the recovery completes, backup and restore operations resume normally.
Recovery is largely irreversible: Forest recovery is a destructive, major operation. Stop Recovery halts the automated workflow and allows you to specify a reason (which is logged), but it does not roll back changes already applied to domain controllers. Plan carefully and test your recovery procedure before relying on it in production.
Detailed logging and partial-failure resilience: All recovery steps, errors, and domain-specific failures are logged and downloadable. A single domain failure does not halt the entire forest recovery; remaining domains continue to recover concurrently. Download logs from the job details page for troubleshooting from the Jobs > All Domain tab.