Active Directory Policy and SYSVOL
Diagnose a legacy FRS SYSVOL
Read FRS journals, change orders, partner state, morphed folders, and recovery evidence without confusing them with DFSR.
Historical reference · true
Establish that FRS actually owns SYSVOL
These notes are for an inherited FRS replica set. Check the domain’s migration state and actual share paths first; old FRS logs can remain after SYSVOL has moved to DFSR. Windows Server 2019 and later DC promotion requires DFSR SYSVOL. Use the migration checks to find the current engine, and DFSR recovery for a DFSR replica.
Preserve the affected DC’s files, logs, share paths, and directory configuration before reinitializing anything. A functioning directory-replication connection does not prove that FRS has joined its SYSVOL replica set or installed the required files.
Follow a change through distinct stages
FRS watches the volume’s NTFS change journal, finds relevant changes, records change orders, stages file content, talks to partners, and installs received changes. Its database tracks file identities and what partners know. A file can go missing at the detection, filtering, staging, communication, or installation stage. Work out which one failed before treating it as a general “replication failure.” The historical FRS architecture reference describes these stages.
With the legacy FRS tools installed and permission to inspect the named server:
ntfrsutl sets DC1
ntfrsutl ds DC1
ntfrsutl inlog DC1
ntfrsutl outlog DC1
ntfrsutl idtable DC1
ntfrsutl poll DC1
Save the output and collection time. sets lists active replica sets and partners; ds shows the service’s directory view; inlog and outlog show incoming and outgoing work; idtable tracks known file/folder identities. Match the replica-set, connection, partner, and file GUIDs before comparing rows. The Ntfrsutl reference documents these commands. poll /now asks the service to consume configuration and changes its activity; it won’t repair AD replication or recover missing file history.
An outbound backlog can implicate the downstream member
Work waiting at DC1 for DC2 doesn’t automatically mean DC1 can’t send. DC2 might be unreachable, unable to join, unable to install, or in journal wrap. Compare the same direction at both ends, check the partner’s state, and see whether the outstanding change-order identities advance between samples. A growing backlog while new changes arrive is different from a fixed backlog with no successful partner communication.
A newly established partner can require a version-vector join and substantial inventory comparison. Several simultaneous joins on a busy hub can compete for disk and CPU. Avoid manufacturing additional joins by deleting connections or repeatedly reinitializing members while measuring the original problem.
Event evidence needs a sequence
| Event | Interpretation and next evidence |
|---|---|
| 13508 | The named replication connection is failing. Check the exact partner’s DNS, FRS service, RPC path, and arriving topology. |
| 13509 | A previously failing connection was established. It does not establish that all files are current. |
| 13522 | Staging pressure. Inspect free space, staging configuration, workload, and partners retaining work. |
| 13565 / 13566 | Non-authoritative / authoritative initialization began. Follow the resulting join and content evidence. |
| 13516 | SYSVOL initialization has completed sufficiently for FRS to advertise readiness; verify the expected data and shares as well. |
| 13568 | The required NTFS journal record is unavailable. Investigate journal continuity and select a supported reinitialization plan. |
Read the full replica-set, path, partner, and status fields in the FRS event reference. Check whether an old warning was followed by recovery or is still happening. A blanket four-hour wait won’t tell you what the actual schedule and business impact require.
Journal wrap is a loss of change history
The NTFS journal belongs to the volume, not only to SYSVOL. Unrelated high-volume activity can overwrite records before FRS consumes them. A long service outage, journal deletion/truncation, or inability to keep up can break continuity. Increasing capacity afterward does not reconstruct the lost records.
Check whether FRS was stopped and what else changed on that volume. Preserve files edited locally during the stalled period, especially on the DC administrators used for GPO edits. A non-authoritative reinitialization can replace those files with an older partner’s copy even though their GPC changes replicated successfully through AD.
The journal-wrap article is explicitly historical Windows 2000 guidance. Its explanation remains useful; its service-pack sizing values are not current defaults. It specifically rejects general use of Enable Journal Wrap Automatic Restore on later systems. Reinitialize using the documented BurFlags procedure after selecting and preserving the required data.
Morphed folders identify conflicting identities
Policies_NTFRS_01234567 is a name-conflict result, not an ordinary temporary folder. Two same-named folders independently created on different replicas have different FRS identities. Manually copying a tree to every DC can create exactly this condition.
Cleanup changes replicated data: save every candidate tree first. Microsoft’s morphed-folder procedure renames the competing folders, waits for the names to converge, selects the required identity/content, and restores the intended name before removing the unwanted folders. Don’t delete one folder and immediately rename the other; the procedure specifically warns against that. Expect the affected policy paths to be unavailable during the operation. Check that each member has the same chosen identity and required contents before cleanup.
D2 and D4 select authority, not health
State-changing recovery: the BurFlags procedure distinguishes D2 (take data from a healthy partner) from D4 (declare this member’s inventory authoritative). Its global key affects the server’s FRS replica sets; use the documented replica-specific scope when other sets must be preserved. D2 can move local-only files into Pre-existing; inspect and reconcile them after synchronization.
Before D2, verify a healthy upstream copy, schedule, connectivity, available space, and backups of unique local content. For a complete replica-set rebuild, choose one validated authoritative source and prepare the other members for non-authoritative initialization in the documented sequence. Multiple independent authoritative sources defeat that decision. Afterward, verify initialization events, shares, identities, representative policy/script content, and both AD and file replication. A coordinated rebuild is a recovery operation, not routine backlog maintenance.
SYSVOL publication also depends on its physical tree and junctions. If those are damaged, use the SYSVOL tree reconstruction procedure with the actual configured paths. Setting SysVolReady alone does not rebuild the tree or replicate the files.