Active Directory Operations and recovery
Choose a recovery scope
Work out whether you're repairing a server, replicated directory data or exposed credentials, and where the good state will come from.
Ask what is wrong, then where the good state exists
A DC that cannot boot and an incorrect value present on every DC are different failures. A healthy surviving writable replica can supply a replacement DC. It cannot supply the previous value of an attribute after the bad update has reached it.
Record three decisions before choosing a restore operation:
- Damaged state: server/OS, database pages, particular directory objects or attributes, SYSVOL files, DNS configuration, or credentials/trust.
- Replication scope: one replica, one domain naming context, an application partition’s replica set, forest-wide schema/configuration, or a GC’s partial replica.
- Repair authority: which surviving replica, backup, policy backup or independent business record supplies the intended state, and why it is trusted.
Several failing DCs don’t necessarily mean several damaged databases. A shared DNS or network fault can make healthy copies appear unavailable. Microsoft treats forest recovery as a last option after assessing the cause and possible remedies with Support. See the forest recovery prerequisites before committing to that path.
Match the unit of recovery to the damaged state
| Evidence | Candidate recovery unit | Important boundary |
|---|---|---|
| One DC has failed; appropriate surviving replicas are healthy and trusted | Rebuild that replica or use a supported DC restore | Verify its domain and application partitions are represented elsewhere before discarding it |
| A deleted user, group or OU remains restorable | Restore the original object identity, parents and required links | A new object with the old name has a different identity; use object recovery |
| A live object’s values were overwritten | Repair the selected values from established good evidence | Recycle Bin restores deletions; it does not roll back an edit |
| A GPO is damaged or deleted | Recover the policy’s directory and file components with the appropriate GPO backup/process | Also verify links and filtering; see Group Policy audit and backup |
| One DFSR SYSVOL member has a bad local copy | Recover that member from a deliberately selected healthy source | A whole-domain SYSVOL reset is a different scope; use SYSVOL recovery |
| Every usable copy contains widespread damaging changes | Assess isolated domain/forest recovery or a supported targeted repair | A nonauthoritative restore can accept the unwanted state again |
| Directory contents are correct but secrets were exposed | Contain the exposure and establish a credential/security recovery plan | Database rollback alone does not make the exposed secrets private again |
With physical database corruption, first find out whether you have a supported backup or healthy peer. A lossy repair doesn’t return the DC to supported long-term service: Microsoft’s database-corruption guidance requires rebuilding it afterwards. Choose the tool only after you’ve separated local storage/database damage from bad data that replicated normally.
Compare values and their replication history
Use RSAT’s Repadmin from an authorized diagnostic host to query the same known object GUID on selected replicas. Replace these illustrative names and GUID; these commands read metadata:
repadmin /showobjmeta dc1.contoso.com "<GUID=11111111-2222-3333-4444-555555555555>"
repadmin /showobjmeta dc2.contoso.com "<GUID=11111111-2222-3333-4444-555555555555>"
For each affected attribute, compare version, originating DSA, originating USN and originating time. Local USNs can differ on two replicas holding the same originating update. Matching metadata establishes which update arrived; inspect the actual value separately to establish whether that update is desirable. The command also accepts a DN, but GUID selection remains useful after a move, rename or deletion. Repadmin metadata syntax and Microsoft’s current object-metadata troubleshooting guidance describe the comparison.
Metadata tells you which directory instance originated the update and its history. It doesn’t identify the person or process behind the write. Match the time and affected object with change auditing, provisioning and application logs before a repair adds another update. A recent whenChanged value alone won’t identify a good restore point.
If one DC still has an earlier value, establish whether it is a trustworthy reference or simply stale. Do not force synchronization merely to make the diagnostic views agree: convergence can remove the remaining useful comparison. Mounted backup/snapshot inspection provides a separate read-only way to investigate historical state. Contain the offending writer so the repair persists.
Directory authority and SYSVOL authority are separate
A nonauthoritative directory restore lets newer partner updates win. An authoritative object/subtree restore deliberately changes that outcome for selected directory state. Making DFSR SYSVOL authoritative is a separate operation on the replicated file data. Neither decision should be inferred from the other.
For a GPO, distinguish the Group Policy Container in AD from the Group Policy Template in SYSVOL. Restoring directory objects alone does not recreate missing policy files. GPMC recovery also has a scope boundary: GPO-to-site/domain/OU links belong to those containers, so restoring the GPO does not restore those links. A restored link to a WMI filter does not restore a deleted filter’s contents. Microsoft’s GPO restore semantics specify these distinctions.
Decide which copy will be authoritative and which servers will receive it, then follow the backup/recovery plan or DFSR SYSVOL procedure. Check that you can actually reach the good copy before depending on it.
Single-domain recovery has a forest-wide GC consequence
In a multidomain forest, restoring one domain to last week’s backup can leave GCs in other domains holding newer partial replicas of that recovered domain. Completing the writable domain’s restoration does not establish consistency of those foreign GC copies.
Microsoft documents two approaches: coordinate unhosting and rehosting the recovered domain’s partial partition on all GCs outside that domain, or follow the recovery process and remove lingering objects from those GCs using a suitable recovered-domain reference. The first can remove substantial GC capacity while replicas rebuild; the second requires a verified reference and partition-specific cleanup. These are planned recovery changes, not ordinary replication retries. The single-domain recovery guide gives the supported branches and their operational assumptions.
For the rehosting branch, the guide requires removing that partial partition from all GCs outside the recovered domain before rehosting it. Rehosting one while another still holds the newer copy can defeat the intended cleanup. Plan the loss of those replicas and the remaining GC capacity before starting.
List every foreign GC before choosing a recovery branch. Record the recovered domain NC, sites, replica sources, capacity during recovery and sign-in dependencies. Afterwards, check the domain on its writable replicas and its partial replicas; see GC query scope and lingering-object checks. The recovered domain’s own DC list won’t include the second set.
Schema damage and credential exposure need distinct decisions
A failed schema extension is not automatically grounds for forest rollback. Determine the exact additions/modifications and whether supported corrections or making eligible custom definitions defunct meet the application’s needs. Schema additions cannot simply be deleted; making a definition defunct does not erase existing instances. Rebuilding one DC also does not remove schema changes already replicated through the forest. Schema modification rules and defunct schema behavior define the limits.
Credential exposure needs a separate decision. Microsoft’s failure examples distinguish leaked DC/backup contents with no AD data modification from cases requiring database restoration. Recovery may instead require resetting affected user, computer, trust and managed-service-account secrets under the incident plan. An older database doesn’t by itself remove persistence or fix exposed external credentials. Identify the recovery problem covers that distinction. Check both the directory state you’ll trust and the work needed to make credentials trustworthy again.