Active Directory Disaster Recovery

Introduction to Active Directory Disaster Recovery 

Back in the day, I was lucky enough to work with a Microsoft Premier Field Engineer. That was quite some time ago, and AD has evolved considerably since then. Using the original field engineer’s guide as a foundation, I’ve rewritten and updated the material for Windows Server 2016 and newer.

The topics covered in this updated AD Disaster Recovery guide include:

• Backing up and restoring Active Directory

• Scheduling a script to export object reference data to assist during restores

• Identifying and verifying FSMO role holders, moving or seizing roles

• Enabling and restoring objects with the Recycle Bin.

• Performing non-authoritative and authoritative restores

• Rebuilding a failed domain controller from backup

• Restoring GPOs, DFSR and SYSVOL

• Metadata cleanup and lingering object removal

• Validating replication health after recovery

Best Practices for Active Directory Backups

The Obvious – Backups

• The obvious, but not to all, enable BACKUPS using Windows Backup or another backup product.

• Enable the AD Recycle Bin to reduce the necessity of an Authoritative Restore.

Use Dedicated Backup Storage

• Store backups on a dedicated local or network volume, not on the same disk as the operating system.

• If using a share, restrict access to a dedicated service account with write-only permissions.

• Don’t allow share or NTFS permissions to Users or Authenticated Users

• Especially Full Control, you know who you are…. Muppet and you’re the apparent expert

Always Include the System State

• Active Directory is stored within the NTDS.dit database, SYSVOL, the registry, COM+ class registration database, and critical boot files, all of which are part of the System State.

• Never rely on volume-level or file-based backups alone; they won’t capture the AD database metadata or replication data needed for restore.

• Backup SYSVOL as a file level backup.

• Export and Backup GPO’s to the file system.

• Export DNS and backup.

Back Up All FSMO Role Holders

• Ensure every DC is protected, but at a minimum, always back up:

  • Schema Master

  • Domain Naming Master

  • RID Master

  • PDC Emulator

  • Infrastructure Master

• Losing an un-backed FSMO holder complicates recovery, role seizure should be the last resort

Retain Multiple Recovery Points

• Keep at least 7 days of rolling backups on local or nearline storage.

• Weekly or monthly copies offsite or offline (for ransomware isolation).

Validate Backups Regularly

• A backup that can’t restore isn’t a backup.

• Perform test restores to non-production.

Windows and Script Backup Configuration

System State backup schedule configuration 

• Add a drive dedicated to backups of 100Gb or greater

• Install the Windows Backup feature

• Open Windows Backup

• Create a daily backup schedule

• Select custom backup

• Backup the System State, C:\ADBackups, C:\Windows\NTDS, C:\Windows\SYSVOL

• Backup to the dedicated drive

Service account setup 

• Create a service account named svc_ADBackup

• Add the service account to both ‘DNSAdmins’ and ‘Group Policy Creator Owners’ Groups.

• The service requires both User Rights Assignments ‘Logon as Batch’ and Logon as a Service’

• Either add directly to URA via GPO Management or preferably, create URA groups and assign to ‘Logon as Batch’ and ‘Logon as a Service’, then add the service account to the groups.

• The service account will require Full NTFS permission on 'C:\ADBackup\' and 'C:\Windows\System32\dns\' to create and delete files and directories.

• Don’t allow the service account permissions to amend the backup script.

• Do Not execute scripts with a service account that is a Domain Admin on a Domain Controller.

Scheduled task creation for backup script 

This PowerShell script automates the creation of a reference snapshot to support Active Directory recovery by backing up DNS zones, Group Policy Objects (GPOs), and AD objects. It runs on Domain Controllers and organizes the backups by day of the week, maintaining a straightforward seven-day rotation.

The script exports:

• DNS configuration details (forwarders, recursion, scavenging, zones, and server settings), backs up all DNS zone files

• GPO data with linked permissions and references.

• AD computers, users, groups, OUs, and GPO links

Schedule setup:

• Create a Scheduled task

• Add the svc_ADbackup and password to ‘Run whether users is logged on or not’

• Add a daily trigger

• Add action: powershell.exe -executionpolicy bypass -file "C:\ADBackups\ADBackup.v.0.1.ps1"

Protect the DSRM Password

• The Directory Services Restore Mode (DSRM) password is required for any restore.

  
  

Reset if unknown:

• Open CMD as Domain Admin

Type ‘ntdsutil’
Type ‘set dsrm password’, press Enter
Type ‘reset password on server %serverName%’, press Enter
Type the new password * 2, press Enter
Type q,q to quit ntdsutil

• Store the password securely (e.g., sealed envelope or password vault). Without it, you can’t boot into DSRM to perform an authoritative or non-authoritative restore.

• Reset every 180 days

Active Directory Recycle Bin

Overview

The Active Directory Recycle Bin is a feature that provides the ability to restore deleted Active Directory objects without needing to perform an authoritative restore from backup media. Introduced in Windows Server 2008 R2, this feature significantly simplifies the recovery process for accidentally deleted AD objects and preserves all attributes during restoration.

How to Enable the Active Directory Recycle Bin

Prerequisites

Before enabling the AD Recycle Bin, ensure the following requirements are met:

• Forest Functional Level: The forest must be at Windows Server 2008 R2 or higher functional level

• Schema Version: The AD schema must be updated to support the feature

• Permissions: You must be a member of the Enterprise Admins group

• Important Warning: Once enabled, the AD Recycle Bin cannot be disabled

• Enabling via PowerShell

The recommended method for enabling the AD Recycle Bin is through PowerShell:

• Enable-ADOptionalFeature –Identity 'Recycle Bin Feature' –Scope ForestOrConfigurationSet –Target 'yourdomain.com'

• After running this command, you'll receive a warning about the irreversible nature of this operation. Type 'Y' to confirm.

Enabling via Active Directory Administrative Center:

• Open Active Directory Administrative Center (ADAC)

• Navigate to your domain in the left pane

• Click on "Enable Recycle Bin" in the Tasks pane on the right

• Confirm the warning dialog

• Refresh ADAC to see the "Deleted Objects" container

• The feature typically takes approximately 15 minutes to replicate across all domain controllers in the forest.

Recoverable Objects:

• The AD Recycle Bin can recover virtually all types of Active Directory objects, including:

• User accounts: All user attributes, group memberships, and properties are preserved

• Computer accounts: Including domain-joined computer objects

• Security and distribution groups: With all group memberships intact

• Organizational Units (OUs): Including all objects within the OU structure

• Contacts: Mail-enabled and standard contacts

• Group Policy Objects (GPOs): Though GPO links may need to be manually restored

• Other AD objects: Such as printers, shared folders, and custom schema objects

• When an object is deleted, it moves to the Deleted Objects container and enters a "deleted" state where it remains for the duration of the deleted object lifetime (180 days by default). During this period, most attributes are preserved, making full restoration possible.

Limitations and Considerations

Time-Based Limitations

Deleted Object Lifetime:

By default, deleted objects are retained for 180 days. After this period, objects enter a "recycled" state where most attributes are removed, leaving only a minimal subset. Once in the recycled state, full restoration is no longer possible.

Recycled Object Lifetime:

After the recycled object lifetime expires (an additional 180 days by default), objects are permanently removed through garbage collection and cannot be recovered.

Functional Limitations

Cannot Be Disabled:

Once enabled, the AD Recycle Bin feature cannot be turned off. This is a permanent forest-level change.

No Rollback:

There is no way to revert to the previous tombstone based deletion model after enabling the feature.

Storage Overhead:

Deleted objects consume space in the Active Directory database until they are permanently removed through garbage collection. Organizations with frequent deletions may see increased database size.

Replication Considerations:

Deleted objects must replicate across all domain controllers, which can impact replication traffic in environments with many deletions.

Recovery Limitations

Container Objects:

When recovering an OU or container, you must first restore the container itself before restoring child objects. The hierarchy must be rebuilt from the top down.

Linked Attributes:

While most attributes are preserved, some complex linked attributes or dependencies may require manual verification after restoration.

No GUI for Recycled Objects:

Objects in the recycled state (after the deleted object lifetime expires) cannot be viewed or restored through the Active Directory Administrative Center interface; PowerShell must be used.

GPO Links:

While GPOs themselves can be restored, GPO links to OUs are not automatically restored and must be manually re-established.

Active Directory Recovery Methods

Non-Authoritative Restore (Standard Recovery)

• Use non-authoritative restore when the domain controller hardware failed but the domain is otherwise healthy, this assumes that the DC is non-bootable.

• Deploying a fresh Domain Controller is almost always preferable to performing a non-authoritative restore. A clean build ensures you’re running from a known-good, current installation without inheriting potential corruption or stale metadata from backups. It allows you to install the latest patches, security baselines, and configuration hardening from the outset. Once joined to the domain, the new DC will automatically replicate the directory data from healthy peers, cleanly re-establishing consistency across the forest.

• FSMO roles can then be gracefully transferred or seized as needed, without the risk of reintroducing outdated or conflicting data.

Prerequisites:

• Access to system state backup created before the failure

• At least one other healthy domain controller in the domain

• External backup media available and accessible

Procedure:

Install Server OS

• Install a new server of the same OS version and patch to the latest or at least to the same version as the now dead DC

• Install Windows Backup Feature

• Set network settings and IP

• Type msconfig and select Boot > Safe Boot > AD Repair or Boot into DRMS with Shift and F8

• Reboot and logon as the local admin

• Mount volume or copy backup to local server

• Launch Windows Backup

• Click Recover…

• Select This Server

• Select Date of the restore point

• Select Recovery Type = System State

• Restore to the original location

• There is a check box to Authoritatively restore of AD – Don’t check

• Reboot the server after the restore completes and ensure newer objects are replicated from another DC.

• Restart domain controller in normal mode

Restart-Computer -Force

• Post-Recovery Steps:

• Log back in as domain administrator after restart

• Run these commands on the recovered domain controller

Replication with domain controllers

repadmin /syncall /d /P

Verify replication completes

repadmin /replsummary
repadmin /showrepl

Check for replication errors

Get-ADReplicationFailure -target DC01 | Format-Table

Run diagnostic tests

dcdiag /f:c:\dcdiag.log

Verify DNS registration

ipconfig /registerdns
nslookup DCNAME

Monitor Event Viewer for errors

• Directory Service logs

• Replication events

• DNS server logs

Authoritative Restore (Selective Object Recovery)

When to use an Authoritative Restore and when to use the Recycle Bin.

The Active Directory Recycle Bin is excellent for recovering deleted objects, but it doesn’t help when existing objects or entire directory partitions are corrupted, overwritten, or lost due to replication issues or human error. That’s where an authoritative restore still matters.

The Recycle Bin can only restore objects that were intentionally deleted and still exist in the deleted objects container. It can’t roll back changes, like group membership modifications, GPO edits, or accidental bulk updates, because those aren’t deletions; they’re legitimate writes replicated across all domain controllers. If an admin accidentally removes every user from a security group or a script wipes out configuration attributes, those changes replicate instantly, and the Recycle Bin won’t help.

An authoritative restore allows you to recover data from a known-good backup and mark that version of the directory as the master copy during replication. This forces other domain controllers to accept the restored version as authoritative, overwriting the bad data across the forest.

In short:

• Recycle Bin = undelete objects.

• Authoritative Restore = roll back to a previous state after corruption or unwanted changes.

• Both have their place, but they solve entirely different problems.

Authoritative Restore Procedure

Use authoritative restore to recover deleted Active Directory objects that should not be overwritten by replication from other domain controllers. The restored objects are marked as authoritative and will replicate outbound to other DCs.

Prerequisites

• You must have a System State backup of the domain controller taken when the data was good.

• You must know which partition (naming context) you’re restoring:

• Domain partition: DC=yourdomain,DC=com

• Configuration partition: CN=Configuration,DC=yourdomain,DC=com

• Application partition: e.g. DC=ForestDnsZones,DC=yourdomain,DC=com

• Ensure other domain controllers are healthy, you’ll be restoring to one DC and then replicating out.

Restore AD Partition Procedure

• Boot into Directory Services Restore Mode (DSRM)

• Type msconfig and select Boot > Safe Boot > AD Repair or Boot into DRMS with Shift and F8

• Reboot

• Log in using the DSRM administrator password (set during DC promotion).

• Mount volume or copy backup to local server

• Launch Windows Backup

• Click Recover…

• Select This Server

• Select Date of the restore point

• Select Recovery Type = System State

• Restore to the original location

• There is a check box to Authoritatively restore of AD – Don’t check

• Don’t Reboot the server

• This step restores the AD database (NTDS.dit) from backup, but at this stage, it’s considered non-authoritative, other domain controllers would overwrite it during replication if you booted normally.

Mark the Partition as Authoritative

• Open Command Prompt (still in DSRM).

ntdsutil
Type ‘activate instance ntds’
Type ‘authoritative restore’
Then specify the partition you want to make authoritative, for example:
restore database
or, to target a specific partition:
restore subtree "DC=yourdomain,DC=com"
restore subtree "CN=Configuration,DC=yourdomain,DC=com"

• When prompted, confirm.

• This process updates the Update Sequence Numbers (USNs) on all objects in that partition so that when replication resumes, other DCs treat this version as newer and replicate it outward.

• Type quit twice to exit ntdsutil.

Reboot Normally

• Restart the domain controller normally. Once it starts, it will advertise as healthy and begin replicating the restored (authoritative) data to the rest of the forest.

Validate Replication

• Run the following to verify replication and event logs:

repadmin /showrepl
repadmin /syncall /AdeP

• Check the Directory Service event log for replication success (Event ID 1109 and similar).

Examples of Authoritative Restores

Authoritative Restore of a Single OU

Scenario: An administrator accidentally deletes the Sales OU, including all user and computer accounts, and the deletion has replicated to all DCs.

Goal:

Restore only the Sales OU and its objects from a System State backup.

Steps:

• Boot the affected DC into Directory Services Restore Mode (DSRM).

• Restore the System State using Windows Server Backup:

• Do not reboot when prompted after the restore completes.

• Open a Command Prompt and run:

ntdsutil
activate instance ntds
authoritative restore
restore subtree "OU=Sales,DC=Domain,DC=com"
quit, quit

• Restart the domain controller normally.

Authoritative Restore of an Entire Domain Partition

Scenario: A script corrupts large parts of the domain (e.g. user attributes overwritten or objects missing) across all domain controllers.

Goal:

Restore the entire domain partition to its last known good state.

Steps:

• Boot into DSRM.

• Perform a System State restore as above.

• Before rebooting, run:

ntdsutil
activate instance ntds
authoritative restore
restore database
quit, quit

• Reboot the DC normally.

Authoritative Restore of a Configuration Partition

Scenario: An improperly written schema extension or deleted configuration container (e.g. Exchange or DFS settings) breaks forest-wide functionality.

Goal:

Restore the Configuration naming context to a working version from backup.

Steps:

• Boot into DSRM.

• Perform a System State restore as above.

• Before rebooting, run:

ntdsutil
activate instance ntds
authoritative restore
restore subtree "CN=Configuration,DC=Domain,DC=com"
quit, quit

Authoritative Restore of Sites

Scenario: An improperly written schema extension or deleted configuration container (e.g. Exchange or DFS settings) breaks forest-wide functionality.

Goal:

Restore the Configuration naming context to a working version from backup.

Steps:

• Boot into DSRM.

• Perform a System State restore as above.

• Before rebooting, run:

ntdsutil
activate instance ntds
authoritative restore
restore subtree "CN=Configuration,DC=Domain,DC=com"
quit, quit

This includes:

• Sites (CN=Sites)

• Subnets (CN=Subnets)

• Site links and link bridges

• Site link costs and replication schedules

Authoritative Restore of Subnets

Scenario: An improperly written schema extension or deleted configuration container (e.g. Exchange or DFS settings) breaks forest-wide functionality.

Goal:

Restore the Configuration naming context to a working version from backup.

Steps:

• Boot into DSRM.

• Perform a System State restore as above.

• Before rebooting, run:

ntdsutil
activate instance ntds
authoritative restore
restore subtree "CN=Subnets,CN=Sites,CN=Configuration,DC=Domain,DC=com"
quit, quit

Authoritative Restore of a Deleted Group Policy Object (GPO)

Scenario: A key GPO (e.g. Default Domain Policy) was deleted and the Recycle Bin isn’t enabled.

Goal:

Restore the deleted GPO from backup.

Steps:

• Boot into DSRM.

• Perform a System State restore as above.

• Before rebooting, run:

ntdsutil
activate instance ntds
authoritative restore
restore subtree "CN={6AC1786C-016F-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=Domain,DC=com"
quit, quit

• Restart the DC.

• Compare SYSVOL contents and re-link GPOs if needed.

Partial Object Restore (Single User or Group)

Scenario: A critical service account or group was deleted and is not recoverable via the Recycle Bin.

Goal:

• Restore only that object without affecting the rest of the directory.

Steps:

• Boot into DSRM.

• Perform a System State restore as above.

• Before rebooting, run:

ntdsutil
activate instance ntds
authoritative restore
restore object "CN=svc_SQL,OU=Service Accounts,DC=Domain,DC=com"
quit, quit

Authoritative Restore After a Forest-Wide Rollback

Scenario: A misconfiguration or replication storm corrupts all domain partitions, and restoring a single DC is not sufficient.

Goal:

• Perform a forest-level authoritative restore (usually from the forest root DC).

Steps:

• Boot into DSRM.

• Perform a System State restore as above.

• Before rebooting, run:

ntdsutil
activate instance ntds (restore all naming contexts:)
authoritative restore
restore database
quit, quit

• Reboot, allow replication to push authoritative copies to all other DCs

FSMO Architecture Overview

What are FSMO Roles

FSMO (Flexible Single Master Operations) roles exist because certain Active Directory operations cannot be performed simultaneously across multiple domain controllers without creating logical inconsistencies, data corruption, or irreconcilable conflicts. These operations require a single authoritative source, a master role holder.

There are five FSMO, roles  two forest-wide and three domain-wide, that ensure consistency in schema, domain naming, object creation, and directory replication.

Schema Master

Scope:

Forest-wideDefault location: First DC in the forest root domain

Purpose:

Controls all changes to the Active Directory schema, the master definition of all object classes and attributes. When products such as Exchange, SCCM, or Azure AD Connect extend the schema, the changes are applied only via the Schema Master.

If unavailable:

• No schema updates or extensions can occur.

• Existing directory operations continue normally.

Improper seizure consequences:

• If the Schema Master role is seized and the original DC is later brought online, schema version conflicts can occur.

• Both DCs may believe they are authoritative for schema updates.

• Replication may fail with “schema mismatch” errors.

• Corrupted or divergent schema versions can render the forest unrecoverable without a rebuild.

• Criticality:  Low (short term), High (during schema updates)

Domain Naming Master

Scope:

Forest-wideDefault location:

• First DC in the forest root domain

Purpose:

Controls the creation and deletion of domains and application directory partitions in the forest. It ensures that all domain names are unique and updates the forest-wide naming context.

If unavailable:

• Cannot create or remove domains or application partitions.

• Daily operations and replication are unaffected.

Improper seizure consequences:

• If the role is seized incorrectly or the original DC returns:

• The forest may contain duplicate domain or application partition records.

• “Orphaned” domain entries may remain in AD, causing replication or trust inconsistencies.

• Forest integrity checks (ntdsutil, repadmin /showrepl) may show naming collisions or metadata errors.

Criticality:

• Low (short term), High (during forest restructuring)

Relative ID (RID) Master

Scope:

• Domain-wide

Purpose:

The RID Master allocates RID pools to all domain controllers within its domain. Each new security principal (user, group, or computer) is assigned a unique Security Identifier (SID), which consists of the domain SID plus a Relative ID (RID). The RID Master ensures that each domain controller issues unique RIDs, preventing SID duplication across the domain.

If unavailable:

• DCs can continue creating new objects until their current RID pool runs out.

• Each domain controller receives a RID pool of 500 identifiers. When approximately half of the pool (250 RIDs) has been consumed, the DC automatically requests a new allocation from the RID Master.

• Once depleted, no new users, groups, or computers can be created.

Improper seizure consequences:

• If the RID Master role is seized while the original DC is still active or later reintroduced:

• Multiple DCs may issue overlapping RID pools, resulting in duplicate SIDs.

• SID duplication breaks access control and causes permanent security inconsistencies.

• AD replication may fail due to RID conflicts (event ID 16650 or event ID 16658).

• A forest rebuild may be required to safely recover.

Criticality: 

• Medium (short term), High (if RID pool exhausted or duplicated)

Primary Domain Controller (PDC) Emulator

Scope:

• Domain-wide

Purpose:

• The PDC Emulator is the operational backbone of the domain. It performs several time-sensitive and synchronization functions:

• Password authority: Receives immediate replication of password changes; resolves password mismatches during authentication.

• Time synchronization: Acts as the authoritative time source for the domain; the forest root PDC is the master clock for the forest.

• Group Policy master: Central point for GPO creation and editing (GPMC connects directly to it).

• Trust management: Maintains trust passwords and NT4 compatibility for legacy systems.

If unavailable:

• Password changes stop replicating promptly; recently changed passwords may fail to authenticate.

• Kerberos time skew may cause logon and service ticket failures.

• GPO edits fail or are inconsistent.

• External trusts and legacy systems may fail authentication.

Improper seizure consequences:

• If seized incorrectly or the old PDC Emulator is later reintroduced:

• Two DCs may both act as time authorities, creating time drift and Kerberos failures.

• Password replication loops or mismatches may occur, leading to logon failures.

• Group Policy edits may conflict or become corrupted.

• Trust relationships may intermittently fail.

Criticality:

• Very High, immediate recovery or transfer required

Infrastructure Master

Scope:

• Domain-wide

Purpose:

Maintains cross-domain object references by updating phantom objects, lightweight records that represent objects (users, groups, or computers) from other domains. When a cross-domain object is renamed, moved, or deleted, the Infrastructure Master updates these phantom references to keep directory data consistent.

If unavailable:

Cross-domain group memberships or references display outdated or incorrect names.

Access control continues to function (based on SIDs), but visible names become stale.

In a single-domain forest, or where all DCs are Global Catalogs, this role has no functional impact.

Improper seizure consequences:

• If the Infrastructure Master is seized incorrectly or the original DC is brought back online:

• Phantom object records may become inconsistent between DCs.

• Cross-domain group memberships can appear corrupted or out of sync.

• Event logs may show phantom cleanup or reference errors (event ID 1412).

• Requires metadata cleanup and GC resync to correct.

Criticality:

• Low to Medium

Special note on GCs:

In a multi-domain forest, the Infrastructure Master should not reside on a Global Catalog unless all DCs are GCs. Otherwise, it will never detect outdated phantom references.

Global Catalog (GC) Interaction

• Although not a FSMO role, the Global Catalog (GC) interacts closely with FSMO operations. It stores a partial replica of every object across the forest, enabling:

• Universal group membership resolution during logon.

• Forest-wide searches and object lookups.

• Phantom object validation for the Infrastructure Master.

• Best practice: host at least one GC per site for redundancy and authentication performance.

FSMO Placement Commands

cmd:

netdom query fsmo

PowerShell:

Get-ADForest | Select-Object -Property SchemaRoleOwner, DomainNamingMasterRole

Get-ADDomain | Select-Object -Property InfrastructureRoleMaster, RidRoleOwner, PDCEmulator

How to Seize the Operations Master Roles

FSMO roles are normally transferred gracefully using standard Active Directory management tools such as Active Directory Users and Computers, Domains and Trusts, or the Schema Management snap-in.

These tools require the current FSMO holder to be online and reachable. However, in the event of a permanent failure or loss of connectivity to the role holder, the role must be seized by another domain controller.

Role seizure is a last-resort operation and should only be performed if the existing FSMO host cannot be recovered within a reasonable time frame. Improper or premature seizure can cause directory inconsistencies and replication issues.

Potential Risks of Role Seizure:

Data Loss or Inconsistent Directory State

• When a FSMO role is seized, the new holder begins operating based on its current AD replication state. If replication was incomplete before the original FSMO server failed, the new role holder may be missing recent updates.

• To reduce this risk, wait for at least one full replication cycle to complete across all domain controllers before seizing the role, ensuring the target DC has the latest data.

Duplicate Role Holders

• Because the original FSMO server is offline during the seizure, it does not receive notification that its role has been reassigned. If that server is later brought back online, such as after repair or restoration from backup, it may still consider itself the valid FSMO holder.

• Having two domain controllers performing the same FSMO role can lead to severe directory corruption or conflicting updates.

• To prevent this, once a FSMO role has been seized, the original role holder must never be brought back online. If the hardware is restored, it should be reinstalled and rejoined as a new domain controller rather than reintroduced with its previous Active Directory database.

• Role seizure is a powerful but dangerous tool, use it only when the failure is permanent and recovery is impossible.

Steps:

Open an elevated Command Prompt on the target domain controller.

• Type:

ntdsutil
Enter FSMO maintenance mode:
roles
Connect to the target DC:
connections
connect to server <NewDCName>
quit
(Replace <NewDCName> with the hostname of the DC taking over the roles.)
(Optional) View current FSMO role assignments:
select operation target
list roles for connected server
quit

• Seize the required FSMO roles using the appropriate commands:

seize schema master
seize naming master
seize rid master
seize pdc
seize infrastructure master         

• (Only run the commands for the roles that need to be seized.)

Exit NTDSUTIL:
quit, quit

After Seizing the Roles:

Verify new FSMO assignments

netdom query fsmo

AD Partitions

Active Directory is divided into several naming contexts (partitions), each serving a specific replication and storage purpose. Here’s the complete list — including the two used by DNS:

Schema Partition

• Distinguished Name (DN): CN=Schema,CN=Configuration,DC=<domain>,DC=<com>

• Purpose: Defines all object classes and attributes in the forest.

• Replication Scope: Forest-wide (to all Domain Controllers).

• Example:

  • CN=Schema,CN=Configuration,DC=<domain>,DC=<com>

Configuration Partition

• Distinguished Name (DN): CN=Configuration,DC=<domain>,DC=<com>

• Purpose: Stores forest-wide configuration data (sites, services, replication topology, etc.).

• Replication Scope: Forest-wide.

• Example:

  • CN=Configuration,DC=<domain>,DC=<com>

Domain Partition

• Distinguished Name (DN): DC=<domain>,DC=<com>

• Purpose: Contains all domain-specific objects — users, groups, computers, OUs, and policies.

• Replication Scope: Domain-wide (replicates only to DCs in the same domain).

• Example:

  • DC=<domain>,DC=<com>

ForestDNSZones Partition

• Distinguished Name (DN): DC=ForestDNSZones,DC=<forestrootdomain>,DC=<com>

• Purpose: Stores DNS zone data replicated forest-wide (used for DNS zones integrated at the forest level).

• Replication Scope: Forest-wide.

• Example:

  • DC=ForestDNSZones,DC=<domain>,DC=<com>

DomainDNSZones Partition

• Distinguished Name (DN): DC=DomainDNSZones,DC=<domain>,DC=<com>

• Purpose: Stores DNS zone data replicated within the domain only (used for domain-scoped DNS zones).

• Replication Scope: Domain-wide.

• Example:

  • DC=DomainDNSZones,DC=<domain>,DC=<com>

List Partitions with Powershell

$hh=@() ; $hh += "-" * 80
$root = Get-ADRootDSE
Write-Host $hh
Write-Host "Active Directory Partitions:" -ForegroundColor Cyan
Write-Host $hh
# Domain Partition
Write-Host "Domain Partition: $($root.defaultNamingContext)"
# Configuration Partition
Write-Host "Configuration Partition: $($root.configurationNamingContext)"
# Schema Partition
Write-Host "Schema Partition: $($root.schemaNamingContext)"
# Domain DNS Zones Partition
Write-Host "DomainDNSZones Partition: DC=DomainDNSZones,$($root.defaultNamingContext)"
# Forest DNS Zones Partition
Write-Host "ForestDNSZones Partition: DC=ForestDNSZones,$($root.rootDomainNamingContext)"

 

Using ADSI Edit to Connect to AD Partitions

Step-by-Step:

• Run ADSI Edit (adsiedit.msc) on a Domain Controller or from RSAT.

• In the ADSI Edit console, right-click ADSI Edit and select Connect to…

• In the Connection Settings window, under “Select a well-known Naming Context”, choose one of the following:

• Default naming context > The domain partition

• Configuration > Forest-wide configuration data

• Schema > AD schema definitions

• To view DNS partitions (not listed by default), use “Select or type a Distinguished Name or Naming Context” and enter:

• For DomainDNSZones:

• DC=DomainDNSZones,DC=domain,DC=com

• For ForestDNSZones:

• DC=ForestDNSZones,DC=domain,DC=com

Performing an authoritative restore of an Active Directory partition allows you to recover deleted or corrupted objects and ensure they replicate back to other Domain Controllers. Here’s a step-by-step guide, including the DNS partitions if needed.

Prepare for the Restore

Identify the partition to restore:

• Domain Partition: DC=domain,DC=com

• Configuration Partition: CN=Configuration,DC=domain,DC=com

• Schema Partition: CN=Schema,CN=Configuration,DC=domain,DC=com

• DomainDNSZones: DC=DomainDNSZones,DC=domain,DC=com

• ForestDNSZones: DC=ForestDNSZones,DC=domain,DC=com

Ensure you have a recent backup (System State backup) of the partition.

Reference the Authoritative Restore for full detailed instructions to restore a partition

Open a command prompt in DSRM.

ntdsutil
Enter authoritative restore mode:
activate instance ntds
authoritative restore

Mark the partition you want:

Domain Partition:

restore subtree "DC=domain,DC=com"

Configuration Partition:

restore subtree "CN=Configuration,DC=domain,DC=com"

Schema Partition:

restore subtree "CN=Schema,CN=Configuration,DC=domain,DC=com"

DNS Partitions:

restore subtree "DC=DomainDNSZones,DC=domain,DC=com"restore subtree "DC=ForestDNSZones,DC=domain,DC=com"

Tip: Use quotes exactly as above;

AD DNs are case-insensitive but spaces matter.

DNS Zone Recovery

This procedure defines how to back up and restore the DNS Server Zones. Although it’s possible to backup DNS Server configurations it’s only possible to restore manually.

Backup Procedure

The DNS backup script performs a full export of DNS zones and server configuration each day of the week.

Prepare a backup directory

• Ensure $backupPath is defined in the parent backup script (e.g. C:\Backups\ADBackup.ps1).

• The script automatically creates a daily subfolder under DNS\<DayOfWeek>.

• Schedule with a Service Account and add the following rights and permissions.

• User Rights Assignments for Logon As A Service and Logon as Batch are required.

• The service account will require Full NTFS permission on 'C:\ADBackup\' and 'C:\Windows\System32\dns\' to create and delete files and directories.

• Do Not add the service account to Domain Admins.

  
  

DNS Server Restore

• If restoring to a new server:

• Install the DNS Server role

• Install-WindowsFeature DNS -IncludeManagementTools.

• Allow AD synchronization to restore DNS records to local DC.

Restore DNS zones

• If a DNS zone becomes corrupted, loses records, or is accidentally deleted, it must be restored from a recent backup

• Copy the C:\ADBackup\DNS\<DayofWeek>\Zone.name to C:\Windows\System32\DNS.

• From CMD Type the following

• Dnscmd /zoneadd zone.name /primary /file zone.name

• Open the DNS Snap-in and for each Zone

• Click Type > Change and enable Store the zone in Active Directory

• Select Secure on the Dynamic Updates drop-down

GPO Recovery

Starting with Windows Server 2008 R2, Microsoft moved away from FRS replication system to Distributed File System Replication (DFSR) service for handling SYSVOL replication between domain controllers.

When planning disaster recovery, you need to account for both the AD portion (which gets handled through normal DC backup and recovery procedures) and the SYSVOL files themselves.

A corrupted or out-of-sync SYSVOL can render your entire GPO infrastructure useless even if Active Directory is perfectly healthy, which is why regular backups of the SYSVOL

GPO Backup Overview

GPO data exists in two parts:

• Active Directory component — stored in CN=Policies,CN=System,<domain>

• SYSVOL file component — stored in \\<domain>\SYSVOL\<domain>\Policies\<GPO_GUID>

• Links are not backed up with a GPO backup and must be restored manually.

To preserve both components, GPOs must be backed up using the Backup-GPO PowerShell cmdlet. This command exports GPO settings into a portable XML structure containing both AD and SYSVOL data.

GPO Backup Script

The backup script automates the daily export of all GPOs to a designated path (C:\ADBackups\GPO\dayofweek) creating a clean snapshot of every policy in the domain.

Executes a full backup of all GPOs using:

• Scheduled daily to retain a rolling weeks worth of GPO backups.

• Backup-GPO -All -Path $gpoBackupPath

• Records backup metadata (name, GUID, creation time) into GPOBackupReference.csv for audit and recovery reference.

  
  

Script Summary

try {
    # Clean existing backup directory
    if (Test-Path -Path $gpoBackupPath) {
        Get-ChildItem -Path $gpoBackupPath -Recurse | Remove-Item -Recurse -Force -ErrorAction SilentlyContinue
    }
# Perform full GPO backup
    $gpoBackupResult = Backup-GPO -All -Path $gpoBackupPath -ErrorAction Stop
    $gpoCount = ($gpoBackupResult | Measure-Object).Count
# Export reference file
    $gpoBackupResult | Select-Object DisplayName, GpoId, BackupDirectory, CreationTime |
        Export-Csv -Path "$gpoBackupPath\GPOBackupReference.csv" -NoTypeInformation

	Write-Host "GPO backup complete: $gpoCount GPOs backed up" -ForegroundColor Green
}
catch {
    Write-Error "Failed to backup GPOs: $_"
}

GPO Restoration Procedure

If you suspect a GPO is corrupted, deleted or made unauthorised changes, remove the GPO from the Group Policy Management Console to prevent further policy replication or application issues.

Process:

• Open GPO Management and navigate to Group Policy Objects.

• Right click Group Policy Objects > Manage Backups…

• Browse to C:\ADBackups\GPO\dayofweek and the last known good for that GPO

• Select GPO and Restore

• Restore Links manually using the Object Reference script or the scripted approach with GPO Restore Links script

SYSVOL DFSR Recovery 

SYSVOL replication issues can prevent Group Policy from applying correctly across the domain, leading to inconsistent user and computer configurations. When SYSVOL becomes corrupted, out of sync, or replication halts entirely, domain controllers may hold differing versions of policy data, some with outdated or missing GPOs. This can manifest as Group Policy processing errors, missing logon scripts, or inconsistent security settings. In such cases, a restore may be required.

A non-authoritative restore allows a domain controller to resynchronize its SYSVOL from a healthy partner, effectively discarding its local copy.

An authoritative restore, on the other hand, designates a specific DC’s SYSVOL as the master source, forcing other DCs to replicate from it. Selecting the right approach depends on where the corruption originated and which copy of SYSVOL is known to be correct.

D2 and D4 References by Microsoft

Microsoft still insists on using the old D2 and D4 terminology from the FRS era when describing DFSR SYSVOL recovery. The actual flags haven’t existed since Server 2008, but apparently Redmond can’t quite let go of the good old days of File Replication Service.

Non-Authoritative Restore

• Use when a single DC's SYSVOL is corrupted but other DCs have good copies.

• The restored DC will receive updated SYSVOL data from replication partners. 

• SYSVOL contents are overwritten by authoritative sources.

• Prefer the PDC Emulator as the authoritative source if it has the most up-to-date SYSVOL contents.

• All ADSIEdit attribute edits must replicate via AD replication to all DCs before starting DFSR on those DCs. Use repadmin /syncall /AdeP to force replication.

• Monitor the DFSR event log (Applications and Services Logs > DFS Replication) for the event IDs mentioned below.

Authoritative Restore

• Use when all DCs have corrupted SYSVOL or you need to force specific content across the domain.

• The restored DC becomes the authoritative source

• Other DCs receive SYSVOL data from the authoritative DC

Non-Authoritative SYSVOL Restore (D2)

Use this when a single DC’s SYSVOL is bad and you want it to rebuild from peers.

Steps (per DC you want to repair):

• Open ADSIEdit.msc and connect to the default naming context.

• Navigate to the SYSVOL subscription object for the target DC:

• CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<ServerName>,OU=Domain Controllers,DC=<domain>,DC=<com>

• Set the attribute msDFSR-Enabled = FALSE on that DN.

• Force AD replication to propagate that change to other DCs:

repadmin /syncall /AdeP

• On the target DC, run:

dfsrdiag pollad

• You should see Event ID 4114 in the DFSR log (sysvol replication stopped).

• On the same DN in ADSIEdit, set msDFSR-Enabled = TRUE.

• Force AD replication again:

repadmin /syncall /AdeP

• On the target DC, run:

dfsrdiag pollad

• You should see Event ID 4614 and 4604 indicating SYSVOL has been initialized and a D2 (non-authoritative sync) occurred.

• Verify SYSVOL shares, GPO contents and DFSR health

Authoritative SYSVOL Restore (D4)

Use this when other DCs are corrupt or missing SYSVOL and you have a single known-good copy.

High level: stop/start DFSR, mark authoritative in AD on one DC (msDFSR-Options=1), mark others non-authoritative, force AD replication, start DFSR on authoritative server, flip flags and start others.

Steps:

All DC’s

• Stop DFSR service on all DCs in the domain and set Startup Type to Manual (prevents races):

net stop dfsr
sc config dfsr start= demand

Authoritative DC:

• On the DC you want to be authoritative (preferably PDCe), in ADSIEdit edit the SYSVOL subscription DN:

• CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<ServerName>,OU=Domain Controllers,DC=<domain>,DC=<com>

• Set msDFSR-Enabled = FALSE

• Set msDFSR-Options = 1 (this marks it authoritative — the D4 flag)

• Non-Authoritative DCs:

• On every other DC in the domain, edit the same DN and set:

• msDFSR-Enabled = FALSE

• Force AD replication and validate it succeeded across all DCs:

• repadmin /syncall /AdeP

• repadmin /showrepl

• wait until replication has propagated to all DCs.

Authoritative DC:

• Start DFSR on the authoritative DC:

• net start dfsr

• dfsrdiag pollad

• Expect Event ID 4114 (replication stopped, normal after the stop), then later Event ID 4602 when the authoritative initialization completes.

• On the authoritative DC set msDFSR-Enabled = TRUE (ADSIEdit) and force AD replication again:

• repadmin /syncall /AdeP

• dfsrdiag pollad

• Event ID 4602 should appear indicating initialization (D4 completed).

Non-Authoritative DCs:

• Start DFSR on each non-authoritative DC.

• net start dfsr

• On each, you will see Event ID 4114 indicating replication paused (expected).

• Then on each non-authoritative DC, set msDFSR-Enabled = TRUE in ADSIEdit (or you may perform this step before starting the service depending on your ordering),

• Force AD replication

• repadmin /syncall /AdeP

• dfsrdiag pollad

• These DCs will now replicate the authoritative SYSVOL contents from the D4 source.

• When all DCs report successful sync and Event IDs indicating initialization complete, return DFSR service startup type to Automatic on all DCs:

• sc config dfsr start= aut0          

Verify:

• repadmin /replsummary and repadmin /showrepl show healthy replication.

• Get-DfsrBacklog -GroupName "Domain System Volume" -SourceComputer <AuthDC> -DestinationComputer <DC> shows no backlogs.

• Confirm \\domain\SYSVOL content and GPOs match across DCs.

• Monitor DFSR Event Log for absence of 2213 (dirty shutdown) or persistent 5002/5004 errors.

Important cautions & troubleshooting tips

• AD replication is mandatory between the ADSIEdit edits and any DFSR start/poll, if the AD attribute changes don’t replicate, the process fails.

• Use repadmin /showrepl to confirm propagation.

• Do not skip the dfsrdiag pollad and repadmin /syncall /AdeP cycles, these force DCs to pick up the ADSI edits.

• Prefer the PDC Emulator as the authoritative source since it typically has the most recent SYSVOL contents.

• If you encounter Event ID 2213 (dirty shutdown), follow Microsoft guidance for resuming replication (backup DFSR database, ResumeReplication as documented).

• If more than one DC is affected, expand the steps to include all affected DCs (the KB assumes a 2-DC example).

• Always test in an isolated lab before running in production if possible.

Metadata Clean up

When a domain controller (DC) is decommissioned properly using Active Directory Users and Computers or dcpromo, most of its metadata, such as NTDS settings, replication links, and server objects are automatically removed.

However, if a DC fails or is forcefully removed, residual metadata often lingers in AD. These remnants can cause replication errors, ghost entries in Sites and Services, and general directory hygiene issues.

This is where ntdsutil comes in. Running ntdsutil in metadata cleanup mode allows administrators to manually delete orphaned DC objects from the configuration naming context.

Here are the correct steps, Microsoft’s own documentation doesn’t exactly make life easy, leaving out most of the critical parts of the metadata cleanup process.

ntdsutil
metadata cleanup
connections
connect to server <servername>
quit
select operation target
list sites
select site <number>
list domain
select domain <number>
list servers in site
select server <number>
quit
remove selected server <Confirm message>
quit
quit

Go into Sites and Services and remove any remaining existence of the deleted DC.