How to Configure 802.1X Network Access Control on Windows Server 2022

Overview of Active Directory Replication

Active Directory replication is the mechanism by which changes made to one domain controller (DC) are propagated to all other domain controllers in the domain and forest. Because Active Directory is a multi-master directory service, any DC can accept writes — including object creation, modification, and deletion. Replication ensures consistency across the entire directory without requiring a single authoritative write point.

There are two primary replication scopes: intra-site replication and inter-site replication. Intra-site replication occurs between domain controllers within the same AD site. It is optimized for speed and low latency — changes typically replicate within 15 seconds using the Knowledge Consistency Checker (KCC) generated ring topology. Inter-site replication occurs between DCs in different sites, typically connected by slower WAN links. It is scheduled and compressed to minimize bandwidth consumption, with administrators defining site link costs, replication intervals, and schedules through Active Directory Sites and Services.

Replication Topology and the KCC

The Knowledge Consistency Checker (KCC) is an internal process running on every domain controller that automatically generates and maintains the replication topology. It creates connection objects between DCs that define which DC replicates from which source, forming a ring topology within each site to guarantee that any change reaches all DCs within two hops. For inter-site replication, the KCC designates Intersite Topology Generators (ISTGs) in each site that are responsible for creating bridgehead connections between sites.

You can view and manually manage connection objects in Active Directory Sites and Services by expanding the Servers container within each site. Manual connection objects override KCC-generated ones and persist even if the KCC would normally remove them. Use manual connections sparingly and only when the automatically generated topology does not meet your needs.

Update Sequence Numbers and Change Tracking

Active Directory uses Update Sequence Numbers (USNs) to track changes on each domain controller. Every DC maintains a local USN counter that increments each time any write occurs. When a change is replicated to another DC, that DC records the highest USN it received from each source DC in a structure called the up-to-dateness vector. This allows each DC to request only changes it has not yet seen, avoiding redundant replication.

A USN rollback is a serious replication problem that occurs when a DC’s USN counter is reverted to a past state — most commonly caused by incorrectly restoring a DC from a snapshot without proper safeguards. When this happens, other DCs believe they have already received changes that the rolled-back DC now claims are new, leading to data inconsistency. Windows Server 2022 includes VM Generation ID protection that detects snapshot-based rollbacks and automatically places the DC in a safe state to prevent USN rollback issues in virtualized environments.

Using repadmin to Monitor and Manage Replication

The repadmin command-line tool is the primary utility for troubleshooting and managing AD replication. It must be run from an elevated command prompt on a domain controller or a machine with the AD DS Remote Server Administration Tools installed.

To get a high-level summary of replication status across all DCs in the domain:

repadmin /replsummary

This command shows each DC, the number of failed and successful replication attempts, and the largest delta (time since last successful replication). Any DC showing failures or a large delta requires investigation.

To view detailed inbound replication status for a specific DC, showing each naming context and its last replication result:

repadmin /showrepl DC01.corp.local

To view all inbound replication partners and their replication metadata across the entire domain:

repadmin /showrepl * /csv > C:replication_report.csv

To force immediate synchronization of all naming contexts on a DC with all its replication partners:

repadmin /syncall DC01.corp.local /AdeP

The flags used above: /A synchronizes all naming contexts, d identifies DCs by distinguished name, e includes inter-site partners, P pushes changes outbound.

To replicate a specific naming context from a specific source DC to a destination DC:

repadmin /replicate DC02.corp.local DC01.corp.local "DC=corp,DC=local"

To check the current replication queue on a DC (useful when replication appears stalled):

repadmin /queue DC01.corp.local

To view the up-to-dateness vector for a specific DC and naming context:

repadmin /showutdvec DC01.corp.local "DC=corp,DC=local"

Forcing Replication with PowerShell

PowerShell provides the Sync-ADObject cmdlet to force replication of a specific AD object to a target DC, which is useful when a change needs to propagate immediately rather than waiting for the scheduled interval:

# Replicate a specific user object to DC02 from DC01
Sync-ADObject `
    -Object "CN=John Smith,OU=Users,DC=corp,DC=local" `
    -Source DC01 `
    -Destination DC02

To monitor replication partner metadata using PowerShell across all DCs:

Get-ADReplicationPartnerMetadata -Target * -Scope Domain | 
    Select-Object Server, Partner, LastReplicationSuccess, LastReplicationResult, ConsecutiveReplicationFailures |
    Sort-Object ConsecutiveReplicationFailures -Descending |
    Format-Table -AutoSize

A value of 0 in LastReplicationResult indicates success. Any non-zero value is a Windows error code indicating why replication failed.

To check replication failure counts across the domain:

Get-ADReplicationFailure -Target * -Scope Domain | 
    Select-Object Server, Partner, FirstFailureTime, FailureCount, LastError |
    Format-Table -AutoSize

Tombstone Lifetime and Object Deletion

When an object is deleted in Active Directory, it is not immediately removed. Instead, it becomes a tombstone — a placeholder object with most attributes stripped and a special isDeleted flag set. Tombstones remain in the directory for the duration of the tombstone lifetime (TSL), which defaults to 180 days on Windows Server 2003 SP1 and later. This ensures that all DCs in the forest have an opportunity to replicate the deletion before the tombstone is garbage collected.

If a domain controller is offline for longer than the tombstone lifetime and is then reconnected, it may contain objects that have already been garbage collected on other DCs. This creates a replication problem called lingering objects. To detect lingering objects:

repadmin /removelingeringobjects DC02.corp.local DC01.corp.local "DC=corp,DC=local" /advisory_mode

Running with /advisory_mode reports lingering objects without removing them. Review the output in the Directory Service event log (Event IDs 1946 and 1942), then run without /advisory_mode to clean them up if confirmed.

To view the current tombstone lifetime for your forest:

Get-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=corp,DC=local" `
    -Properties tombstoneLifetime | Select-Object tombstoneLifetime

SYSVOL Replication

SYSVOL is a shared directory structure replicated to all domain controllers in the domain. It contains Group Policy Objects (GPOs) and logon scripts. Modern domains use DFS-R (Distributed File System Replication) to replicate SYSVOL, which replaced the legacy FRS (File Replication Service). To verify SYSVOL replication status using DFS-R:

# Check DFS-R replication service status
Get-Service DFSR

# View DFS-R replication group membership for SYSVOL
Get-DfsrMembership -GroupName "Domain System Volume" | 
    Select-Object ComputerName, FolderName, State, Enabled | 
    Format-Table -AutoSize

# Check for DFS-R backlog between two DCs
Get-DfsrBacklog -GroupName "Domain System Volume" `
    -FolderName "SYSVOL Share" `
    -SourceComputerName DC01 `
    -DestinationComputerName DC02 | 
    Measure-Object | Select-Object Count

For domains still using FRS, use the legacy ntfrsutl tool to check replication health:

ntfrsutl sets DC01
ntfrsutl ds DC01

To migrate from FRS to DFS-R for SYSVOL replication, use the dfsrmig tool and migrate through the four stages (Start, Prepared, Redirected, Eliminated):

dfsrmig /setglobalstate 1   # Prepared
dfsrmig /setglobalstate 2   # Redirected
dfsrmig /setglobalstate 3   # Eliminated (FRS removed)
dfsrmig /getmigrationstate  # Check all DCs completed each state

Resolving Common Replication Errors

Replication error 8614 (ERROR_DS_DRA_SOURCE_DISABLED) indicates that a source DC has been offline for longer than the tombstone lifetime and replication has been blocked by Active Directory to prevent propagation of stale data. To resolve this, either demote and re-promote the affected DC, or if confident the DC is current, clear the replication quarantine using:

repadmin /regkey DC01 +allowDivergent

Replication error 1753 indicates the RPC Endpoint Mapper could not register a service — typically caused by firewall rules blocking TCP port 135 and the dynamic RPC port range. On Windows Server 2022 DCs, open the required ports:

netsh advfirewall firewall add rule name="AD Replication TCP 135" `
    protocol=TCP dir=in localport=135 action=allow

netsh advfirewall firewall add rule name="AD Replication RPC Dynamic" `
    protocol=TCP dir=in localport=49152-65535 action=allow

Replication error 8453 (Replication access was denied) usually means the DC computer account lacks the required permissions on the directory partition. Verify that the DC’s computer account is a member of the Enterprise Domain Controllers group and has the Replicating Directory Changes and Replicating Directory Changes All permissions on the domain naming context.

Monitoring Replication with Event Logs

Active Directory replication events are written to the Directory Service event log on each DC. Key event IDs to monitor include 1566 (replication failure), 1864 (replication latency warning — DC not replicated in X days), 2087 (DNS lookup failure during replication), and 1925 (failed to establish replication link). Query these events with PowerShell:

Get-WinEvent -ComputerName DC01 -FilterHashtable @{
    LogName = 'Directory Service'
    Level = 1, 2    # Critical and Error
    StartTime = (Get-Date).AddDays(-3)
} | Select-Object TimeCreated, Id, LevelDisplayName, Message |
    Format-Table -AutoSize -Wrap

For comprehensive replication health monitoring across all DCs in the domain, the built-in dcdiag tool provides a suite of diagnostic tests:

# Run all replication-related tests on all DCs in the domain
dcdiag /test:replications /e /v /f:C:dcdiag_report.txt

The /e flag tests all servers in the enterprise, /v enables verbose output, and /f saves results to a file. Review the output for FAILED entries and address each one systematically. Running dcdiag /test:replications as part of a weekly health check routine will catch replication latency issues before they become critical failures.