Active Directory forest recovery, part 2: step-by-step restore, cleanup and reconnection

You've confirmed that a full forest recovery is the right call and picked the backup to restore. Now the order of operations matters more than anything else: one wrong step can let damaged data replicate back in. In this post I'll walk through the execution in sequence, from isolating the DCs to verifying replication and reconnecting Microsoft Entra Connect, Exchange and Configuration Manager. Preparation is covered in part 1: planning, backups and readiness.

Prerequisites#

• A chosen backup per domain (writable DC, younger than the tombstone lifetime, taken before the failure).
• The DSRM password for each restore DC and Enterprise Admins, Schema Admins and Domain Admins credentials.
• An isolated network, and a list of every writable DC so none is missed.
• The forest map from your plan: FSMO holders, GCs, DNS servers, trusts and IP addresses.

Step 1: Shut down and isolate every writable DC#

Shut down all writable DCs, especially the FSMO role holders, before any restored DC comes online. Move virtual DCs to an isolated virtual network or remove their network adapters; unplug physical ones. RODCs can keep running for cached branch sign-ins and are rebuilt at the end.

Recover the forest root domain first, then the other domains, always parent before child.

Step 2: Restore the first writable DC in the domain#

The first DC in each domain gets a non-authoritative restore of AD DS combined with an authoritative restore of SYSVOL, so that every later DC takes its SYSVOL from this one. Start the DC in Directory Services Restore Mode (DSRM), for example by setting the boot flag from Windows, then run the restore:

bcdedit /set safeboot dsrepair
shutdown /r /t 0

REM In DSRM, signed in with the DSRM password:
wbadmin get versions
wbadmin start systemstaterecovery -version:10/28/2026-21:00 -authsysvol

REM After the restore, boot normally again
bcdedit /deletevalue safeboot

If you did a bare-metal or full server recovery instead, mark SYSVOL authoritative afterwards: in Active Directory Users and Computers with Advanced Features on, open Domain Controllers › <DC> › DFSR-LocalSettings › Domain System Volume, set msDFSR-Options on SYSVOL Subscription to 1, then:

Restart-Service DFSR -PassThru
Get-WinEvent -LogName 'DFS Replication' | Where-Object Id -eq 4602

Event 4602 means SYSVOL was initialized authoritatively. If the restored DC held a FSMO role, stop it from waiting for replication partners that no longer exist:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" /v "Repl Perform Initial Synchronizations" /t REG_DWORD /d 0 /f

Check that the data is good (the damaged objects or schema change are absent). If not, restore a different backup.

Step 3: Clean up the restored DC#

Seize the operations master roles#

On the forest root DC seize all five roles; in child domains seize the three domain-wide roles.

ntdsutil
roles
connections
connect to server rootdc01.contoso.com
quit
seize schema master
seize naming master
seize pdc
seize rid master
seize infrastructure master
quit
quit

netdom query fsmo

If the DC wasn't the RID master before, you're warned that it can't sync with a partner. Confirm and continue.

Remove every other DC from the metadata#

Delete each other DC of the domain from the Domain Controllers OU in Active Directory Users and Computers, ticking This Domain Controller is permanently offline. That performs metadata cleanup and removes the server and computer objects. The command-line alternative is ntdsutil › metadata cleanup › remove selected server <ServerName>. If this DC was the RID master before the failure, it won't act as RID master until the cleanup is done: System log event 16650 is followed by 16648 once it succeeds.

Fix DNS#

Make sure the DNS Server service runs. In the root domain, point the DC's preferred DNS server to its own IP; in child domains, point it to the root DC. Delete NS records of removed DCs in the domain and _msdcs zones, and speed up SRV record removal:

nltest /dsderegdns:olddc02.contoso.com

Raise and invalidate the RID pool#

Raise rIDAvailablePool by 100,000 so that new accounts never reuse the SIDs of accounts created after the backup, then invalidate the local pool:

$ridMgr = "CN=RID Manager`$,CN=System,$((Get-ADDomain).DistinguishedName)"
$rid = Get-ADObject $ridMgr -Properties rIDAvailablePool
Set-ADObject $ridMgr -Replace @{rIDAvailablePool = $rid.rIDAvailablePool + 100000}

$Domain = New-Object System.DirectoryServices.DirectoryEntry
$RootDSE = New-Object System.DirectoryServices.DirectoryEntry("LDAP://RootDSE")
$RootDSE.UsePropertyCache = $false
$RootDSE.Put("invalidateRidPool", $Domain.objectSid.Value)
$RootDSE.SetInfo()

Look for event 16654 in the System log. The first attempt to create a user, group or computer afterwards fails once, then succeeds with a new pool.

Reset the DC's computer password twice#

Reset-ComputerMachinePassword
Reset-ComputerMachinePassword

The equivalent on the DC itself is netdom resetpwd /server:<this DC> /userd:<domain\admin> /passwordd:*, also run twice. Pre-failure DCs can no longer replicate with this one.

Reset krbtgt twice#

In Active Directory Users and Computers (View › Advanced Features), right-click krbtgt in Users and choose Reset Password. The value you type doesn't matter; Windows generates a strong one. Do it twice, because the account keeps two passwords in history. Microsoft's procedure page asks for a gap of at least the maximum ticket lifetime (10 hours by default) between resets; plan that wait into your timeline. Don't touch the krbtgt_<number> accounts of RODCs.

Reset trust passwords (security incidents)#

If the recovery follows an attack, reset each trust from the trusting side with the same password on both sides. The command resets it twice by itself:

netdom trust contoso.com /domain:child.contoso.com /resetOneSide /passwordT:<TrustPwd> /userO:administrator /passwordO:*

In that case, also reset all administrative account passwords before adding DCs, and plan gMSA re-creation.

Remove the global catalog and set time#

In a multi-domain forest, clear Global Catalog in the restored DC's NTDS Settings properties to avoid lingering objects from mismatched backup dates. Single-domain forests can keep it. Configure the root PDC emulator to sync with a reliable time source.

Step 4: Repeat for each remaining domain#

Restore and clean up one DC per domain with the same sequence, parent domains before children. Domains can run in parallel once their parent is done.

Step 5: Connect the restored DCs and verify#

Join the restored DCs to one common network that is still isolated from production. Physical DCs may need new IP addresses, so fix DNS records by hand. Then check:

repadmin /replsummary
repadmin /viewlist *
nltest /dclist:contoso.com
dcdiag /v
dcdiag /test:dns
net share

Good looks like: zero failures in /replsummary, only the restored DCs in /viewlist, dcdiag passing Replications, Advertising, SysVolCheck and the DNS test, and SYSVOL and NETLOGON listed in net share.

Step 6: Add a global catalog, back up, redeploy#

Make the forest root DC a global catalog and force replication with every restored DC. It's ready when Directory Service event 1119 appears. Take fresh backups of all restored DCs now.

Then rebuild the other DCs: reinstall or forcibly remove AD DS and promote them again (old backups of those DCs are unusable), or clone virtual DCs from the restored one. Point each new DC to the first root DC for DNS, rebuild all RODCs, restore the original FSMO, GC and DNS layout, and set Repl Perform Initial Synchronizations back to 1.

Step 7: Reconnect production and clean up dependent services#

• Directory data: recreate objects created after the backup, re-create external and outgoing forest trusts, and delete DNS and WINS records of DCs you didn't recover.
• Microsoft Entra Connect Sync: verify the AD connector against the restored DCs, run a full import and full synchronization (Start-ADSyncSyncCycle -PolicyType Initial), and preview pending deletes before exporting. Users created after the backup will show up as deletions in Microsoft Entra ID. A staging server makes this safe.
• Microsoft Entra Cloud Sync: check that the provisioning agents are healthy, then restart the sync for each configuration.
• Seamless SSO: the AZUREADSSOACC account may be back to an old password; roll over its key (see my Seamless SSO guide).
• Exchange Server: follow the Exchange Server outage and switchover guide.
• Configuration Manager: follow the Configuration Manager site recovery guide.

Verify the recovery#

• repadmin /replsummary clean across all DCs, and dcdiag /e /q silent.
• netdom query fsmo shows the intended role holders.
• Users sign in, Group Policy applies, and new accounts get created without errors.
• Entra Connect or Cloud Sync exports cleanly with no unexpected deletes.

Tips and gotchas#

• Never do an authoritative SYSVOL restore on a second DC in the same domain: it causes SYSVOL conflicts.
• Keep a timestamped log of every command; it speeds up support calls and your post-incident review.
• Replication errors after reconnection? Check my replication error codes and SYSVOL event IDs quick references.

References#

• AD Forest Recovery - Perform initial recovery
• AD Forest Recovery - Procedures
• AD Forest Recovery - Redeploy remaining DCs