Monitor unlimited number of servers
Filter log events
Create email and web-based reports

Direct access to Microsoft articles
Customized keywords for major search engines
Access to premium content

Event ID: 13508 Source: ntfrs

The File Replication Service is having trouble enabling replication from <server 1 name> to <server 2 name> for c:\winnt\sysvol\domain; retrying.
We had this problem after converting our physical server to a virtual machine on vmware ESXi 4.0 U1  (a P2V process, to be clear).

The first DC complained about the variation of c:\sysvol\domain path. The solution is provided in the error log itself (event id 13599), and i'm summarizing the solution here:

Create a simple empty txt file in c:\sysvol\domain folder (change the path according to your ad configuration, in case you changed it from default).
Rename the file to NTFRS_CMD_FILE_MOVE_ROOT without any extension, just like i wrote it.

After this, restart ntfrs:
net stop ntfrs
net start ntfrs

After a while, the original DC will tell you it successfully restored ntfrs functions.

Restart ntfrs with the above commands on your new DC as well, and check its logs: the replication will occur succesfully!
To fix the problem, you must designate a domain controller to be authoritative for the Sysvol replica set:
1. Stop the File Replication service on the PDC emulator FSMO role holder.
2. Use the Registry Editor to navigate to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Paramaters\Backup/Restore\Process at Startup.

3. Double-click the BurFlags Value Name, a REG_DWORD data type, and set the data value to D4, using the Hex radix.
4. Exit the Registry Editor.
5. Start the File Replication service.

Note: If the BurFlags Value Name is set to D4 (authoritative) on more that one replica, conflicts and collisions will occur.
In my case these changes didn't resolve the problem:
1. Stop FRS.
2. Start Registry Editor (Regedt32.exe).
3. Locate and click the following key in the registry:
4. On the Edit menu, click Add Value, and then add the following registry value:
   Value name: Enable Journal Wrap Automatic Restore
   Data type: REG_DWORD
   Radix: Hexadecimal
   Value data: 1 (Default 0)
5. Quit Registry Editor.
6. Restart FRS.

So i did these too:

1. Stop FRS.
2. Start Registry Editor (Regedt32.exe).
3. Locate and click the following key in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore/Process at Startup
4. On the Edit menu, click Add Value, and then add the following registry value:
   Value name: BurFlags
   Data type: REG_DWORD
   Radix: Hexadecimal
   Value data: D2
5. Quit Registry Editor.
6. Restart FRS.
There could be many reasons for the File Replication Service the experience problems replicating. See ME272279 for general troubleshooting.
One condition that we identified, was a missing SYSVOL share on the domain controller (check with "net share" command). One other reason can be the fact that the computers' time is not synchronized with the domain controller time. See ME285923.

ME326855 indicates that an instance where this error can occur was fixed with Service Pack 2.

* * *

Microsoft has released a tool called Ultrasound that can be used to investigate file replication issues. See EV100099 - "Ultrasound - Monitoring and Troubleshooting Tool for File Replication Service".
I solved this problem by enabling the File Replication Service manually on the primary Domain Controller. After that, the DCs replicated successfully.

I had same issue. To fix the problem, I had to properly synchronize the time and to set the BurFlags to authoritative on the PDC master as described in WITP76743.
In our case, the problem was solved after setting the "nonauthoritative mode restore (D2)" value on the failing domain controller, and the "authoritative mode restore (D4)" value on the working domain controller. It appeared that these domain controllers have never finished initial replication between them since the first one was promoted. See ME290762 for information on using the BurFlags registry key to reinitialize File Replication Service replica sets.
See ME249256 for information on how to troubleshoot Intra-Site replication failures.

See ME555381 for information on how to configure the Windows 2003 SP1 firewall on a Domain Controller. A wrongly configured firewall might be the cause of this event.

ME327341 shows information on how to troubleshoot the File Replication Service in Windows Server 2003.

File Replication Service Diagnostics Tool (FRSDiag.exe) might help you to solve this problem. As per Microsoft: "FRSDiag provides a graphical interface to help troubleshoot and diagnose problems with the File Replication Service (FRS). FRSDiag helps to gather snap-shot information about the service, perform automated tests against that data, and compile an overview of possible problems that may exist in the environment". See the link bellow to download the tool.

From a newsgroup post: "Event 13508 in the FRS log is a warning that the FRS service has been unable to complete the RPC connection to a specific replication partner. It indicates that FRS is having trouble, enabling replication with that partner and will keep trying to establish the connection. A single event ID 13508 does not mean anything is broken or not working; simply look for event ID 13509 to make sure that the problem was resolved. Based on the time between event IDs 13508 and 13509, you can determine if there is a real problem that needs to be addressed.
Note that if FRS is stopped after a 13508 event, and then later started at a time when the communication issue has been resolved, no 13509 will be entered in the event log, and without a 13508 message reappearing, replication connections are being made correctly.
Since FRS servers gather their replication topology information from their closest Active Directory domain controller (itself on a domain controller that is also an FRS member), there is also an expected case where a replica partner in another site will not be aware of the replica set until the topology information has been replicated to domain controllers in that site. When the topology information finally reaches that distant domain controller, the FRS partner in that site will be able to participate in the replica set and lead to FRS event ID 13509. Note that intra-site Active Directory replication partners replicate every 5 minutes. Inter-site replication only replicates when the schedule is open (shortest delay is 15 minutes). In addition, FRS polls the topology in the active directory at defined intervals – 5 minutes on domain controllers, and 1 hour on other member servers of a replica set. These delays and schedules (and especially in topologies with multiple hops) can delay propagation of the FRS replication topology
Procedures for Troubleshooting FRS Event 13508 without Event 13509:
1. Examine the 13508 Event in the FRS Event Log in order to determine which machine that FRS has been unable to communicate with.
2. Determine whether the remote machine is working properly, and verify that FRS is running on it. A good method to do this to execute “NTFRSUTL VERSION <FQDN of remote DC name>” from the machine logging the 13508 event. If this fails, check network connectivity by pinging the <FQDN of remote DC name> from the machine logging the 13508 event. If this fails, then troubleshoot as a DNS or TCP/IP issue. If it succeeds, confirm the FRS service is started on the remote DC.
3. Determine whether FRS has ever been able to communicate with the remote computer by looking for 13509 in the event log and review recent change management to networking, firewalls, DNS configuration, and Active Directory infrastructure to see if there is a correlation.
4. Determine whether there is anything between the two machines that is capable of blocking RPC traffic, such as a firewall or router.
5. Confirm that Active Directory replication is working".

See the links to "Troubleshooting File Replication Service", "Monitoring and Troubleshooting the File Replication Service", "FRS Technical Reference", and "EventID 13508 from source FRS" for more details on fixing this problem.
On a Windows 2003 network, if this event appears a number of times in the FRS log of a DC, it usually means that the clock for the DC is not synchronized with the DC that has the FSMO roles. Synchronize the clock, and the replication should be OK on the next replication cycle.
I have spent the best part of a whole day trying to sort this out. Our firewall system (Checkpoint NG FP3) was blocking a large ICMP packet that one domain controller sent to another in communication. No idea why it sends such a large ICMP packet, but in Checkpoint, you can go into smartdefense for a policy and increase the packet size.
The "Secure Channel" password between the DCs has been broken. I had three domain controllers and the PDC got it's time changed by months. This created pandemonium because the other servers on the network started changing their times and other people on the network could not log in because of the time difference. Here is what you do to fix it:
1. Stop the Key Distribution service on the BDC.
2. Set it to disabled.
3. Open a command prompt and type: "netdom resetpwd /server:<BDC Name> /user:<domain name> \administrator /password:<*****>”.
4. Restart the server
5. A new ticket will be assigned to the server from the PDC emulator. The KDS Service must still be disabled.
6. Set the KDS Service to Auto and start it.
Do this to all of the DCs except the PDC Emulator.
I have seen this error on a newly installed Windows 2003 domain controller with Service Pack 1. It could not replicate with the only other DC, a Windows 2000 SP4 server. I was not able to figure out which blocked ports caused this, but disabling the Windows 2003 firewall solved the problem (look for event 13516).
I had this error in connection with Kerberos authentication errors. After the restore (from backup media) of one DC (holder of all FSMOs), the replication with the second DC would not work anymore. The SYSVOL share was missing on the PDC, but rebuilding it did not solve the problem. I noticed security/access problems in the event log and turned on Kerberos logging. Extended Error: KDC_ERR_S_PRINCIPAL_UNKNOWN ==> second DC was missing in the Kerberos database. After resetting the computer account of the second DC, the replication worked again. See ME260575 for information on resetting the machine account passwords of a Windows 2000 Domain Controller.
We have two DCs in one domain. DC1 showed event ID 13508 and DC2 showed event ID 1265. These problems were caused by missing DNS SRV records on DC1 (DNS server). You could add them manually, but I solved the problem by running “netdiag /fix” on DC2. Running netdiag added the missing records to the DNS automatically.

This problem occurred when applying a new Group Policy to the servers housing the DFS Root Replicas. Restarting the FRS service on all Root Replica servers resolved the issue.
The permission for the folder that was being replicated was removed. Make sure SYSTEM has full permission on the folder. I had to check each DC for the folder location and set SYSTEM permission to full.
The following workaround worked for me. Make the following changes in the registry to instruct FRS to handle the JRNL_WRAP_ERROR status automatically:
1. Stop FRS.
2. Start Registry Editor (Regedt32.exe).
3. Locate and click the following key in the registry:
4. On the Edit menu, click Add Value, and then add the following registry value:
   Value name: Enable Journal Wrap Automatic Restore
   Data type: REG_DWORD
   Radix: Hexadecimal
   Value data: 1 (Default 0)
5. Quit Registry Editor.
6. Restart FRS.
This occurred when an AD database on a DC could not grow because of other files, which were consuming drive space where the database was located. To solve this check the disk drive where your AD database files are located and make sure there is free space available.
Changing from a mixed mode domain to a native mode may fix this problem on SP2 machines.
I have also seen this error repeated times when I have just made a DC a Global Catalog server. It will eventually recover (event ID 13509). Possibly a traffic issue during initial GC replication.
In my case, the error was due to low disk space on the DC.
After this event I got event 13509 stating: “The FRS has enabled replication...after repeated retries”. To resolve this problem I synchronized the computer's clock with the domain controller that is the authoritative time server. For each server that was experiencing this difficulty, I opened a CMD prompt and typed:
   net time \\ComputerName_Of_Authoritative_Time_Server /set /y
   net stop ntfrs
   net start ntfrs
I started and stopped Ntfrs and got the following: The FRS is no longer preventing the computer DC02 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.
Corrupted permissions on the Sysvol share or any of the objects below it can cause this error. The ACL should include full access for Administrators, Creator/Owner and system, read for server operators and authenticated users. The ownership on these folders and files may also become corrupt and have to be reset to Administrators.

Got this error on a Domain DFS which was replicating files between two systems. Server A did not get this error, but Server B did. Upon further investigation, Server B did not have "Authenticated Users" specified in the "Access this computer from the Network" right. Upon correcting this, the error was replaced by a success and replication began to flow. Users - which contains Authenticated Users, should also be sufficent here but wasn't tried.
This can occur if:
1. FRS can not correctly resolve the DNS name for server 2 from server 1.
2. FRS is not running on server 2
3. The topology information in the Active Directory for this replica has not yet replicated to all the Domain Controllers.
This event log message will appear once for each connection. After the problem  is fixed you will see another event log message that indicates that the connection has been established.

Windows Event Log Analysis Splunk App

Build a great reporting interface using Splunk, one of the leaders in the Security Information and Event Management (SIEM) field, linking the collected Windows events to



Cisco ASA Log Analyzer Splunk App

Obtain enhanced visibility into Cisco ASA firewall logs using the free Firegen for Cisco ASA Splunk App. Take advantage of dashboards built to optimize the threat analysis process.