Active Directory Forest Recovery: Authoritative Restore, RID Pool and DC Order

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

In a forest recovery you restore one writeable domain controller (DC) per domain in isolation, forest root first and parents before children. You restore the directory on that DC nonauthoritatively and SYSVOL authoritatively. Then you seize the operations master roles, remove the other DCs from the directory, raise the RID pool and reset the critical passwords, and only then build the remaining DCs as new ones.

This is a planning and evidence guide, not an executable forest-recovery procedure. No recovery was lab tested here. Role seizure, metadata removal, credential resets and SYSVOL changes require a version-specific plan validated in isolation with qualified identity specialists and Microsoft Support, as the source guide assumes.

Recommendations and interpretations are editorial unless attributed; source research is not lab validation.

Why it matters

A forest recovery rolls every domain back to its last trusted backup. Microsoft lists what is lost: objects added after that backup, updates to existing objects, and configuration or schema changes. It also says that in many cases forest recovery should be the last option, and assumes you have reached that conclusion with Microsoft Support.

Know the limit of the source before relying on it. Microsoft states that its guide does not cover security recommendations for recovering a forest that has been hacked or compromised, although the procedure includes credential steps for that case.

If only one domain is damaged in a multi-domain forest, Microsoft has a separate approach, and it creates its own problem: the global catalogs elsewhere hold newer data for that domain than the restored DC does.

How it works

Three uses of "authoritative"

The word causes real mistakes, because it means different things depending on what it refers to.

The third is for accidental deletions. Microsoft Support says the most common method is the AD Recycle Bin. Where that is not available, it describes a selected-object authoritative restore and a separate backlink-restoration stage for group memberships. The operation raises the version number of the restored object so that it beats the tombstone, the deleted-object marker that replication carries. That documentation, scoped to Windows Server 2008 and 2008 R2, says it should not be used to restore an entire DC. Where the Recycle Bin is enabled, deleted objects can be restored from it within the deleted object lifetime. Enabling it cannot be undone.

The authoritative SYSVOL restore is needed because SYSVOL replication must be restarted, and every later DC synchronises from the copy you chose.

Before you start: the inputs you cannot improvise

• Backups. Microsoft says to back up at least two writeable DCs per domain. A backup of a read-only DC (RODC) cannot restore a writeable DC.
• Passwords. You need a Domain Admin password for each domain, and the Directory Services Restore Mode (DSRM) password to perform a system state restore. Microsoft says to archive the Administrator account and DSRM password history safely for as long as the backups are valid. The password that opens a backup is the one in force when it was taken, so today's password may fail on an older backup.
• BitLocker keys, if DC volumes are encrypted, must be available.
• Backup age. Microsoft treats a backup as valid within the tombstone lifetime, or the deleted object lifetime if that is shorter and the Recycle Bin is enabled.
• Backup type. A system state restore needs a backup that explicitly includes system state. Microsoft says a full server backup used for full server recovery will not work for this, while a bare-metal recovery backup contains system state. The FAQ notes that bare-metal recovery is binary-based and completes much faster than a system state restore.
• Same server. Restoring system state to a different server is not recommended, and restoring it to a new Windows installation is not supported. For different hardware, plan a full server recovery, then the authoritative SYSVOL synchronisation. That route has conditions: the target needs the same number of drives, each the same size or greater, it starts from the operating system media, and a Hyper-V DC restoring from a network location needs a legacy network adapter.

Choosing the backup and the DC

Microsoft recommends backups taken a few days before the failure and describes a trade-off: newer backups hold more data but carry more risk of reintroducing the problem. If the failure time is unknown, you can use Dsamain.exe to mount backups or ntdsutil snapshots and inspect them over LDAP before committing to one.

Microsoft lists what to look for in the first DC:

Microsoft recommends a dedicated DC per domain as the preferred restore target. Restoring an operations master holder for simplicity is not recommended, as you seize all roles anyway. The PDC emulator's backup is the exception for SYSVOL, since it typically has the best copy.

Virtual machine snapshots are a permitted route for the nonauthoritative restore only where the host supports hypervisor Generation ID, and the guide's FAQ says they are not the recommended approach. A DC rolled back by unsupported means can suffer USN rollback, logged as Directory Services event 2095.

The first DC in each domain

Start with the forest root, because it holds Schema Admins and Enterprise Admins and usually the root DNS. You may recover several domains at once, but always a parent before its child. Microsoft's preferred scenario shuts down all writeable DCs before the first restored DC returns, so that damaged data cannot replicate back in. Read-only DCs can keep running, because no other DC replicates changes from them.

Translate Microsoft's published order into a reviewable recovery plan with these gates. This table describes the dependencies; it is not a command sequence.

The SYSVOL scope needs explicit resolution. Microsoft's procedure is repeated for each domain and refers to the first writeable DC in that domain, while a warning on the SYSVOL page names the first DC in the forest root. SYSVOL replicates within a domain; our reading is that each domain requires one intended authoritative source, never competing sources. Confirm that interpretation and the precise method with Microsoft Support for the planned topology before execution.

A bare-metal recovery, a system-state restore and a supported VM rollback do not all initialise SYSVOL in the same way. The plan must state which route was used and which follow-on DFSR operation it requires. DFSR event 4602 is relevant evidence for authoritative initialisation; an absent event is a reason to investigate, not to set a readiness flag until the underlying state is understood. Older FRS-based domains need their separate supported path.

Role and metadata changes deliberately invalidate the old topology. A machine that was previously a role holder may wait for initial replication, which is unavailable in the isolated first-DC stage. Microsoft's guide addresses that dependency, but changing its registry control without the complete recovery procedure can remove an important protection. Record the temporary setting and its restoration as reviewed actions rather than copying a registry value from an article.

The credential work also needs a case-specific schedule. Microsoft's initial recovery list includes machine-account and krbtgt resets; suspected intrusion adds administrative-account work. Compromise of the directory database may require KDS-root-key and group-managed-service-account recovery. Those tasks do not replace shutting down dangerous writeable peers.

Global-catalog removal can affect sign-in, so establish the supported administrative access path before making that change. The goal is to prevent lingering objects from different backup dates while maintaining controlled access for recovery staff. Do not make a broad authentication exception merely to get past a failed login.

RID pool: why two separate steps

Every new user, group or computer gets a security identifier (SID) ending in a relative ID (RID). After a rollback, the RID master has forgotten what it issued after the backup, so it could issue those RIDs again.

Microsoft gives a concrete risk. A user created after the backup no longer exists after the restore, but permissions granted to that SID may persist. If the RID is reused, the new object inherits that access.

Raising the pool moves the starting point of the domain's future allocations. It is done on CN=RID Manager$,CN=System,DC=<domain>, by adding 100,000 to the rIDAvailablePool attribute in ADSI Edit or LDP. The value is a large integer. In Microsoft's example, 4611686014132422708 has a low part of 2100 (the next pool to be allocated) and an upper part of 1073741823 (the total RIDs available). Adding 100,000 gives a new low part of 102100.

Microsoft says to use a larger increase only if you have reason to, choosing the lowest safe value, since RIDs are finite. The global limit is about 1 billion RIDs by default, or just over 2 billion once the 31st bit is unlocked, a deliberate action Microsoft says is "intended only to prevent running out of RIDS". Repeated recoveries consume the pool.

Invalidating the pool deals with the block this DC already holds, so it cannot reissue RIDs from the backup era. A system state restore does this for you. Otherwise, the plan must include Microsoft's version-specific local-pool invalidation operation. It changes directory allocation state and is not included here as an untested script.

Success logs event 16654. The first object you then create will fail with an error, and the retry succeeds. Expect that.

krbtgt and the waiting period

The krbtgt account's password history holds two values, so two resets clear the pre-failure password and stop another DC replicating with this one using an old password.

Microsoft's procedure page says you must wait 10 hours between the resets, which is the default maximum ticket lifetime, or longer if that policy has been raised. The summary list in the initial recovery page does not mention the wait. The krbtgt account is per domain, so plan the wait in each domain. Microsoft's page does not say whether steps 13 to 15 and the reconnection can go ahead during the wait, so settle that in rehearsal or with Microsoft Support.

The procedure applies to writeable DCs, not RODCs. If you plan to recover an RODC, do not delete its krbtgt_<number> account. A custom password filter such as passfilt.dll can make the reset fail, and the page links a workaround.

Reconnect, verify and redeploy

Join the restored DCs to a common network that is still isolated from everything else. Physical DCs may need new addresses there, which makes their DNS records wrong, and secure dynamic updates fail until a global catalog exists. Virtual DCs can join a new virtual network without that change. Then run these checks:

repadmin /replsum
repadmin /viewlist *
nltest /DCList:<domain>
dcdiag /v

For SYSVOL, event 4602 shows replication was initialised. Event 4614 means the DC is waiting to perform initial replication. If 4602 does not appear on a DFSR-replicated SYSVOL, the page gives next steps. For event 4612, use the event-specific Microsoft investigation and recovery procedure. Setting a readiness flag alone does not prove that SYSVOL is correct.

After that, add the global catalog to a DC in the root with repadmin.exe /options DC_NAME +IS_GC. It is not advertised until it has fully synchronised, so force replication and watch for event 1119. Global-catalog unavailability can prevent normal logon and universal-group evaluation; exceptions and cached behaviour depend on the environment.

After validation, Microsoft has you join them to the production network and repeat the health checks, creating DNS delegation records and configuring forwarding as needed.

You now have one DC per domain. Microsoft says to make a new backup of each at this point.

Install the remaining DCs as new DCs, by reinstalling AD DS or cloning. Existing backups of those DCs cannot be reused, because their metadata was removed during the recovery. Virtualised DC cloning needs a hypervisor that supports VM-GenerationID, membership of the Cloneable Domain Controllers group and an available PDC emulator. Set each new DC's preferred DNS server to the first restored DNS server in the root domain. Rebuild all RODCs too, and when removing AD DS from an RODC, retain the DC metadata.

What to choose and why

Rehearse it. Microsoft says to practise at least once a year and after membership changes to Enterprise Admins or Domain Admins. There is no end-to-end automation.

Risks and limits

• Older source. The explanation of version numbers and the DSRM boot note come from archived 2008 documentation. The object-level syntax is from the current Microsoft Support article.
• Trust clean-up. External trusts are not restored automatically and objects created after the backup must be recreated. Afterwards, revert the DNS configuration and delete WINS records for DCs that were not recovered.
• Applications. Anything that stored a SID, or that used an account password changed after the backup, will need attention.
• Not covered: Entra hybrid synchronisation, Server Core specifics and third-party recovery products.

Sources

Opened 2026-11-10.

• Microsoft Forest Recovery Guide: Steps to restore the forest, Prerequisites, Devise a plan, Identify the problem, Determine how to recover, Perform initial recovery, Nonauthoritative restore, Authoritative SYSVOL, Full server recovery, Seize a role, Clean metadata, Raise RID pool, Invalidate RID pool, Reset computer account, Reset krbtgt, Reset trust, Remove global catalog, Verify replication, Redeploy DCs, Virtualization, Cleanup, Single domain, FAQ
• Microsoft: Managing RID issuance, USN rollback, Golden gMSA, Recycle Bin
• Microsoft Support: Restore deleted accounts and groups. Windows Server commands: wbadmin start systemstaterecovery
• Archived Windows Server 2008/R2: Authoritative restore of objects

This article was originally published on 10 November 2026.