FILE REPLICATION SERVICE is having trouble. Event ID 13508

Troubleshooting FRS Events 13508 without FRS Event 13509

FRS event ID 13508 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 FRS event ID 13508 does not mean anything is broken or not working, as long as it is followed by FRS event ID 13509, which indicates that the problem was resolved. Based on the time between FRS event IDs 13508 and 13509, you can determine if a real problem needs to be addressed.

Note: If FRS is stopped after an event ID 13508 is logged and then later started at a time when the communication issue has been resolved, event ID 13509 will not appear in the event log. In this case, look for an event indicating that FRS has started, and ensure it is not followed by another event 13508.

Because FRS servers gather replication topology information from the closest domain controller, 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 FRS event ID 13509 will be logged. Intrasite Active Directory replication partners replicate every five minutes. Intersite replication only replicates when the schedule is open (the shortest delay is 15 minutes). In addition, FRS polls the topology at defined intervals: five minutes on domain controllers, and one hour on other member servers of a replica set. These delays and schedules can delay propagation of the FRS replication topology, especially in topologies with multiple hops.
Procedures for Troubleshooting FRS Event 13508 without Event 13509

1.
      

Examine the FRS event ID 13508 to determine the 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. Type the following command at a command prompt on the computer that logged the FRS event ID 13508 and press ENTER:

ntfrsutl version <FQDN of remote domain controller>

If this fails, check network connectivity by using the Ping command to ping the fully qualified domain name (FQDN) of the remote domain controller from the computer that logged the FRS event ID 13508. If this fails, then troubleshoot as a DNS or TCP/IP issue. If it succeeds, confirm that the FRS service is started on the remote domain controller.

3.
      

Determine whether FRS has ever been able to communicate with the remote computer by looking for FRS event ID 13509 in the event log and see if the FRS problem correlates to recent change management to networking, firewalls, DNS configuration, or Active Directory infrastructure.

4.
      

Determine whether anything between the two machines is capable of blocking RPC traffic, such as a firewall or router.

5.
      

Confirm that Active Directory replication is working. For more information about troubleshooting Active Directory replication, see Troubleshooting Active Directory Replication Problems in this guide.

Thanks,

for #2 above, i ran the command and got the followng results.

C:\>ntfrsutl version SERVER0.domain.local
NtFrsApi Version Information
   NtFrsApi Major      : 0
   NtFrsApi Minor      : 0
   NtFrsApi Compiled on: Mar 24 2005 15:06:29
NtFrs Version Information
   NtFrs Major        : 0
   NtFrs Minor        : 0
   NtFrs Compiled on  : Mar 24 2005 15:06:43
   Latest changes:
   Install Override fix
OS Version 5.2 (3790) -
SP (1.0) SM: 0x0110  PT: 0x02
Processor:  INTEL Level: 0x000f  Revision: 0x0401  Processor num/mask: 4/0000000f

Not sure what this tells me??
for Item #3, there is no 13509 event in the event log.

for Item #4, nothing between the machines, they are on the same switch.

for Item #5, that seems to work fine. AD is showing up on the new system etc.

Here is what microsoft said to run and it seems fine:
P:\>repadmin /showreps
Default-First-Site\SERVER0
DC Options: IS_GC
Site Options: (none)
DC object GUID: d1e7199c-0676-4799-8d7d-cb3b3d73af0c
DC invocationID: 47dbf5e5-d089-4c7d-a4b3-c14af3be8c63

==== INBOUND NEIGHBORS ======================================

DC=SERVER,DC=local
    Default-First-Site\SERVER1 via RPC
        DC object GUID: f39a462d-a72b-4e3b-9b28-127296f614f9
        Last attempt @ 2006-02-17 13:28:29 was successful.
    Default-First-Site\YODA via RPC
        DC object GUID: 9916c798-2fe7-45f5-b3c0-66c5f21e0ba5
        Last attempt @ 2006-02-17 13:41:29 was successful.

CN=Configuration,DC=SERVER,DC=local
    Default-First-Site\SERVER1 via RPC
        DC object GUID: f39a462d-a72b-4e3b-9b28-127296f614f9
        Last attempt @ 2006-02-17 13:41:12 was successful.
    Default-First-Site\YODA via RPC
        DC object GUID: 9916c798-2fe7-45f5-b3c0-66c5f21e0ba5
        Last attempt @ 2006-02-17 13:41:15 was successful.

CN=Schema,CN=Configuration,DC=SERVER,DC=local
    Default-First-Site\SERVER1 via RPC
        DC object GUID: f39a462d-a72b-4e3b-9b28-127296f614f9
        Last attempt @ 2006-02-17 12:49:09 was successful.
    Default-First-Site\YODA via RPC
        DC object GUID: 9916c798-2fe7-45f5-b3c0-66c5f21e0ba5
        Last attempt @ 2006-02-17 12:49:09 was successful.

P:\>

let me know what you think.

Thanks

Well, I finally had to all Microsoft and after 6 hours on the phone we figured it out. We Ran several different utilities (described above) as well as a couple we downloaded from Microsoft (GPMC.MSI, FRSDIAG.MSI) and we also used the built in ADSIEDIT.MSC to find some errors in the site. In the end the tech made a D2 tweak to the new backup server telling it to pull replication from the Primary DC and a D4 registry tweak on the DC telling it that it holds all of the master records to replicate out. Restarted FRS service on both systems then watched the events logs. It finally created the Netlogon share as well as the Syslogon. Not sure if this will every help anyone, but I wanted to share its all done and working fine. The bottom line...pay the $245 to Microsoft if you get this error and they will fix it! :-)

gents quite simply try the D2 flag first, if that doesnt work try the D4 on both DC's concerend.

steps for D2/D4 are
stop file replication service
hklm\system\currentcontrolset\services\ntfrs\paramters\backup/restore\proceess at startup
dword key
change from 0 to d2 or d4
start ntfrs
 keep an eye on ntfrs events you should see it saying all ok

malboteju, thanks for posting the steps!  Just a couple of typo corrections/additions:

D2 - non-authoritative restore (pull from another DC)
D4 - authoritative restore

Steps for setting D2/D4 are:
*  stop file replication service (net stop ntfrs)
*  Use RegEdit to edit "BurFlags" in the key "hklm\system\currentcontrolset\services\ntfrs\parameters\Backup/Restore\Process at Startup"
*  edit the dword key "BurFlags" in Hex format.
*  change from 0 to D2 or D4
*  start the file replication service (net start ntfrs)

Keep an eye on ntfrs events you should see it saying all OK.

 
Rob "I"
IT Tech Lead

This post was very helpful to me.  Thanks for the follow up and good instructions.  This worked for me!

I do have one question.  should the registry changes made be left, or should the values be returned to 0 after replication is working properly?

I see... It automatically gets set back to 0.  Very nice!

Setting the key to D2 also worked for me. I was having this problem after adding a windows 2003 R2 server to a domain controlled by a windows 2008 server. Thanks!

Worked great! I had raised the topology from native to 2003 and it stopped replicating this brought it back online

This registry fix worked out great for me also after I got a "The File Replication Service has detected that the replica set "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" is in JRNL_WRAP_ERROR." on one of our DC's.
Thanks

This solution its fantastic. I have this issue since month ago but now its ok thanks gays. I like experts Exchange .

Thanks:)