NTFrs errors (Event IDs: 13508 and 13509)

error 13508

The File Replication Service is having trouble enabling replication from ELAW-DC-SYD-01 to SYDFPEX for c:\winnt\sysvol\domain using the DNS name elaw-dc-syd-01.elaw.net.au. FRS will keep retrying.
 Following are some of the reasons you would see this warning.
 [1] FRS can not correctly resolve the DNS name ServerA.mydomain from this computer.
 [2] FRS is not running on ServerA
 [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 per connection, After the problem is fixed you will see another event log message indicating that the connection has been established.


The File Replication Service has enabled replication from ServerA to ServerB for c:\winnt\sysvol\domain after repeated retries.

Resolution attempts:

[1] I am able to ping ServerA from this coimputer
[2]FRS is running on btoh servers
[3] How can I check this????????

Please help as I am new to Windows 2000.

Who is Participating?
Zaheer IqbalTechnical Assurance & ImplementationCommented:

Event ID: 13508
Source NtFrs  
Type Warning  
Description The File Replication Service is having trouble enabling replication from <server 1 name> to <server 2 name> for c:\winnt\sysvol\domain; retrying.  
Comments Adrian Grigorof
There could be many reasons for the File Replication Service the experience problems replicating. See Q272279 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 Q285923.

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

Ionut Marin (Last update 12/16/2003):
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".

Anonymous (Last update 12/16/2003):
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.

Sipho Ntombela (Last update 10/14/2003):
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.

Anonymous (Last update 9/27/2003):
Changing from a mixed mode domain to a native mode may fix this problem on SP2 machines.

Anonymous (Last update 9/27/2003):
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.

Oded Shafran (Last update 9/27/2003):
In my case, the error was due to low disk space on the DC.

John Orban (Last update 9/27/2003):
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.

CHooper (Last update 5/5/2003):
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.

Brad Turner
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.  
Rob StoneCommented:
I know this is an old question - but I've been troubleshooting the same issue for about 2 weeks now & found the resolution on Microsoft KB Article ID : 822158.


Once I added the recommended DC files & folders in my Norton AV exclusion list - & net stop/start file replication service it worked.
I think Norton was creating a file lock in my sysvol folder causing the replication to fail & go into JRNL_WRAP_ERROR.

Thanks - James
Error 13508 means the DC cannot become a Domain controller. Check if the syslog folder and netlogon folder have been shared by the DC. If they haven't it sounds like some of the ports are closed that enable the DC to replicate ( probably due to a firewall).

Try this link it will tell you what ports need to be open and ways around a firewall.

If there is a ristriction on your network for UDP byte size it will stop Kerberos Authentication from working

Try this link

There is also a link to a utility on this page called Portquery that will allow you to test for the open ports you need.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.