Decoding FRS Event Log Errors: A Windows Server Troubleshooting Guide
This article provides a comprehensive guide to interpreting and troubleshooting common event log entries generated by the File Replication Service (FRS) on Windows Server. Understanding these events is crucial for maintaining the health and functionality of services relying on FRS, such as SYSVOL replication in older Active Directory environments. Each Event ID discussed represents a specific condition or issue encountered by the FRS service, ranging from informational messages to critical errors preventing replication.
The File Replication Service plays a vital role in distributing and maintaining consistent copies of files and folders across multiple servers, particularly for the SYSVOL share in domain controllers. When FRS encounters problems, it logs specific events in the Windows Event Log, providing valuable insights into the nature of the issue. Promptly addressing these errors is essential to ensure proper directory service operation and file synchronization. The following sections detail various FRS Event IDs and their associated troubleshooting steps.
Service Startup, Shutdown, and Basic State Events (Event ID 13500-13506)¶
This range of Event IDs indicates the basic operational state of the File Replication Service. Errors in this range often point to fundamental issues preventing the service from running correctly.
- Event ID=13500
- Severity=Error
- File Replication Service
- Description: A generic error indicating an issue with the FRS service. The specific cause would typically be detailed in subsequent or preceding event log entries.
- Event ID=13501
- Severity=Informational
- The File Replication Service is starting.
- Description: An informational message indicating that the FRS service is initiating its startup sequence. This is expected behavior during system boot or manual service start.
- Event ID=13502
- Severity=Informational
- The File Replication Service is stopping.
- Description: An informational message indicating that the FRS service is in the process of stopping. This can occur during system shutdown or a manual service stop operation.
- Event ID=13503
- Severity=Informational
- The File Replication Service has stopped.
- Description: An informational message confirming that the FRS service has successfully stopped. This event often follows Event ID 13502.
- Event ID=13504
- Severity=Error
- The File Replication Service stopped without cleaning up.
- Description: This error indicates that FRS stopped unexpectedly or was terminated abnormally, preventing it from performing its normal shutdown procedures. This could leave the service in an inconsistent state.
- Event ID=13505
- Severity=Error
- The File Replication Service has stopped after taking an assertion failure.
- Description: An assertion failure is a software error where a condition expected to be true was not met. This suggests an internal logic error within the FRS service code, leading to a critical stop.
- Event ID=13506
- Severity=Error
- The File Replication Service failed a consistency check (%3) in “%1” at line %2.
- Description: Similar to an assertion failure, this error points to an internal inconsistency detected by the service during its operation, indicating a potential bug or data corruption issue.
When any of these error Event IDs (13500, 13504, 13505, 13506) appear, the File Replication Service is often configured to attempt an automatic restart after a certain delay. If these errors persist, examining the recovery settings configured for the service can provide insight into how it’s configured to handle failures. You can view these settings by opening Computer Management (run compmgmt.msc), navigating to System Tools > Services, right-clicking File Replication Service, selecting Properties, and then viewing the Recovery tab. Persistent errors usually require deeper investigation into the system state or configuration.
Volume and File System Issues (Event ID 13507, 13511, 13512, 13570, 13571)¶
These events highlight problems related to the disk volumes where FRS stores its replicated data, staging files, or database. Issues with file system type, free space, or volume configuration can prevent FRS from operating correctly.
- Event ID=13507
- Severity=Error
- The File Replication Service can’t start replica set %1 on computer %2 for directory %3 because the type of volume %4 isn’t NTFS 5.0 or later.
- Description: FRS requires volumes formatted with NTFS version 5.0 or later to function, as it relies on features like the USN journal. This error occurs when a volume designated for replication does not meet this requirement.
- Troubleshooting: Verify the volume type by running
chkdsk %4at the command prompt. If the volume is not NTFS 5.0 or later (e.g., FAT32 or an older NTFS version), it must be upgraded. You can attempt to upgrade the volume to NTFS 5.0 or later using the commandchkntfs /E %4. Ensure the volume is healthy before attempting replication.
- Event ID=13511
- Severity=Error
- The File Replication Service is stopping on computer %1 because there is no free space on the volume containing %2.
- Description: FRS operations, especially staging files before replication, require sufficient free disk space on the volume hosting the replicated folders, staging area, or database. This error indicates that the required disk space is unavailable.
- Troubleshooting: Check the available space on the affected volume using
dir %2. Free up space by deleting unnecessary files. Once space is available, restart the FRS service usingnet start ntfrs. FRS is typically configured to retry automatically, but a manual restart can expedite recovery. Review the service’s recovery settings for details on automatic restarts.
- Event ID=13512
- Severity=Warning
- The File Replication Service has detected an enabled disk write cache on the drive containing the directory %2 on the computer %1.
- Description: While not an error that stops the service, this is a warning about a configuration that could lead to data loss or inconsistency if there is a power interruption. Disk write caching can delay writes to the physical disk.
- Troubleshooting: For critical volumes hosting FRS data, it is generally recommended to disable write caching for reliability, though this may impact disk performance. This setting is typically configured in Device Manager for the disk drive.
- Event ID=13570
- Severity=Error
- The File Replication Service has detected that the volume hosting the path %1 is low on disk space. Files may not replicate until disk space is made available on this volume.
- Description: Similar to Event ID 13511, this error explicitly states that a volume critical to FRS (database, staging, or root path) is running out of space, halting replication.
- Troubleshooting: Use
dir /a %1to check the free space on the volume. Free up space by deleting unneeded files. Common commands for managing files and directories includecopy /?,rename /?,del /?,rmdir /?, anddir /?. Once sufficient space is recovered, replication should resume automatically or after restarting the FRS service.
- Event ID=13571
- Severity=Error
- The File Replication Service has detected that one or more volumes on this computer have the same Volume Serial Number. File Replication Service doesn’t support this configuration. Files may not replicate until this conflict is resolved.
- Description: FRS uses the Volume Serial Number as part of its internal tracking mechanisms. Duplicate serial numbers on a single system are not supported and prevent FRS from uniquely identifying volumes.
- Troubleshooting: This usually indicates a configuration issue with disk management or virtualization. Identify the volumes with the duplicate serial number using the
dircommand (which shows the serial number before the directory listing) for the paths listed in the event (%2). Resolving this often involves correcting the disk configuration or reformatting one of the volumes with a new serial number (which may require data backup and restore).
Network and Communication Failures (Event ID 13508, 13509, 13510)¶
These Event IDs relate to FRS’s ability to communicate with its replication partners over the network, often involving DNS and RPC issues.
- Event ID=13508
- Severity=Warning
- The File Replication Service is having trouble enabling replication from %1 to %2 for %3 using the DNS name %4. FRS will keep retrying.
- Description: This warning indicates that FRS on server %1 is unable to establish a replication connection to partner %2 for replica set %3 using the DNS name %4. FRS is designed to be resilient and will repeatedly attempt the connection.
- Possible Reasons: Common causes include:
- The computer experiencing the error cannot resolve the DNS name %4.
- The FRS service is not running on the partner computer %4.
- Active Directory replication delays have prevented the FRS topology information (connections, replica sets) from reaching all domain controllers involved.
- Troubleshooting: Address the possible reasons. Verify DNS resolution of %4 from %1 using
ping %4ornslookup %4. Ensure FRS is running on %4 (net start ntfrs). Check Active Directory replication health using tools likerepadmin. This warning typically resolves itself once the underlying network or service issue is fixed, followed by Event ID 13509.
- Event ID=13509
- Severity=Warning
- The File Replication Service has enabled replication from %1 to %2 for %3 after repeated retries.
- Description: This warning is a positive sign, indicating that the FRS service successfully established a replication connection to partner %2 after previous attempts had failed (potentially indicated by Event ID 13508). This usually means the underlying issue was temporary or has been resolved.
- Event ID=13510
- Severity=Error
- The File Replication Service on the computer %1 can’t communicate with the File Replication Service on the computer %2.
- Description: This is a more severe communication error than 13508, indicating a complete inability for FRS on %1 to communicate with FRS on %2. This prevents replication between these specific partners.
- Troubleshooting: Follow these systematic steps:
- Verify that computer %2 is online and running.
- Confirm the FRS service is running on %2 by typing
net start ntfrson %2. - Check network connectivity: Type
ping %2on %1 andping %1on %2. Successful pings indicate basic network reachability. If pings fail, investigate network routing, firewalls, or DNS. - Diagnose DNS issues: Use
ipconfig /allon both servers to check IP configuration and DNS server addresses.ping <DNS server IP address>verifies DNS server availability. Usenslookupon both servers to verify that %1 correctly resolves %2 and vice-versa. DNS problems on either server can cause communication failures. - Flush DNS Resolver Cache:
ipconfig /flushdnson both servers can clear incorrect cached entries. - Renew IP Address (if using DHCP):
ipconfig /releasefollowed byipconfig /renew. - Restart NetLogon Service:
net stop NetLogonfollowed bynet start NetLogoncan re-register DNS entries and service principal names. - Restart FRS Service:
net stop ntfrsfollowed bynet start ntfrs. - Restart Servers: As a last resort, restart both computers %1 and %2, especially if recent configuration changes (like dcpromo) were made.
Database and Corruption Issues (Event ID 13513)¶
The FRS service uses an internal database to track file changes and replication state. Corruption of this database can lead to the service stopping.
- Event ID=13513
- Severity=Error
- The File Replication Service on computer %1 is stopping because the database %2 is corrupted.
- Description: This critical error indicates that the Jet database used by FRS, located at %2, is damaged and prevents the service from operating.
- Troubleshooting: The recommended action is to repair the database. Open a command prompt and run
esentutl /d %2. Replace%2with the actual path to the corrupted database file shown in the event details. Note thatesentutl /dperforms an offline defragmentation and repair. Once the database repair is successful, restart the File Replication Service by typingnet start ntfrs. If repair fails or the service still doesn’t start, a more drastic recovery might be needed, potentially involving rebuilding the replica set.
Initial Synchronization and SYSVOL Readiness (Event ID 13514, 13515, 13516, 13565, 13566)¶
These events are common during the initial setup of a domain controller or when a server is added to an FRS replica set. They indicate that FRS is performing the initial synchronization process.
- Event ID=13514
- Severity=Warning
- File Replication Service is initializing the system volume with data from another domain controller. Computer %1 cannot become a domain controller until this process is complete. The system volume will then be shared as SYSVOL.
- Description: During the promotion of a server to a domain controller (DC), FRS synchronizes the SYSVOL share content from an existing DC. Until this initial sync is complete, the new server is not fully operational as a DC, and the SYSVOL share will not be available.
- Monitoring: You can check for the SYSVOL share availability by running
net shareat the command prompt. The presence of the SYSVOL share indicates that FRS initialization is complete for that critical replica set. - Context: The duration of this process depends on the size of the SYSVOL data, network speed, and the replication partners’ availability and schedule.
- Event ID=13515
- Severity=Warning
- The File Replication Service may be preventing the computer %1 from becoming a domain controller while the system volume is being initialized and then shared as SYSVOL.
- Description: This event reinforces that FRS initialization is a prerequisite for a server to fully function as a domain controller and share SYSVOL. It’s not an error but a status update.
- Monitoring: Use
net shareto check for the SYSVOL share. - Workaround (Not Recommended): The system volume initialization can be bypassed by setting the
SysvolReadyregistry value to1underHKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parametersand restarting the Netlogon service (net stop netlogonfollowed bynet start netlogon). This action is strongly discouraged as it can lead to unexpected application failures if the SYSVOL content is not fully synchronized.
- Event ID=13516
- Severity=Informational
- The File Replication Service is no longer preventing the computer %1 from becoming a domain controller. The system volume has been successfully initialized and the Netlogon service has been notified that the system volume is now ready to be shared as SYSVOL.
- Description: A positive informational event confirming that the initial FRS synchronization for SYSVOL is complete, and the Netlogon service has been notified to share SYSVOL.
- Verification: Run
net shareto confirm the SYSVOL share is present.
- Event ID=13565
- Severity=Warning
- File Replication Service is initializing the system volume with data from another domain controller. Computer %1 cannot become a domain controller until this process is complete. The system volume will then be shared as SYSVOL.
- Description: This appears to be a duplicate of Event ID 13514, carrying the same meaning regarding SYSVOL initial synchronization during DC promotion.
- Monitoring: Use
net shareto check for the SYSVOL share. The process time varies based on data volume, partner availability, and replication intervals.
- Event ID=13566
- Severity=Warning
- File Replication Service is scanning the data in the system volume. Computer %1 cannot become a domain controller until this process is complete. The system volume will then be shared as SYSVOL.
- Description: Before or during initial synchronization, FRS may scan the local system volume. This event indicates this scanning process is underway and is a necessary step before SYSVOL is fully ready.
- Monitoring: Use
net shareto check for the SYSVOL share. The share appears once the scan and subsequent initialization/sync are finished. The duration depends on the data volume.
Access Check and Permissions Issues (Event ID 13517, 13518, 13519)¶
These events relate to FRS checking user or system permissions when interacting with specific APIs or resources.
- Event ID=13517
- Severity=Warning
- The File Replication Service won’t check access to the API “%1”.
- Description: This warning indicates that FRS is configured not to perform access checks for a specific API (%1). While this might be intentional for performance or compatibility, it could potentially bypass security restrictions.
- Configuration: Access checks can be enabled via the registry. Navigate to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Access Checksinregedit. Find the values corresponding to %1 and %2 (likely parameter names mentioned in the API context) and change their string data to Enabled. - Permissions: Permissions for the specific API or related registry key can be adjusted by right-clicking the relevant item in regedit and selecting Permissions.
- Event ID=13518
- Severity=Warning
- The File Replication Service did not grant the user “%3” access to the API “%1”.
- Description: This warning signifies that a specific user account (%3) attempted to access an FRS API (%1) but was denied based on the configured permissions.
- Troubleshooting: Review and modify permissions for the API or resource. Open
regeditand go toHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Access Checks. Right-click the value related to %1 and select Permissions… to adjust who has access. - Disabling Check (Use Caution): Access checks for %1 can be disabled by double-clicking the corresponding value (%2) under the
Access Checkskey and changing its string data to Disabled. This should only be done if you understand the security implications.
- Event ID=13519
- Severity=Error
- The File Replication Service could not grant an unknown user access to the API “%1”.
- Description: This error indicates that an attempt was made to access FRS API %1 by a security principal that FRS could not identify or authenticate. This could be due to trust issues, incorrect credentials, or problems resolving the user’s identity.
- Troubleshooting: Investigate why the user is appearing as “unknown.” Check domain trusts, user account status, and network authentication issues.
- Disabling Check (Use Caution): Similar to 13518, access checks can be disabled for %1 via
regeditunderHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Access Checksby changing the values for %1 and %2 to Enabled (note: the description says “change %1 and %2 strings to Enabled” but the error implies denying access, so disabling the check might be the intent if bypassing security is accepted). Review permissions by right-clicking %1 underAccess Checksand selecting Permissions….
Pre-Existing Files and Staging Area Issues (Event ID 13520, 13522, 13523)¶
These events relate to how FRS handles files already present in a replica directory during setup and issues with the staging area used for replication.
- Event ID=13520
- Severity=Warning
- The File Replication Service moved the pre-existing files in %1 to %2.
- Description: When FRS is configured to replicate a directory (%1) that already contains files, it moves these existing files to a pre-existing directory (%2) before performing the initial synchronization. This is a normal part of the setup process for non-SYSVOL replica sets.
- Context: Files in %2 are considered pre-existing and are handled separately from replicated files. They may be deleted by FRS later. If you need to preserve any files from %2, copy them to a different location outside the replica path or the pre-existing files directory. Copying them back into %1 might cause conflicts during replication if other partners already have files with the same names. Space can be recovered by manually deleting files in %2 if they are no longer needed.
- Event ID=13522
- Severity=Warning
- The File Replication Service paused because the staging area is full. Staging files are used to replicate created, deleted, or modified files between partners. FRS will automatically remove least recently used files from this staging area (in the order of the longest time since the last access) until the amount of space in use has dropped below 60% of the staging space-limit, after which replication will resume.
- Description: FRS uses a staging area to temporarily store file changes before replicating them. If this area fills up (reaches its configured limit), FRS pauses replication until space is freed. FRS attempts to automatically clean up older files to stay below 60% of the limit.
- Troubleshooting: If this happens often, it suggests replication cannot keep up with the rate of file changes or the staging area limit is too low.
- Ensure direct outbound replication partners are online and actively receiving updates.
- Verify that replication schedules with partners allow sufficient time windows for replication.
- Consider increasing the staging area size limit.
- Increasing Staging Limit: Open
regedit, navigate toHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters, and modify the DWORD value Staging Space Limit in KB. Increase this value (in kilobytes) based on the volume of changes and available disk space.
- Event ID=13523
- Severity=Warning
- The File Replication Service paused because the size of a file exceeds the staging space limit. Replication will resume only if the staging space limit is increased.
- Description: This warning indicates that a single file being replicated is larger than the entire configured staging area limit. Unlike Event 13522, which signifies the total staging area is full, this specifically points to one large file being the culprit.
- Troubleshooting: Replication for this file (and potentially other files if the limit is insufficient) is blocked until the staging limit is increased to accommodate the largest file size.
- Increasing Staging Limit: Open
regedit, navigate toHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters, and modify the DWORD value Staging Space Limit in KB. Increase this value significantly to be larger than the size of the largest file you expect to replicate.
RPC, Performance Counters, and Overlapping Path Errors (Event ID 13524, 13527-13546)¶
This large block of events covers various internal errors, including issues with RPC communication (often related to performance counter access), inability to generate unique identifiers, and configuration errors where FRS paths overlap.
- Event ID=13524
- Severity=Error
- The File Replication Service is stopping on the computer %1 because a universally unique ID (UUID) cannot be created.
- Description: FRS requires the ability to generate UUIDs for internal operations. This error occurs if the underlying system call (
UuidCreate()) fails. This often points to fundamental system issues, potentially related to network adapter presence or functionality, as UUID generation can sometimes rely on network addresses. - Troubleshooting: Verify that the server has at least one properly functioning network adapter (Ethernet or Token Ring) with a valid network address. Ensure network drivers are correctly installed. This is a serious error requiring immediate investigation of the server’s hardware and operating system configuration. The service will attempt to restart automatically, as configured in its recovery properties.
- Event ID 13527 to 13538 (RPC and Performance Counter Errors)
- Severity=Error
- Descriptions: These events indicate failures related to accessing performance counter data for FRS using Remote Procedure Call (RPC). Issues include RPC binding failures (
13527, 13528, 13531, 13532) or RPC call failures (13529, 13530, 13533, 13534), often occurring in theOpenorCollectfunctions for theFileReplicaSetorFileReplicaConnperformance objects. Errors 13535 and 13536 relate to memory allocation (VirtualAlloc) failure for performance counters, and 13537 and 13538 indicate registry access failures related to performance counter setup. - Impact: When these errors occur, the performance counter data for FRS replica sets and connections will not be available, hindering performance monitoring. The underlying FRS replication might still function, but visibility is lost.
- Troubleshooting: These errors usually point to issues with the performance counter library, RPC services, or system resources.
- Check system event logs for related RPC or service control manager errors.
- Ensure the Remote Procedure Call (RPC) service is running.
- Use
lodctr /Randunlodctr /Rto rebuild the performance counter registry (run from an elevated command prompt). You may need to unload and then load thentfrsperformance counters specifically. - Check system memory usage if
VirtualAllocfailures are reported. - Verify system account permissions to access performance counter registry keys under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\PerflibandHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Performance.
- Event ID 13539 to 13545 (Overlapping Path Errors)
- Severity=Error
- Descriptions: This series of errors indicates configuration problems where the paths configured for different FRS components (replica root, staging area, working directory, logging directory) overlap or are contained within one another. FRS requires these paths to be distinct to avoid conflicts.
13539: Replica directory path is invalid or inaccessible.13540: Customer designated staging directory path is invalid or inaccessible.13541: Replica path overlaps logging path.13542: Replica path overlaps working directory.13543: Replica path overlaps staging directory.13544: Replica path overlaps another replicating directory.13545: Replica path overlaps the staging directory of another replicating directory.
- Troubleshooting: Examine the FRS configuration to identify the conflicting paths. The paths are usually configured in Active Directory (for SYSVOL and DFS replica sets managed by AD) or the registry (for standalone FRS replica sets). Ensure that the root path for a replica set, its staging directory, the FRS working directory, and the debug log directory are all on different, non-overlapping paths. Correct the configuration in AD Sites and Services or the registry as needed. Ensure the specified paths exist and are accessible by the FRS service account.
- Event ID=13546
- Severity=Error
- The File Replication Service could not prepare the root directory %1 for replication. This is likely due to a problem creating the root directory or a problem removing pre-existing files in the root directory.
- Description: During the setup of a replica set, FRS failed to prepare the designated root directory (%1). This could involve issues with directory creation, permissions, or handling existing content.
- Troubleshooting: Verify that the path leading up to the root directory exists and is accessible by the FRS service account. Check file system permissions on the parent directory where FRS is trying to create or manage %1. If %1 already exists, ensure FRS has permissions to read, write, and delete files within it.
Configuration Parameter Errors (Event ID 13547)¶
This event indicates that FRS detected an invalid value for a configuration parameter in the registry.
- Event ID=13547
- Severity=Warning
- The File Replication Service detected an invalid parameter value in the registry. %1. The expected registry key name is “%2”. The expected value name is “%3”. The expected registry data type is %4. The allowed range for this parameter is %5. The data units for this parameter value are %6. The File Replication Service is using a default value of “%7”.
- Description: FRS found a registry setting with a value that is outside the acceptable range, has the wrong data type, or is otherwise invalid. It will fall back to using a default value (%7) for the parameter %3 located at key %8.
- Troubleshooting: Correct the registry value. Open
regedit, navigate to the key path “%8” (replace %8 with the actual path from the event details). Locate the value name “%3” (add it if it’s missing). Ensure the data type matches “%4” (e.g., REG_DWORD, REG_SZ). Modify the value to be within the allowed range “%5”, keeping in mind the data units “%6”.
Time Synchronization Issues (Event ID 13548, 13549)¶
Accurate time synchronization is critical for FRS replication. Significant time differences between partners can lead to replication failures.
- Event ID=13548
- Severity=Error
- The File Replication Service is unable to replicate with its partner computer because the difference in clock times is outside the range of plus or minus %1 minute. The connection to the partner computer is: “%2” The detected time difference is: %3 minutes.
- Description: FRS detected a substantial clock skew between the local computer and its replication partner %2. If the difference exceeds the configured threshold (%1 minutes), replication is stopped to prevent inconsistencies.
- Troubleshooting: Correct the time synchronization on both the local computer and the partner %2. Ensure both servers are synchronizing time with a reliable source (e.g., a domain hierarchy’s PDC emulator or an external NTP server). If the time difference is close to a multiple of 60 minutes, check the time zone settings on both computers.
- Adjusting Skew Tolerance (Not Recommended): The default time skew tolerance can be changed via
regeditatHKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parametersby modifying the DWORD value Partner Clock Skew In Minutes. Increasing this value is not generally recommended as it masks the underlying time sync problem.
- Event ID=13549
- Severity=Error
- The File Replication Service is unable to replicate from a partner computer because the event time associated with the file to be replicated is too far into the future. It is %1 minute greater than the current time. This can happen if the system time on the partner computer was set incorrectly when the file was created or updated. To preserve the integrity of the replica set this file update will not be performed or propagated further. The file name is: “%2” The connection to the partner computer is: “%3”
- Description: FRS received an update for file %2 from partner %3, but the timestamp on the change is significantly in the future compared to the local server’s time. FRS rejects this update to prevent propagating potentially incorrect future timestamps, which could cause issues.
- Troubleshooting: The primary cause is incorrect time or time zone settings on the partner computer %3 at the time the file %2 was modified. Correct the time and time zone on the partner server %3. This file update will likely replicate correctly once the time is fixed and the file is modified again on the source. If the difference is near a multiple of 60 minutes, check the time zone on the partner server.
Staging and Pre-Install Directory Issues (Event ID 13550, 13551)¶
These events specifically relate to FRS’s inability to access or create necessary subdirectories within the replica set’s root path or staging area.
- Event ID=13550
- Severity=Error
- The File Replication Service is unable to open the customer designated staging directory for replica set %1. The path used for the staging directory is, “%2” The customer designated root path for this replica set is: “%3”
- Description: FRS cannot access the configured staging directory %2 for replica set %1. This prevents FRS from preparing files for replication.
- Possible Causes: Common issues include: an invalid path specified for the staging directory, the directory does not exist, the disk volume is missing or inaccessible, the volume’s file system does not support ACLs (Access Control Lists, required by NTFS), or another application is exclusively locking the staging directory.
- Troubleshooting: Verify the staging directory path %2 exists and is correct. Ensure the volume hosting %2 is online and healthy. Confirm the volume is formatted with NTFS. Check file system permissions on %2 to ensure the FRS service account has full control. Use tools like Process Explorer to see if any other process is locking files or the directory within %2. Correct the problem, and FRS will attempt to restart replication automatically.
- Event ID=13551
- Severity=Error
- The File Replication Service is unable to open (or create) the pre-install directory under the customer designated replica tree directory for replica set %1. The path used for the pre-install directory is, “%2” The customer designated root path for this replica set is: “%3”
- Description: FRS failed to access or create the required “pre-install” subdirectory (%2) within the root path (%3) for replica set %1. This directory is used temporarily during the inbound replication of files.
- Possible Causes: Similar to staging area issues, this could be due to an invalid root path, missing directory, missing disk volume, a file system not supporting NTFS 5.0 (required for FRS), or a sharing conflict on the pre-install directory.
- Troubleshooting: Verify the root path %3 is valid and exists. Ensure the volume hosting %3 is online and healthy and formatted with NTFS 5.0 or later. Check permissions on %3 to ensure the FRS service account can create subdirectories and manage files within it. Check for locking issues on %2 or %3 by other applications. Correct the problem; FRS will retry automatically.
Replica Set Membership and Configuration Issues (Event ID 13552, 13553, 13554, 13556, 13557, 13558)¶
These events relate to FRS adding or failing to add a computer or connection to a replica set, and issues with configuration changes like root path modifications or duplicate connections.
- Event ID=13552
- Severity=Error
- The File Replication Service is unable to add this computer to the following replica set: “%1” Information below may help to resolve the problem: Computer DNS name is “%2” Replica set member name is “%3” Replica set root path is “%4” Replica staging directory path is “%5” Replica working directory path is “%6” Windows error status code is %7 FRS error status code is %8
- Description: FRS failed to successfully add the local computer (%2/%3) as a member of replica set %1. This prevents replication for this set on this server. The event provides details about the computer’s configuration for the replica set and specific Windows (%7) and FRS (%8) error codes.
- Possible Causes: Invalid root path (%4), missing directories (%4, %5, %6), missing disk volumes, or file systems not supporting NTFS 5.0. The error codes %7 and %8 provide specific clues.
- Troubleshooting: Use the detailed information provided. Check that the paths %4, %5, and %6 exist and are accessible. Ensure the volumes are healthy and NTFS 5.0+. Look up the specific Windows error code %7 for more details. Review other FRS event logs for related issues. Correct the underlying problem, and FRS will retry adding the member automatically.
- Event ID=13553
- Severity=Informational
- The File Replication Service successfully added this computer to the following replica set: “%1” Information related to this event is shown below: Computer DNS name is “%2” Replica set member name is “%3” Replica set root path is “%4” Replica staging directory path is “%5” Replica working directory path is “%6”
- Description: A positive informational event confirming that the local computer was successfully added as a member of replica set %1. This indicates that FRS is now configured to replicate data for this set.
- Event ID=13554
- Severity=Informational
- The File Replication Service successfully added the connections shown below to the replica set: “%1”
- Description: An informational event indicating that replication connections were successfully established for replica set %1. This suggests FRS has found its partners and communication paths are configured. More details about the specific connections may follow in subsequent events.
- Event ID=13556
- Severity=Error
- The File Replication Service has detected what appears to be an attempt to change the root path for the following replica set: “%1” This is not allowed. To perform this operation, you must remove this member from the replica set and add the member back with the new root path. It is possible that this is a transient error due to Active Directory Domain Services replication delays associated with updating FRS configuration objects. If file replication does not take place after an appropriate waiting time, which could be several hours if cross site Active Directory Domain Services replication is required, you must delete and readd this member to the replica set. Information related to this event is shown below: Computer DNS name is “%2” Replica set member name is “%3” The current Replica set root path is “%4” The desired new Replica set root path is “%5” Replica staging directory path is “%6”
- Description: FRS detected a change in the configured root path for replica set %1 from %4 to %5. FRS does not support changing the root path while a member is active in the replica set. The process for moving the replica root involves specific manual steps.
- Troubleshooting: This error occurs if the root path is changed in AD or the registry without following the correct procedure. If this is a transient AD replication issue, wait for AD replication to converge. If the error persists and the path change was intentional, you must remove the server from the replica set configuration, wait for the change to replicate, and then add the server back with the new root path %5. A full tree sync will occur. There is a deprecated method involving creating a special file (
NTFRS_CMD_FILE_MOVE_ROOT), but removing and re-adding is the standard approach.
- Event ID=13557 / 13558
- Severity=Error
- Descriptions: These events indicate that FRS has detected duplicate connection objects configured between the local computer (%6 or %7) and partner %1 for replica set %2. Duplicate connections prevent replication between these partners. Event 13557 refers to connections found via the Active Directory Sites and Services snap-in path, while Event 13558 refers to connections found via the Active Directory Users and Computers snap-in path (under the System node).
- Troubleshooting: Duplicate connection objects are usually created manually or due to AD replication inconsistencies. They must be manually removed.
- Using AD Sites and Services (for 13557): Open Active Directory Sites and Services. Navigate to the connection object path specified in the event (%3, %4, %5, %6, %7). Within the server object for %6, look under NTDS Settings -> CONNECTIONS. Identify duplicate connections pointing to server %1 within site %8. Delete all but one connection object.
- Using AD Users and Computers (for 13558): Open Active Directory Users and Computers. Enable Advanced Features under the View menu. Navigate to the path %3, %4, %5 (under the System node). Find the FRS member object %6 under the replica set object for %2. Under %6, locate duplicate connections pointing to %1. Delete all but one connection object.
- Context: Allow sufficient time for Active Directory replication after deleting objects before checking FRS health again.
Error State and Recovery (Event ID 13555, 13560)¶
These events indicate that FRS has entered a persistent error state and outline recovery procedures.
- Event ID=13555
- Severity=Error
- The File Replication Service is in an error state. Files will not replicate to or from one or all of the replica sets on this computer until the following recovery steps are performed.
- Description: This event is a general indicator that FRS is stuck in an unhealthy state and cannot perform replication for some or all replica sets. It provides detailed recovery steps based on the role of the server and the replica sets involved.
- Troubleshooting/Recovery Steps:
- Attempt Service Restart: First, try a simple FRS service restart:
net stop ntfrsfollowed bynet start ntfrs. This often clears transient issues. - SYSVOL Recovery (Domain Controllers):
- If other healthy DCs exist in the domain and this DC doesn’t host unique DFS data: Perform a non-authoritative restore of the system state using a backup utility (like
ntbackupor others). This wipes the local SYSVOL copy and forces a full resynchronization from a partner. - If this is the only DC: Perform an authoritative restore of the system state and mark SYSVOL as primary during the restore. This will restore SYSVOL from backup, and other potential (but offline/demoted) DCs would sync from it (if they ever came back online correctly).
- If all DCs have this error: Choose one DC to perform an authoritative restore (it will become the primary source), and perform non-authoritative restores on all other affected DCs.
- If other healthy DCs exist in the domain and this DC doesn’t host unique DFS data: Perform a non-authoritative restore of the system state using a backup utility (like
- DFS/Non-SYSVOL Recovery (Domain Controllers hosting DFS/other sets):
- If DFS alternates/other replica sets on this DC are not replicated elsewhere: Back up the unique data manually from the shared folders.
- Before step (3-c), ensure no connections exist to offline or improperly demoted former DCs using AD Sites and Services.
- Perform a non-authoritative system state restore.
- After SYSVOL is published, copy back the unique data saved in step (3-a).
- Recovery on Other Windows Servers (Non-DCs):
- If any DFS alternates or other replica sets on this server have no other replication partners: Manually back up the unique data from the shared folders or replica root paths.
- Stop FRS:
net stop ntfrs. - Delete the replica set’s root directory content (this forces FRS to perform a full synchronization):
rd /s /q %1(replace %1 with the replica root path). Be extremely cautious with this command; ensure you target the correct directory and understand that this deletes data. - Start FRS:
net start ntfrs. - Wait for initialization (e.g., 5 minutes) and then copy back any unique data saved in step (4-a).
- Attempt Service Restart: First, try a simple FRS service restart:
- Important: If this error is on all members of a replica set, only perform steps (4-b) and (4-c) on one member; the others will sync from it.
- Event ID=13560
- Severity=Warning
- The File Replication Service is deleting this computer from the replica set “%1” as an attempt to recover from the error state, Error status = %2. At the next poll, which will occur in %3 minutes, this computer will be re-added to the replica set. The re-addition will trigger a full tree sync for the replica set.
- Description: This event is part of FRS’s automatic recovery process when it enters an error state (potentially after Event 13555 or JRNL_WRAP_ERROR). FRS attempts to fix the issue by simulating the removal and re-addition of the member to the replica set %1. This process involves deleting the member from the replica set configuration (virtually) and then adding it back, which forces a full synchronization (%3 indicates the polling interval).
- Context: This automatic recovery mechanism is designed to resolve inconsistencies by forcing a fresh synchronization of the replica set content.
Journal Wrap Errors (Event ID 13561, 13568)¶
Journal wrap errors are a common and critical FRS issue occurring when FRS loses track of changes on a volume because the USN journal cycles too quickly or is interrupted.
- Event ID=13561
- Severity=Error
- The File Replication Service has detected that the replica set “%1” is in JRNL_WRAP_ERROR. Replica set name is: “%1” Replica root path is: “%2” Replica root volume is: “%3”
- Description: This critical error indicates that FRS can no longer find a record it needs in the NTFS USN journal on volume %3, which hosts the replica set root path %2 for replica set %1.
- Possible Causes:
- The volume %3 was formatted.
- The USN journal on %3 was deleted.
- The USN journal was truncated (e.g., by
chkdskfinding corruption). - FRS was stopped for a long time, allowing the journal to wrap past the point FRS was tracking.
- Disk I/O activity on %3 was so high that the journal wrapped before FRS could process the changes.
- Automatic Recovery (Default): By default, FRS attempts to recover automatically (similar to Event 13560). It will virtually delete the member from the replica set at the next polling interval (%4 minutes) and then re-add it, triggering a full tree sync.
- Event ID=13568
- Severity=Error
- The File Replication Service has detected that the replica set “%1” is in JRNL_WRAP_ERROR. [Same description and possible causes as 13561] Setting the “Enable Journal Wrap Automatic Restore” registry parameter to 1 will cause the following recovery steps to be taken to automatically recover from this error state. … During the recovery process data in the replica tree may be unavailable. You should reset the registry parameter described above to 0 to prevent automatic recovery from making the data unexpectedly unavailable if this error condition occurs again.
- Description: This event is also a JRNL_WRAP_ERROR but specifically mentions the
Enable Journal Wrap Automatic Restoreregistry key, suggesting it might be referencing a configuration where automatic recovery is enabled or being triggered. It reiterates the possible causes and the recovery steps involving virtual deletion and re-addition, leading to a full sync. - Troubleshooting: The root cause is usually high disk activity combined with a small USN journal size or FRS downtime. Consider increasing the USN journal size using
fsutil usn createjournal(this command creates or resizes; be careful with parameters). Address the underlying cause of high disk I/O if possible. If FRS was stopped, investigate why. - Automatic Restore Setting: The
Enable Journal Wrap Automatic RestoreDWORD value underHKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameterscontrols whether FRS automatically attempts recovery from journal wrap. A value of1enables it (default for SYSVOL in later OS versions), and0disables it. If automatic recovery is causing issues (e.g., frequent unexpected full syncs making data temporarily unavailable), you might set this to0to require manual intervention, allowing you to schedule the recovery.
Staging Path Change and Debug Log Issues (Event ID 13562, 13563, 13564, 13572)¶
These events deal with changes in configuration paths or issues related to FRS logging.
- Event ID=13562
- Severity=Warning
- Following is the summary of warnings and errors encountered by File Replication Service while polling the Domain Controller %1 for FRS replica set configuration information. %2
- Description: This event acts as a summary container, reporting other warnings and errors (%2) that FRS encountered while retrieving configuration information from a domain controller %1. It means FRS couldn’t get up-to-date configuration details cleanly.
- Troubleshooting: The specific issues are listed in the body of the event (%2) or in other accompanying FRS event logs. Troubleshoot the specific warnings/errors reported in the summary. This often relates to Active Directory read access issues, network problems contacting the DC, or issues on the DC itself.
- Event ID=13563
- Severity=Warning
- The File Replication Service has detected that the staging path for the replica set %1 has changed. Current staging path = %2 New staging path = %3 The service will start using the new staging path after it restarts. It is recommended that you manually restart the service to prevent loss of data in the staging directory. To manually restart the service, do the following: 1. Run
net stop ntfrsor use the Services snap-in to stop File Replication Service. 2. Move all the staging files corresponding to replica set %1 to the new staging location. If more than one replica set are sharing the current staging directory, then it is safer to copy the staging files to the new staging directory. 3. Runnet start ntfrsor use the Services snap-in to start File Replication Service. - Description: This warning indicates that the configured staging directory for replica set %1 has been changed from %2 to %3 in the FRS configuration (likely in Active Directory). FRS needs a service restart to begin using the new path. The warning provides explicit instructions on how to handle this change and move existing staged files.
- Troubleshooting: Follow the recommended steps precisely to ensure a smooth transition and avoid data loss in the staging area. Manually stopping the service, moving the files, and then restarting allows FRS to cleanly adopt the new path and process any files already in the staging area.
- Event ID=13564
- Severity=Warning
- The File Replication Service has detected that the volume holding the FRS debug logs is running out of disk space. This will not affect replication unless this volume hosts database, staging, or replica root paths as well. Path to the logs directory = %1
- Description: This warning indicates that the volume hosting the FRS debug log files (%1) is low on disk space. While this doesn’t directly stop replication (unless other critical FRS components are on the same volume), it prevents FRS from writing logs, making troubleshooting difficult.
- Troubleshooting: Free up space on the volume containing %1. You can also configure FRS logging to use less space or move the log directory.
- Configuring Logs: The number and size of log files are controlled by DWORD registry values under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters:Debug Log Files(number of files),Debug Log Severity(level of detail), andDebug Maximum Log Messages(messages per file). The log file path is set by the REG_SZ valueDebug Log Fileat the same location. Changes take effect after the next polling cycle or service restart.
- Event ID=13572
- Severity=Error
- The File Replication Service was unable to create the directory “%1” to store debug log files.
- Description: FRS failed to create the designated directory (%1) for storing its debug logs. This is often a permissions issue or an invalid path.
- Troubleshooting: Verify that the path %1 is valid and that the FRS service account has the necessary permissions to create and write to this directory. Without debug logs, diagnosing other FRS issues becomes significantly harder.
File Locking and Deprecation Events (Event ID 13573, 13574, 13575, 13576)¶
These events cover issues with files being locked by other applications and the important deprecation of FRS for non-SYSVOL replication and even for SYSVOL on newer operating system versions (migrating to DFS Replication).
- Event ID=13573
- Severity=Warning
- File Replication Service has been repeatedly prevented from updating: File Name: “%1” File GUID: “%2” Due to consistent sharing violations encountered on the file. Sharing violations occur when another user or application holds a file open, blocking FRS from updating it. Blockage caused by sharing violations can result in out-of-date replicated content. FRS will continue to retry this update, but will be blocked until the sharing violations are eliminated.
- Description: FRS is unable to replicate updates for file %1 because another process has the file open in a way that prevents FRS from accessing it (a sharing violation). This leads to that specific file becoming inconsistent between replication partners.
- Troubleshooting: Identify which application or user is holding the file %1 open. This can often be done using tools like Resource Monitor or Process Explorer, which can show handles to files. Address the cause of the sharing violation (e.g., close the application accessing the file, adjust application configuration, investigate user activity). FRS will replicate the file once the lock is released and the file is modified again (or potentially after a service restart or manual intervention).
- Event ID=13574
- Severity=Error
- The File Replication Service has detected that this server is not a domain controller. Use of the File Replication Service for replication of non-SYSVOL content sets has been deprecated and therefore, the service has been stopped. The DFS Replication service is recommended for replication of folders, the SYSVOL share on domain controllers and DFS link targets.
- Description: This event indicates that FRS was started on a server that is not a domain controller. FRS is primarily intended for SYSVOL replication on DCs in older Windows versions. Microsoft has deprecated its use for other purposes (like replicating standalone DFS targets) in favor of the newer DFS Replication (DFSR) service. Since the server isn’t a DC, FRS assumes it’s being used for a deprecated purpose and stops itself.
- Troubleshooting: If you need to replicate data on a non-DC, you should use the DFS Replication service instead of FRS. Migrate any FRS replica sets to DFSR. If FRS was running unnecessarily, you can simply disable the service.
- Event ID=13575
- Severity=Error
- This domain controller has migrated to using the DFS Replication service to replicate the SYSVOL share. Use of the File Replication Service for replication of non-SYSVOL content sets has been deprecated and therefore, the service has been stopped. The DFS Replication service is recommended for replication of folders, the SYSVOL share on domain controllers and DFS link targets.
- Description: This event occurs on a domain controller that has successfully migrated its SYSVOL replication from FRS to the newer DFS Replication service (DFSR). Once SYSVOL is replicated by DFSR, FRS is no longer needed for this core function. Like Event 13574, it then checks if FRS is being used for any other (deprecated) non-SYSVOL replica sets. If it finds none, or if those uses are considered deprecated, it stops the FRS service.
- Troubleshooting: This event is generally informational after a successful SYSVOL migration to DFSR. It confirms FRS has stopped because its primary role (SYSVOL) is taken over and its secondary roles (non-SYSVOL) are deprecated. If FRS was still needed for some reason (unlikely in a modern setup), that configuration would need review, but the recommended approach is to use DFSR for all replication tasks.
- Event ID=13576
- Severity=Error
- Replication of the content set “%1” has been blocked because use of the File Replication Service for replication of non-SYSVOL content sets has been deprecated. The DFS Replication service is recommended for replication of folders, the SYSVOL share on domain controllers and DFS link targets.
- Description: This event explicitly states that FRS is blocking replication for a specific non-SYSVOL replica set %1 because FRS is deprecated for this purpose.
- Troubleshooting: This is Microsoft signaling the end-of-life for FRS for non-SYSVOL data. You must migrate the replica set %1 from FRS to the DFS Replication service. DFSR is the modern, recommended technology for replicating file shares, including DFS namespaces and SYSVOL on newer operating systems.
Interpreting these FRS event log errors is a key skill for Windows Server administrators, especially in environments still relying on FRS for SYSVOL replication. While newer systems primarily use DFSR, understanding FRS behavior and troubleshooting its issues remains relevant for maintaining legacy infrastructure or during migration processes.
Have you encountered any particularly challenging FRS event log errors? Share your experiences and troubleshooting tips in the comments below!
Post a Comment