GET-IT: TEAMS DAY | 1-Day Free Virtual Conference all about Teams. Here on Petri.com - 8/12/20 GET-IT: TEAMS DAY - 8/12/20

AD replication error 8614

Viewing 1 post (of 1 total)
  • Author
    Posts
  • Avatar
    Jeffesmi
    Member
    #165494

    Hello,

    [SIZE=14px]I have a two server system that is reporting AD Replication Error 8614: The Active Directory cannot replicate with this server because the time since the last replication with this server has exceeded the tombstone lifetime.” The two servers are:
    – DERMSERVER2 (holds FSMO role, has JRNL WRAP error)
    – RMDEMR (is a DC & GC, runs SQL/IIS application that is critical to organization) *yes, I know a SQL server should not run AD, but that is a problem for later times*

    A technician on technet with some AD savvy has identified that the DERMSERVER2 has a JRNL WRAP error from the logs I posted there. I have corrected the file corruption problem by running CHKDSK /F /R until no more errors were reported. He is recommending that I transfer the fsmo roles to the RMDEMR server and then perform the “Enable Journal Wrap Automatic Restore” registry fix to repair the JRNL WRAP error before trying to fix the tombstone error. I have the following questions about that:[/SIZE]
    [SIZE=14px]If I understand correctly, the JRNL WRAP fix procedure will delete the server from the replica set and then add it back at the next poll.[/SIZE]
    [SIZE=14px]My first question is this, “If these two servers are basically partitioned from each other due to the tombstone error, where will the DERMSERVER2 server sync the information from? Will the process of deleting the server from the replica set and adding it back during the JRNL WRAP procedure fix the tombstone error and allow the partition to be synced from the RMDEMR server?[/SIZE]
    [SIZE=14px]My second question has to do with you saying to transfer the FSMO roles. Since the DERMSERVER2 that holds the FSMO roles has a JRNL WRAP error and a tombstone error, I’m pretty sure I won’t be able to transfer the roles. Rather I would have to seize them. Since the DERMSERVER2 server won’t recognize that these roles have been seized and will continue thinking of it’s self as the FSMO role holder, during the repair process anyway, wouldn’t it be better to leave the FSMO roles on DERMSERVER2, do the repair, and then seize the roles if necessary once the repair is made?

    Lastly, I did a shadow copy as outlined in http://www.squidworks.net/2011/09/ntfrs-journal-wrap-errors-detected-on-domain-controller/ . Is there anything else I should do to safeguard the servers in event of a disaster?

    The technet guy has been helpful and seems to know what he is doing, but I need answers to these questions soon as I hope to perform this function tomorrow while the office is closed in case I need some recovery time. I’d also like a second set of eyes on this as I’d like to fix it on the first try. For reference, the technet forum post I started, detailed logs, etc., are at:

    https://social.technet.microsoft.com/Forums/en-US/e4602290-f0a8-491d-b376-639c7f95a238/procedure-for-troubleshooting-ad-replication-error-8614?forum=winserverDS

    Any help will be greatly appreciated,

    Jeff[/SIZE]

Viewing 1 post (of 1 total)

You must be logged in to reply to this topic.