Active Directory rollback after bad script: To revert AD to yesterday’s state when incorrect changes replicated to all domain controllers, what is the correct authoritative restore procedure?

Introduction / Context:
When erroneous directory changes replicate to all domain controllers (DCs), a simple non-authoritative restore will be overwritten by newer, bad data. An authoritative restore is required so the restored DC's directory data is treated as the newest and is replicated out to other DCs, effectively rolling back the domain to the prior backup state.

Given Data / Assumptions:

• There are three DCs in the domain.
• Yesterday's full backup of System State exists for at least one DC.
• A script made incorrect modifications that have already replicated.

Concept / Approach:
An authoritative restore consists of: 1) booting into Directory Services Restore Mode (DSRM) so AD is offline, 2) restoring System State (which contains ntds.dit, SYSVOL, registry), and 3) using ntdsutil to mark the restored directory data authoritative (update version numbers/USNs). On reboot, the restored DC's data replicates to the others, undoing the unwanted changes.

Step-by-Step Solution:

Verification / Alternative check:
Inspect event logs for replication status and validate corrected user accounts/attributes. Use repadmin to confirm healthy replication.

Why Other Options Are Wrong:

• Restoring System State and rebooting without marking authoritative results in non-authoritative restore; bad data overwrites the restore.
• Recovery Console cannot perform AD authoritative restores.
• Restoring only SYSVOL does not fix AD database contents.

Common Pitfalls:
Forgetting to restore the correct backup set or not isolating the DC during restore can re-import bad changes; ensure you use DSRM and authoritative flags.

Final Answer:
Boot one DC into Directory Services Restore Mode, restore System State with Windows Backup, run NTDSUTIL to mark objects authoritative, then restart