The difficult part isn’t running the restore command. The difficult part is
choosing the correct recovery method.

If you restore the wrong thing authoritatively, you can roll back changes that
were made after the backup. If you restore a failed Domain Controller
non-authoritatively when the backup actually contains the data you need to
recover, you may not get the result you expect.

This guide explains the difference using practical Active Directory scenarios,
including the recovery situations administrators commonly encounter in modern
Windows Server environments.

Quick Answer

What You’ll Need

• A valid Active Directory-aware backup.
• A System State backup when performing System State recovery.
• DSRM credentials for the affected Domain Controller.
• Knowledge of which Domain Controllers are healthy.
• Knowledge of when the problem occurred.
• A tested Active Directory recovery procedure.
• A clear understanding of which copy of the data is trusted.

Step 1 — Identify What Actually Failed

Before restoring anything, establish exactly what happened.

• Did one Domain Controller fail?
• Are other Domain Controllers healthy?
• Is Active Directory replication working?
• Was an object accidentally deleted?
• Did the bad change replicate?
• Is the problem limited to one DC, one object, or the entire forest?

Check replication health:

repadmin /replsummary

Check Domain Controller health:

dcdiag /v

Step 2 — Decide Which Copy Should Win

Ask the most important question in the entire recovery process:

If healthy Domain Controllers contain the correct information, the restored
Domain Controller normally needs to synchronize with them.

That points toward a non-authoritative AD DS restore.

If the backup contains the correct version of specific deleted or damaged
directory data and that data needs to replace the copies held elsewhere,
an authoritative restore may be appropriate.

Step 3 — Understand Non-Authoritative AD DS Restore

A non-authoritative restore brings a failed Domain Controller back using a
trusted backup, but the restored directory data does not become the
authoritative source for the other Domain Controllers.

The goal is simple:

Real-World Scenario: Failed DC

Your company has:

• DC01 — Primary site
• DC02 — Secondary site
• DC03 — Disaster recovery site

DC02 suffers a hardware or operating-system failure.

DC01 and DC03 are healthy and contain current users, groups and computer
accounts.

You restore DC02 from a valid System State backup.

Microsoft documents a non-authoritative AD DS restore using
wbadmin.exe as part of its forest-recovery procedures.
The backup must contain System State data. :contentReference[oaicite:1]{index=1}

Step 4 — Understand Authoritative Restore

An authoritative restore is different.

It deliberately increases the version information of selected Active Directory
objects or containers so that, after replication, the restored information
becomes authoritative on the other Domain Controllers.

Microsoft specifically recommends keeping the restore scope as small as
practical. Restoring a specific object is less destructive than authoritatively
restoring an entire subtree. :contentReference[oaicite:2]{index=2}

Real-World Scenario: Deleted Security Group

Imagine an administrator accidentally deletes a security group containing
critical application permissions.

The deletion replicates before anyone notices.

At this point, the healthy Domain Controllers agree that the group is deleted.

If Active Directory Recycle Bin can recover the object, that should generally
be considered first.

If backup-based recovery is required, an authoritative restore may be used
to make the recovered object authoritative.

Microsoft’s current guidance notes that Active Directory Recycle Bin is the
common first method for recovering deleted security principals when available.
If it isn’t available, authoritative recovery methods can be used. :contentReference[oaicite:3]{index=3}

Step 5 — Treat SYSVOL as a Separate Recovery Decision

Active Directory Domain Services stores directory information such as users,
groups, computers and directory configuration.

SYSVOL contains important Group Policy and logon-related files and is
replicated separately in modern Windows Server environments using DFSR.

Microsoft’s forest recovery procedure can require a
non-authoritative AD DS restore together with an authoritative SYSVOL
restore. Microsoft’s documentation explicitly provides a
wbadmin -authsysvol option for this situation. :contentReference[oaicite:4]{index=4}

Step 6 — Consider Recycle Bin Before System State Recovery

If the problem is simply that one or several users, computers or groups were
deleted, don’t automatically jump to a System State restore.

If Active Directory Recycle Bin is enabled and the objects are still
recoverable, it is usually a much cleaner object-level recovery approach.

Commands

Check Replication

repadmin /replsummary

Check Domain Controller Health

dcdiag /v

Authoritatively Restore a Specific Object

Microsoft documents the following Ntdsutil syntax for an individual object:

ntdsutil "authoritative restore" "restore object <object DN path>" q q

Example:

ntdsutil "authoritative restore" "restore object cn=JohnDoe,ou=Mayberry,dc=contoso,dc=com" q q

Microsoft requires the quotes in this syntax and recommends restoring the
lowest-level object or container necessary. :contentReference[oaicite:5]{index=5}

Real-World 2026 Scenarios

Scenario 1 — Domain Controller Hardware Failure

DC02 fails. DC01 and DC03 are healthy.

Decision: Non-authoritative AD DS restore.

The objective is to rebuild DC02 and allow it to obtain current directory
information from its healthy partners.

Scenario 2 — Administrator Deletes a User

A user account is accidentally deleted.

First decision: Check Active Directory Recycle Bin.

If the object is available there, recover it without performing a broader
System State recovery.

Scenario 3 — Critical Security Group Deleted

A security group used by a business application is accidentally deleted and
the deletion replicates throughout the domain.

Decision: Recycle Bin if available. If backup-based recovery
is required, authoritative object recovery may be appropriate.

Scenario 4 — Multiple DCs Are Untrusted After a Major Security Incident

The organization determines that the forest can no longer be trusted and
needs to be rebuilt from known-good backups.

Decision: Forest recovery.

This is much larger than restoring one Domain Controller. Microsoft provides
a dedicated forest-recovery sequence for this situation. :contentReference[oaicite:6]{index=6}

Scenario 5 — First DC Recovered During Forest Recovery

The organization restores the first writable Domain Controller from a
known-good System State backup.

This is where the terminology can become confusing.

Microsoft’s documented procedure can involve a
non-authoritative AD DS restore while making SYSVOL authoritative
during the forest recovery process. :contentReference[oaicite:7]{index=7}

Common Errors

Using Authoritative Restore for a Normal DC Failure

If other Domain Controllers already have the correct information, making an
old backup authoritative can unnecessarily roll back newer changes.

Restoring an Entire OU for One Deleted User

An authoritative subtree restore can affect objects that were not part of the
original problem.

Microsoft notes that this can roll back newer changes such as passwords,
profile information, group memberships and security descriptors. :contentReference[oaicite:8]{index=8}

Skipping Recycle Bin

For a simple deleted-user or deleted-group incident, a full System State
recovery may be unnecessarily complicated when Recycle Bin can recover the
object.

Treating SYSVOL Like the AD Database

SYSVOL has its own replication and recovery requirements. Follow the
appropriate DFSR/SYSVOL recovery procedure. :contentReference[oaicite:9]{index=9}

Troubleshooting

Replication Is Not Working

repadmin /replsummary

Investigate DNS, connectivity, replication errors and the health of the
remaining Domain Controllers.

Restored Object Does Not Appear on Other DCs

Verify that the correct object was restored and that the authoritative
recovery procedure was completed correctly. Then check replication.

SYSVOL Is Not Replicating

Don’t solve this by simply copying SYSVOL files between Domain Controllers.
Use Microsoft’s DFSR SYSVOL recovery procedure. :contentReference[oaicite:10]{index=10}

Pros and Cons

When NOT to Use an Authoritative Restore

Best Practices

Simple Decision Tree

Related Articles

Final Takeaway

The biggest mistake in Active Directory recovery is assuming that an
authoritative restore is simply a “stronger” restore.

It isn’t.

Non-authoritative means the restored DC should catch up with
the healthy environment.

Authoritative means selected recovered directory data should
become the version that wins replication.

And in a forest recovery, AD DS and SYSVOL must be considered
separately.

Sources