How to Configure Split Tunneling for VPN on Windows Server 2022

Introduction to Active Directory Backup and Restore

Active Directory is the backbone of most Windows enterprise environments. Losing an AD domain controller without a reliable backup can mean hours or days of downtime, potential data loss, and significant security exposure. Windows Server 2022 provides robust tools for backing up and restoring AD, including the Windows Server Backup utility (wbadmin), Directory Services Restore Mode (DSRM), the AD Recycle Bin, and AD snapshots via ntdsutil. Understanding how all of these interact is critical for every AD administrator.

This guide covers the complete backup and restore lifecycle: creating a System State backup, performing non-authoritative and authoritative restores, recovering deleted objects with the Recycle Bin and tombstone reanimation, and verifying AD health after recovery operations.

System State Backup with wbadmin

The most important backup type for Active Directory is the System State backup. It captures the AD database (NTDS.dit), SYSVOL (Group Policy objects and logon scripts), the registry, boot files, and COM+ class registration data. You must run this as an Administrator.

First, install Windows Server Backup if it is not already present:

Install-WindowsFeature Windows-Server-Backup

To perform a System State backup to a local or network destination:

wbadmin start systemstatebackup -backupTarget:E: -quiet

For a network share destination:

wbadmin start systemstatebackup -backupTarget:\fileserveradbackups -quiet

To list available backup versions stored on a target:

wbadmin get versions -backupTarget:E:

Automate daily System State backups using Task Scheduler. Create a scheduled task that runs at 02:00 every night:

schtasks /create /tn "AD SystemState Backup" /tr "wbadmin start systemstatebackup -backupTarget:E: -quiet" /sc daily /st 02:00 /ru SYSTEM /f

What Is Inside NTDS.dit and SYSVOL

The NTDS.dit file is the Extensible Storage Engine (ESE) database that holds all AD objects: users, groups, computers, OUs, GPO links, schema, and the configuration partition. By default it lives at C:WindowsNTDSntds.dit. Alongside it is a set of transaction log files (edb*.log) that record uncommitted changes.

SYSVOL contains all Group Policy templates and logon/logoff scripts replicated to every DC. Its default path is C:WindowsSYSVOL. SYSVOL is replicated between DCs using DFSR (Distributed File System Replication) on Server 2022. A backup without SYSVOL is insufficient for a full DC recovery.

Booting into Directory Services Restore Mode (DSRM)

Any AD restore operation that touches NTDS.dit requires booting the domain controller into DSRM. DSRM is a special safe mode in which AD services are stopped, allowing the database to be modified or restored. You set the DSRM password during DC promotion; if you have forgotten it, reset it while the DC is online:

ntdsutil
set dsrm password
reset password on server null

quit
quit

To configure the DC to boot into DSRM on the next restart:

bcdedit /set safeboot dsrepair

After the restore is complete, remove the safe boot flag before rebooting normally:

bcdedit /deletevalue safeboot

Non-Authoritative Restore

A non-authoritative restore recovers the DC to the state captured in the backup, then allows normal AD replication to bring the database up to date with changes made on other DCs after the backup was taken. This is the correct approach when a single DC has failed but other DCs are still healthy and hold current data.

Boot into DSRM, log in with the DSRM Administrator password, then run:

wbadmin get versions -backupTarget:E:
wbadmin start systemstaterecovery -version:05/17/2026-02:00 -backupTarget:E: -quiet

Replace the version string with the actual version identifier returned by wbadmin get versions. After the restore completes, remove the safe boot setting and reboot. The DC will contact a replication partner and pull in all changes that occurred after the backup timestamp.

Authoritative Restore with ntdsutil

An authoritative restore is needed when you want to recover deleted or incorrectly modified AD objects and force those recovered objects to replicate out to all other DCs, overriding their current state. Without marking objects as authoritative, replication will simply delete the restored objects again.

First perform a non-authoritative restore as described above, but do NOT reboot yet. While still in DSRM, open a command prompt and run:

ntdsutil
activate instance ntds
authoritative restore
restore subtree "OU=Finance,DC=corp,DC=example,DC=com"
quit
quit

This increments the USN (Update Sequence Number) of all objects in the Finance OU by 100,000, making them appear newer than any version held by replication partners. You can also restore a single object:

ntdsutil
activate instance ntds
authoritative restore
restore object "CN=John Smith,OU=Finance,DC=corp,DC=example,DC=com"
quit
quit

After marking objects authoritative, remove the safe boot flag and reboot. The restored objects will replicate outward to all DCs.

Enabling and Using the AD Recycle Bin

The AD Recycle Bin, available since Windows Server 2008 R2 at Forest Functional Level, preserves all attributes of deleted objects for the duration of the msDS-deletedObjectLifetime period (default 180 days). It must be explicitly enabled and cannot be disabled once active.

Enable the Recycle Bin using PowerShell (requires AD module and Enterprise Admin credentials):

Enable-ADOptionalFeature -Identity 'Recycle Bin Feature' `
  -Scope ForestOrConfigurationSet `
  -Target 'corp.example.com' `
  -Confirm:$false

Verify it is enabled:

Get-ADOptionalFeature -Filter * | Select-Object Name, EnabledScopes

To find and restore a deleted user named John Smith:

Get-ADObject -Filter {displayName -eq "John Smith"} `
  -IncludeDeletedObjects | Select-Object Name, ObjectGUID, Deleted, LastKnownParent

Restore-ADObject -Identity ""

To restore all deleted objects from a specific OU:

Get-ADObject -Filter {LastKnownParent -eq "OU=Finance,DC=corp,DC=example,DC=com"} `
  -IncludeDeletedObjects | Restore-ADObject

Tombstone Reanimation

If the AD Recycle Bin is not enabled and an object has been deleted, it enters a tombstone state. Tombstoned objects retain their GUID and SID but lose most attributes. The tombstone lifetime defaults to 180 days. After that, the object is permanently garbage-collected.

To reanimate a tombstoned object (which recovers fewer attributes than Recycle Bin), you must use ADSI Edit to locate deleted objects. Enable the “Show Deleted Objects” feature in ADSI Edit, connect to the Default Naming Context, navigate to the CN=Deleted Objects container, right-click the tombstoned object, and modify isDeleted to remove the attribute and set distinguishedName to the correct target location.

Alternatively with ldifde — export the tombstoned object, edit the LDIF to remove isDeleted and update the DN, then re-import. This process recovers only the GUID and SID; other attributes must be repopulated manually or from an authoritative restore.

Working with AD Snapshots via ntdsutil

AD snapshots use Volume Shadow Copy Service (VSS) to capture point-in-time images of the NTDS.dit without requiring DSRM. Snapshots are useful for reading historical AD data or for comparison purposes but cannot directly replace a full backup for disaster recovery.

Create a snapshot while AD is running:

ntdsutil
snapshot
activate instance ntds
create
list all
quit
quit

Mount a specific snapshot (replace GUID with the one returned by list all):

ntdsutil
snapshot
activate instance ntds
mount {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
quit
quit

The snapshot mounts as a drive letter. You can then use dsamain.exe to expose the snapshot as an LDAP server and query historical AD data:

dsamain -dbpath C:$SNAP__VOLUMEC$WindowsNTDSntds.dit -ldapport 50000

Connect to it from another machine using ldp.exe on port 50000 or:

Get-ADUser -Server "dc01:50000" -Filter {SamAccountName -eq "jsmith"} -Properties *

Restoring a Domain Controller from Backup

If an entire DC is lost (hardware failure, ransomware), restore it from a full System State or bare-metal backup. Install Windows Server 2022 on replacement hardware, install the Windows Server Backup feature, then from DSRM run the restore:

wbadmin start sysrecovery -version:05/17/2026-02:00 -backupTarget:\fileserveradbackups -quiet

If you are rebuilding a DC in a multi-DC environment and other DCs have current data, it is often faster to demote the failed DC (Uninstall-ADDSDomainController on a surviving DC if the failed DC’s metadata is still present), re-promote a fresh DC, and let replication replicate the entire directory. Use metadata cleanup to remove the stale DC object:

ntdsutil
metadata cleanup
connections
connect to server dc02.corp.example.com
quit
select operation target
list sites
select site 0
list servers in site
select server 1
quit
remove selected server
quit
quit

Verifying AD Health After Restore

After any restore operation, verify AD health before returning the DC to production.

Check replication status across all DCs:

repadmin /replsummary
repadmin /showrepl
repadmin /replicate dc01 dc02 DC=corp,DC=example,DC=com

Run the built-in domain controller diagnostic tool:

dcdiag /test:replications /v
dcdiag /test:netlogons /v
dcdiag /test:advertising /v
dcdiag /test:fsmocheck /v

Verify SYSVOL replication health:

dfsrdiag replicationstate /member:dc01.corp.example.com
Get-DfsrState -ComputerName dc01 | Select-Object * | Format-List

Confirm FSMO role holders are online and accessible:

netdom query fsmo

Check that the NETLOGON and SYSVOL shares are present and accessible:

net share
nltest /server:dc01 /dsgetsite
nltest /server:dc01 /sc_verify:corp.example.com

Finally, check the event logs for replication errors and AD service warnings:

Get-WinEvent -LogName "Directory Service" -MaxEvents 50 | Where-Object {$_.LevelDisplayName -eq "Error"} | Format-List TimeCreated, Message

A successful restore will show zero replication failures in repadmin /replsummary, all dcdiag tests passing, and SYSVOL in a normal (not JRNL_WRAP_ERROR or SYSVOL_NOT_READY) state. Only after all these checks pass should the DC be considered fully recovered and production-ready.