none
The File Replication Service is having trouble enabling replication from SERVER01 to SERVER02 RRS feed

  • Question

  • Hello,

    We are installing moving from Windows 2008 Server to Windows Server 2012 Standard. I did the following:

        Joined 2012 server to the 2008 domain
        Installed Active Directory Domain Services (aka dcpromo) on the server
        Transferred all roles to new server
        Discover that replication was not down

    Ran this command with no errors :
        Get-wmiobject –namespace root\MicrosoftDNS –class “MicrosoftDNS_Zone”
        So I did this :
        Ran the non Authoritative FRS restore procedure using the D2 flag on the new 2012 server
    But i am still having the replication not down and this warning :
    Log Name:      File Replication Service
    Source:        NtFrs
    Date:          9/21/2013 12:13:12 PM
    Event ID:      13508
    Task Category: None
    Level:         Warning
    Keywords:      Classic
    User:          N/A
    Computer:      Server02.domain.local
    Description:
    The File Replication Service is having trouble enabling replication from SERVER01 to SERVER02 for c:\windows\sysvol\domain using the DNS name SERVER01.domain.local. FRS will keep retrying.
     Following are some of the reasons you would see this warning.

     [1] FRS can not correctly resolve the DNS name SERVER01.domain.local from this computer.
     [2] FRS is not running on SERVER01.domain.local.
     [3] The topology information in the Active Directory Domain Services for this replica has not yet replicated to all the Domain Controllers.

    Thank you for your help

           
    Monday, September 23, 2013 11:43 AM

Answers

  • Thank you all for your reply.

    This issue have been solved by following this techinical document : http://support.microsoft.com/kb/315457

    How to rebuild the SYSVOL tree and its content in a domain

    1.    Checked and found that Sysvol and Netlogon are not shared on Server2.
    2.    Ran the below mentioned commands and verified that Active Directory Replication is working fine:

    repadmin /syncall /APedq
    repadmin /syncall /Aedq

    3.    Checked and found below mentioned event id on SERVER1:

    Log Name:      File Replication Service
    Source:        NtFrs
    Date:          21/09/2013 7:49:14 PM
    Event ID:      13568
    Task Category: None
    Level:         Error
    Keywords:      Classic
    User:          N/A
    Computer:      SERVER1.cesoc.local
    Description:
    The File Replication Service has detected that the replica set "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" is in JRNL_WRAP_ERROR.
     
    Replica set name is    : "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"
    Replica root path is   : "c:\windows\sysvol\domain"
    Replica root volume is : "\\.\C:"
    A Replica set hits JRNL_WRAP_ERROR when the record that it is trying to read from the NTFS USN journal is not found.

    4.    Corrected the NIC binding, Provider Order and DNS Pointing on both the DC's.
    5.    Stopped the File Replication Service on both the DC's.
    6.    Browsed to the below mentioned registry location on Server01 and edited the BurFlags to D4
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NtFrs\Parameters\Cumulative Replica Sets\GUID
    7.    Started the File Replication Service on Server01.
    8.    Checked the Event Viewer and verified that we are getting event id 13516.
    9.    Edited the Burflags on Server02 and made it D2.
    10.    Started the File Replication Service.
    11.    After a while we got Event ID 13516.
    12.    Verified that Sysvol & Netlogon got shared on Server02
    13.    Checked the File Replication and found no issues.



    Tuesday, September 24, 2013 1:56 PM

All replies

  • What is primary dns server of the new DC? set it to the original DC as primary, until it's syncing up I assume you installed DNS on the new DC as part of the dcpromo.

    Try to ping between both by name, could also be windows firewall stopping you.

    Monday, September 23, 2013 4:07 PM
  • Hi,

    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.

    To troubleshoot FRS Event 13508 without Event 13509, we may follow the following procedure.

    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.

    Regarding troubleshooting Event ID:13508, the following article may be referred to for information.

    http://technet.microsoft.com/en-us/library/bb727056.aspx#EMAA

    Best regards,

    Frank Shen

    Tuesday, September 24, 2013 10:13 AM
    Moderator
  • Thank you all for your reply.

    This issue have been solved by following this techinical document : http://support.microsoft.com/kb/315457

    How to rebuild the SYSVOL tree and its content in a domain

    1.    Checked and found that Sysvol and Netlogon are not shared on Server2.
    2.    Ran the below mentioned commands and verified that Active Directory Replication is working fine:

    repadmin /syncall /APedq
    repadmin /syncall /Aedq

    3.    Checked and found below mentioned event id on SERVER1:

    Log Name:      File Replication Service
    Source:        NtFrs
    Date:          21/09/2013 7:49:14 PM
    Event ID:      13568
    Task Category: None
    Level:         Error
    Keywords:      Classic
    User:          N/A
    Computer:      SERVER1.cesoc.local
    Description:
    The File Replication Service has detected that the replica set "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" is in JRNL_WRAP_ERROR.
     
    Replica set name is    : "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"
    Replica root path is   : "c:\windows\sysvol\domain"
    Replica root volume is : "\\.\C:"
    A Replica set hits JRNL_WRAP_ERROR when the record that it is trying to read from the NTFS USN journal is not found.

    4.    Corrected the NIC binding, Provider Order and DNS Pointing on both the DC's.
    5.    Stopped the File Replication Service on both the DC's.
    6.    Browsed to the below mentioned registry location on Server01 and edited the BurFlags to D4
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NtFrs\Parameters\Cumulative Replica Sets\GUID
    7.    Started the File Replication Service on Server01.
    8.    Checked the Event Viewer and verified that we are getting event id 13516.
    9.    Edited the Burflags on Server02 and made it D2.
    10.    Started the File Replication Service.
    11.    After a while we got Event ID 13516.
    12.    Verified that Sysvol & Netlogon got shared on Server02
    13.    Checked the File Replication and found no issues.



    Tuesday, September 24, 2013 1:56 PM
  • I had exactly the same problem and this resolved it. Well written, thank you for posting.
    Friday, June 12, 2015 10:06 PM