При репликации возникла ошибка 8614

title	description	ms.date	author	ms.author	manager	audience	ms.topic	ms.prod	localization_priority	ms.reviewer	ms.custom	ms.technology
Troubleshoot replication error 8614	Fixes Active Directory replication error 8614.	04/28/2023	Deland-Han	delhan	dcscontentpm	itpro	troubleshooting	windows-server	medium	kaushika	sap:active-directory-replication, csstroubleshoot	windows-server-active-directory

Troubleshoot Active Directory replication error 8614

This article provides the steps to troubleshoot Active Directory replication error 8614.

Applies to:   Windows Server 2012 R2
Original KB number:   2020053

[!NOTE]
Home users: This article is only intended for technical support agents and IT professionals. If you’re looking for help with a problem, please ask the Microsoft Community.

Symptoms

1. DCDIAG reports that Active Directory Replications test failed with error status code 8614: Active Directory can’t replicate with this server because the time since the last replication with this server has exceeded the tombstone lifetime.

   Testing server: <site name><destination dc name>  
   Starting test: Replications  
   * Replications Check  
   [Replications Check,<destination DC name] A recent replication attempt failed:  
   From <source DC> to <destination DC>  
   Naming Context: <directory partition DN path>  
    The replication generated an error (8614):
    Active Directory cannot replicate with this server because the time since the last replication with this server has exceeded the tombstone lifetime.  
   The failure occurred at <date> <time>.  
   The last success occurred at <date> <time>.  
   3 failures have occurred since the last success.  
   

2. REPADMIN.EXE reports that the last replication attempt failed with status 8614. REPADMIN commands that commonly cite the 8614 status include but aren’t limited to:

   • REPADMIN /REPLSUM
   • REPADMIN /SHOWREPL
   • REPADMIN /SHOWREPS
   • REPADMIN /SYNCALL

   Sample output from REPADMIN /SHOWREPS depicting inbound replication from CONTOSO-DC2 to CONTOSO-DC1 failing with the replication access was denied error is shown below:

    efault-First-Site-NameCONTOSO-DC1  
    DSA Options: IS_GC  
    Site Options: (none)  
    DSA object GUID:  
    DSA invocationID:  
   
   ==== INBOUND NEIGHBORS ======================================  
   
   DC=contoso,DC=com  
   Default-First-Site-NameCONTOSO-DC2 via RPC  
   DSA object GUID:  
   Last attempt @ <date> <time> failed, result 8614(0x21a6):
   The Active Directory cannot replicate with this server because the time since the last replication with this server has exceeded the tombstone lifetime.  
   <#> consecutive failure(s).  
   Last success @ <date> <time>.  
   

3. NTDS KCC, NTDS General, or Microsoft-Windows-ActiveDirectory_DomainService events with the five statuses are logged in the Directory Service event log.

   Active Directory events that commonly cite the 8524 status include but aren’t limited to:

   Event source	ID	Event string
   NTDS KCC	1925	The attempt to establish a replication link for the following writable directory partition failed.

4. NTDS Replication Event 2042 may be logged in the Directory Service event log:

   Event Type: Error
   Event Source: NTDS Replication
   Event Category: Replication
   Event ID: 2042
   User: NT AUTHORITYANONYMOUS LOGON
   Computer: <name of DC that logged event>
   
   Description:  
   It has been too long since this machine last replicated with the named source
   machine. The time between replications with this source has exceeded the tombstone
   lifetime. Replication has been stopped with this source.
   
   The reason that replication is not allowed to continue is that the two machine's views of deleted objects may now be different. The source machine may still have copies of objects that have been deleted (and garbage collected) on this machine. If they were allowed to replicate, the source machine might return objects which have already been deleted.
   
   Time of last successful replication: YYYY-MM-DD HH:MM:SS
   Invocation ID of source: <32 character GUID for source DC>
   Name of source: <fully qualified cname record of source DC>
   Tombstone lifetime (days): <current TSL value. Default = 60 or 180 days>
   
   The replication operation has failed.
   
   User Action:
   
   Determine which of the two machines was disconnected from the forest and is now out of date. You have three options:
   
   1. Demote or reinstall the machine(s) that were disconnected.
   2. Use the repadmin /removelingeringobjects tool to remove inconsistent deleted objects and then resume replication.
   3. Resume replication. Inconsistent deleted objects may be introduced. You can continue replication by using the following registry key. Once the systems replicate once, it's recommended that you remove the key to reinstate the protection.  
   

5. The replicate now command in Active Directory Sites and Services returns the following message:

   Active Directory cannot replicate with this server because the time since the last replication with this server has exceeded the tombstone lifetime.

   Right-clicking on the connection object from a source DC and choosing replicate now in Active Directory Sites and Services (DSSITE.MSC) is unsuccessful. You receive the following message:

   Active Directory cannot replicate with this server because the time since the last replication with this server has exceeded the tombstone lifetime.

   The on-screen error message text is as follows:

   Dialog title text: Replicate Now
   Dialog message text: The following error occurred during the attempt to synchronize naming context <%directory partition name%> from Domain Controller <Source DC> to Domain Controller <Destination DC>:

   The Active Directory cannot replicate with this server because the time since the last replication with this server has exceeded the tombstone lifetime.
   The operation will not continue

   Buttons in the dialog: OK

Cause

Active Directory domain controllers support multi-master replication. Any domain controller that holds a writable partition can originate a create, modify, or delete of an object or attribute (value). Knowledge of object/attribute deletion persists for tombstone lifetime number of days. (See Information about lingering objects in a Windows Server Active Directory forest.

Active Directory requires end-to-end replication from all partition holders to transitively replicate all originating deletes for directory partitions to all partition holders. Failure to inbound-replicate a directory partition in a rolling TSL number of days results in lingering objects. A lingering object is an object that has been intentionally deleted by at least one DC, but incorrectly exists on destination DCs which failed to inbound-replicate the transient knowledge of all unique deletions.

Error 8614 is an example of logic added in domain controllers that are running Windows Server 2003 or a later version. It quarantines the spread of lingering objects and identifies long-term replication failures that cause inconsistent directory partitions.

Root causes for error 8614 and NTDS Replication Event 2042 include:

1. The destination DC that logs the 8614 error failed to inbound-replicate a directory partition from one or more source DCs for tombstone lifetime number of days.

2. System time on the destination DC moved, or jumped, tombstone lifetime one or more numbers of days in the future since the last successful replication. It gives the appearance to the replication engine that the destination DC failed to inbound-replicate a directory partition for tombstone lifetime elapsed number of days.

   Time jumps can occur when the following conditions are true:

   • A destination DC successfully inbound-replicates, adopts bad system time TSL or more number of days in the future.
   • The destination DC then tries to inbound-replicate from a source that was last replicated from TSL or more number of days in the past.

   Or

   Time jumps from current time to a date/time tombstone lifetime or more days in the past, successfully inbound-replicates. Then it tries to inbound-replicate after it adopts time TSL or more number of days in the future.

Basically, the cause and resolution for replication error 8614 apply equally to the cause and resolution for NTDS replication event 2042.

Resolution

[!NOTE]
There are two action plans to recover Active Directory domain controllers that log error status 8614 or NTDS Replication event 2042. You can either force-demote the domain controller, or use the action plan below that says, Check for required fixes, look for time jumps, check for lingering objects, and remove them if present, remove any replication quarantines, resolve replication failures, then put the DC back into service. Force-demoting such DCs may be easier and faster, but can result in the loss of originating updates (that is, data loss) on the domain controller that’s being force-demoted. Active Directory recovers gracefully from this condition by following the steps below. Select the best solution for your scenario. Don’t assume that a force demotion is the only workable solution, especially when replication failure is easy to resolve or is external to Active Directory.

1. Check for nondefault values of tombstone lifetime.

   By default, tombstone lifetime uses either 60 or 180 days, depending on the version of Windows deployed in your forest. Microsoft Support regularly sees DCs that have failed inbound replication for those periods of time. It’s also possible that the tombstone lifetime has been configured to a short period, such as two days. If so, DCs that didn’t inbound-replicate for, say, five days will fail the following test:

   All DCs must replicate with a rolling TSL number of days

   Use repadmin /showattr to see whether a nondefault value for the TombstoneLifetime attribute has been configured.

   repadmin /showattr "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<forest root domain>,DC=<top level domain>"

   If the attribute isn’t present in the showattr output, an internal default value is being used.

2. Check for DCs that failed inbound replication for TSL number of days.

   Run repadmin /showrepl * /csv parsed by using Excel as specified in the Verify successful replication to a domain controller section. Sort the replsum output in Excel on the last replication success column in the order from least current to the most current date and time.

3. Check for Windows Server 2003 RTM domain controllers.

   If the 8614 error occurred on a Windows Server 2003 RTM domain controller, install the latest Windows Server 2003 service pack.

4. Check for time jumps.

   To determine whether a time jump occurred, check event and diagnostic logs (repadmin /showreps, dcdiag logs) on destination DCs that are logging 8614 errors for the following timestamps:

   • Date stamps that predate the release of an operating system. For example, date stamps from Windows Server 2003 for an OS released in Windows Server 2008.
   • Date stamps that predate the installation of the operating system in your forest.
   • Date stamps in the future.
   • No events being logged in a given date range.

   Microsoft Support teams have seen system time on production domain controllers incorrectly jump hours, days, weeks, years, and even tens of years in the past and future.

   If system time was found to be inaccurate, correct it. Then try to determine why time jumped, and what can be done to prevent inaccurate time going forward vs. just correcting the bad time. Possible areas to investigate include:

   • Was the forest root PDC configured by using an external time source?
   • Are reference time sources online, available on the network, and resolvable in DNS?
   • Was the Microsoft or third-party time service running and in an error-free state?
   • Are DC-role computers configured to use NT5DS hierarchy to source time?
   • Was the time rollback protection described in How to configure the Windows Time service against a large time offset in place?
   • Do system clocks have good batteries and accurate time in the BIOS?
   • Are virtual host and guest computers configured to source time according to the hosting manufacturers recommendations?

   This article How to configure the Windows Time service against a large time offset documents steps to help protect domain controllers from listening to invalid time samples. More information on MaxPosPhaseCorrection and MaxNegPhaseCorrection is available in Windows Time Service.

5. Check for and remove lingering objects if they’re present.

   The point of the 8614 error replication quarantine is to check for lingering objects and remove them, if present, in each locally held partition before setting Allow Replication with divergent and corrupt partner to 1 in the registry of the destination DC, even if you think that all destination DCs in the forest are running in strict replication consistency.

   Removing lingering objects is beyond the scope of this article. For more information, see the following articles:

   • Information about lingering objects in a Windows Server Active Directory forest.

   • Event ID 1388 or 1988: A lingering object is detected

   Repadmin syntax is shown here:

   Syntax	Online help (Windows Server 2008 and later)
   c:>repadmin /removelingeringobjects <Dest_DSA_LIST> <Source DSA GUID> <NC> [/advisory_mode]	c:>repadmin /help:removelingeringobject

6. Evaluate setting strict replication on destination DCs.

   Strict mode replication prevents lingering objects from being reanimated on destination DCs that have used garbage collection to create, delete, and reclaim intentionally deleted objects.

   The registry key for strict replication:

   • Path: HKEY_LOCAL_MACHINEsystemccsservicesntdsparameters
   • Setting: Strict Replication Consistency <- not case sensitive>
   • Type: reg_dword
   • Value: 0 | 1

   Repadmin syntax for enabling and disabling strict replication on a single or multiple DCs is as follows:

   Syntax	Online help (Windows Server 2008 and later)	Enable on a single DC	Enable on all DCs in forest	Enable on all GCs in forest
   `repadmin /regkey <DSA_LIST> <{+	-}key> [value [/reg_sz]`]	Repadmin /help:regkey	repadmin /regkey <fully qualified computer name> +strict	repadmin /regkey * +strict

7. Set Allow replication with divergent and corrupt partner to 1 on the 8614 DC.

   After any lingering objects are removed, disable the time-based replication quarantine:

   Registry method：

   • Registry path: HKEY_LOCAL_MACHINEsystemccsservicesntdsparameters
   • Registry setting: Allow replication with divergent and corrupt partner <- Not case sensitive》
   • Registry value: 0 = disallow, 1 = allow

   Repadmin method：

   Syntax	Online help (Windows Server 2008 and later)	Enable on a single DC	Enable on all DCs in forest	Enable on all GCs in forest
   `repadmin /regkey <DSA_LIST> <{+	-}key> [value [/reg_sz]`]	Repadmin /help:regkey	repadmin /regkey dc01.contoso.com +allowDivergent	repadmin /regkey * +allowDivergent

8. Resolve AD replication failures if they’re present.

   When the 8614 error status is logged on a destination DC, prior replication errors that were logged in the previous TSL number of days are masked.

   The fact that the 8614 error was reported by the destination DC doesn’t mean that the replication fault resides on the destination DC. Instead, the source of the replication failure could lie with the network or DNS name resolution. Or, there could be a problem with one of the following items:

   • authentication
   • jet database
   • topology
   • the replication engine on either the source DC or the destination DC

   Review past Directory Service events and diagnostic output (dcdiag, repadmin logs) that was generated by the source DC, by the destination DC, and by alternative replication partners in the past to identify the scope and failure status that is preventing replication between the destination DC and the source DC.

9. Delete Allow replication with divergent and corrupt partner or set Allow replication with divergent and corrupt partner to 0 in the registry.

10. Monitor Active Directory replication daily going forward.

    Monitor end-to-end replication in your Active Directory forest daily by using an Active Directory monitoring application. One inexpensive but effective option is to run repadmin /showrepl * /csv and then parse the results in Excel. For more information, see Method 2: Monitor replication by using a command line.

    Identify DCs that are approaching replication failures for 50 percent and for 90 percent of tombstone lifetime. Put them on a watch list. At 50 percent of TSL, make a strong push to resolve replication errors. At 90 percent, consider demoting DCs that cause replication errors forcibly if it’s necessary. To do so, use the dcpromo /forceremoval command.

    Again, replication errors that are logged on a destination DC may be caused by a problem on:

    • The source DC
    • The destination DC
    • The underlying network

    Therefore, try to determine the cause and where the fault is before you take preventive action.

Data collection

If you need assistance from Microsoft support, we recommend you collect the information by following the steps mentioned in Gather information by using TSSv2 for Active Directory replication issues.

References

Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042)

Hi,

I have check the DCDIAG log file and it looks like you have JRNL_WRAP_ERROR on you DC DERMSERVER2. Please run the check disk in read only mode on C: drive first. There may be disk corruption. You have to fixed that first. Please run the CHKDSK /F /R command
to fix the disk corruption error. If that fixed you might be able to resolved the issue. Else follow the link :

http://www.squidworks.net/2011/09/ntfrs-journal-wrap-errors-detected-on-domain-controller/

  An Error Event occurred.  EventID: 0xC0003500

            Time Generated: 06/30/2015   22:44:07

            Event String:

            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:windowssysvoldomain»

             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.  This can occur because of one of the following reasons.

             [1] Volume «\.C:» has been formatted.

             [2] The NTFS USN journal on volume «\.C:» has been deleted.

             [3] The NTFS USN journal on volume «\.C:» has been truncated. Chkdsk can truncate the journal if it
finds corrupt entries at the end of the journal.

             [4] File Replication Service was not running on this computer for a long time.

             [5] File Replication Service could not keep up with the rate of Disk IO activity on «\.C:».

             Setting the «Enable Journal Wrap Automatic Restore» registry parameter to 1 will cause the following recovery steps to be taken to automatically recover from this
error state.

             [1] At the first poll, which will occur in 5 minutes, this computer will be deleted from the replica set. If you do not want to wait 5 minutes, then run «net stop ntfrs»
followed by «net start ntfrs» to restart the File Replication Service.

             [2] At the poll following the deletion this computer will be re-added to the replica set. The re-addition will trigger a full tree sync for the replica set.

            WARNING: During the recovery process data in the replica tree may be unavailable. You should reset the registry parameter described above to 0 to prevent automatic recovery from making
the data unexpectedly unavailable if this error condition occurs again.

• Marked as answer by

  Friday, July 3, 2015 10:46 PM

Troubleshoot Active Directory replication error 8614

This article provides the steps to troubleshoot Active Directory replication error 8614.

Applies to: В Windows Server 2012 R2
Original KB number: В 2020053

Home users: This article is only intended for technical support agents and IT professionals. If you’re looking for help with a problem, please ask the Microsoft Community.

Symptoms

DCDIAG reports that Active Directory Replications test failed with error status code 8614: Active Directory can’t replicate with this server because the time since the last replication with this server has exceeded the tombstone lifetime.

REPADMIN.EXE reports that the last replication attempt failed with status 8614. REPADMIN commands that commonly cite the 8614 status include but aren’t limited to:

• REPADMIN /REPLSUM
• REPADMIN /SHOWREPL
• REPADMIN /SHOWREPS
• REPADMIN /SYNCALL

Sample output from REPADMIN /SHOWREPS depicting inbound replication from CONTOSO-DC2 to CONTOSO-DC1 failing with the replication access was denied error is shown below:

NTDS KCC, NTDS General, or Microsoft-Windows-ActiveDirectory_DomainService events with the five statuses are logged in the Directory Service event log.

Active Directory events that commonly cite the 8524 status include but aren’t limited to:

Event source	ID	Event string
NTDS KCC	1925	The attempt to establish a replication link for the following writable directory partition failed.

NTDS Replication Event 2042 may be logged in the Directory Service event log:

The replicate now command in Active Directory Sites and Services returns the following message:

Active Directory cannot replicate with this server because the time since the last replication with this server has exceeded the tombstone lifetime.

Right-clicking on the connection object from a source DC and choosing replicate now in Active Directory Sites and Services (DSSITE.MSC) is unsuccessful. You receive the following message:

Active Directory cannot replicate with this server because the time since the last replication with this server has exceeded the tombstone lifetime.

The on-screen error message text is as follows:

Dialog title text: Replicate Now
Dialog message text: The following error occurred during the attempt to synchronize naming context from Domain Controller to Domain Controller :

The Active Directory cannot replicate with this server because the time since the last replication with this server has exceeded the tombstone lifetime.
The operation will not continue

Buttons in the dialog: OK

Cause

Active Directory domain controllers support multi-master replication. Any domain controller that holds a writable partition can originate a create, modify, or delete of an object or attribute (value). Knowledge of object/attribute deletion persists for tombstone lifetime number of days. (See Information about lingering objects in a Windows Server Active Directory forest.

Active Directory requires end-to-end replication from all partition holders to transitively replicate all originating deletes for directory partitions to all partition holders. Failure to inbound-replicate a directory partition in a rolling TSL number of days results in lingering objects. A lingering object is an object that has been intentionally deleted by at least one DC, but incorrectly exists on destination DCs which failed to inbound-replicate the transient knowledge of all unique deletions.

Error 8614 is an example of logic added in domain controllers that are running Windows Server 2003 or a later version. It quarantines the spread of lingering objects and identifies long-term replication failures that cause inconsistent directory partitions.

Root causes for error 8614 and NTDS Replication Event 2042 include:

The destination DC that logs the 8614 error failed to inbound-replicate a directory partition from one or more source DCs for tombstone lifetime number of days.

System time on the destination DC moved, or jumped, tombstone lifetime one or more numbers of days in the future since the last successful replication. It gives the appearance to the replication engine that the destination DC failed to inbound-replicate a directory partition for tombstone lifetime elapsed number of days.

Time jumps can occur when the following conditions are true:

• A destination DC successfully inbound-replicates, adopts bad system time TSL or more number of days in the future.
• The destination DC then tries to inbound-replicate from a source that was last replicated from TSL or more number of days in the past.

Time jumps from current time to a date/time tombstone lifetime or more days in the past, successfully inbound-replicates. Then it tries to inbound-replicate after it adopts time TSL or more number of days in the future.

Basically, the cause and resolution for replication error 8614 apply equally to the cause and resolution for NTDS replication event 2042.

Resolution

There are two action plans to recover Active Directory domain controllers that log error status 8614 or NTDS Replication event 2042. You can either force-demote the domain controller, or use the action plan below that says, Check for required fixes, look for time jumps, check for lingering objects, and remove them if present, remove any replication quarantines, resolve replication failures, then put the DC back into service. Force-demoting such DCs may be easier and faster, but can result in the loss of originating updates (that is, data loss) on the domain controller that’s being force-demoted. Active Directory recovers gracefully from this condition by following the steps below. Select the best solution for your scenario. Don’t assume that a force demotion is the only workable solution, especially when replication failure is easy to resolve or is external to Active Directory.

Check for nondefault values of tombstone lifetime.

By default, tombstone lifetime uses either 60 or 180 days, depending on the version of Windows deployed in your forest. Microsoft Support regularly sees DCs that have failed inbound replication for those periods of time. It’s also possible that the tombstone lifetime has been configured to a short period, such as two days. If so, DCs that didn’t inbound-replicate for, say, five days will fail the following test:

All DCs must replicate with a rolling TSL number of days

Use repadmin /showattr to see whether a nondefault value for the TombstoneLifetime attribute has been configured.

If the attribute isn’t present in the showattr output, an internal default value is being used.

Check for DCs that failed inbound replication for TSL number of days.

Run repadmin /showrepl * /csv parsed by using Excel as specified in the Verify successful replication to a domain controller section. Sort the replsum output in Excel on the last replication success column in the order from least current to the most current date and time.

Check for Windows Server 2003 RTM domain controllers.

If the 8614 error occurred on a Windows Server 2003 RTM domain controller, install the latest Windows Server 2003 service pack.

Check for time jumps.

To determine whether a time jump occurred, check event and diagnostic logs ( repadmin /showreps , dcdiag logs) on destination DCs that are logging 8614 errors for the following timestamps:

• Date stamps that predate the release of an operating system. For example, date stamps from Windows Server 2003 for an OS released in Windows Server 2008.
• Date stamps that predate the installation of the operating system in your forest.
• Date stamps in the future.
• No events being logged in a given date range.

Microsoft Support teams have seen system time on production domain controllers incorrectly jump hours, days, weeks, years, and even tens of years in the past and future.

If system time was found to be inaccurate, correct it. Then try to determine why time jumped, and what can be done to prevent inaccurate time going forward vs. just correcting the bad time. Possible areas to investigate include:

• Was the forest root PDC configured by using an external time source?
• Are reference time sources online, available on the network, and resolvable in DNS?
• Was the Microsoft or third-party time service running and in an error-free state?
• Are DC-role computers configured to use NT5DS hierarchy to source time?
• Was the time rollback protection described in How to configure the Windows Time service against a large time offset in place?
• Do system clocks have good batteries and accurate time in the BIOS?
• Are virtual host and guest computers configured to source time according to the hosting manufacturers recommendations?

This article How to configure the Windows Time service against a large time offset documents steps to help protect domain controllers from listening to invalid time samples. More information on MaxPosPhaseCorrection and MaxNegPhaseCorrection is available in Windows Time Service.

Check for and remove lingering objects if they’re present.

The point of the 8614 error replication quarantine is to check for lingering objects and remove them, if present, in each locally held partition before setting Allow Replication with divergent and corrupt partner to 1 in the registry of the destination DC, even if you think that all destination DCs in the forest are running in strict replication consistency.

Removing lingering objects is beyond the scope of this article. For more information, see the following articles:

Repadmin syntax is shown here:

Syntax	Online help (Windows Server 2008 and later)
c:>repadmin /removelingeringobjects [/advisory_mode]	c:>repadmin /help:removelingeringobject

Evaluate setting strict replication on destination DCs.

Strict mode replication prevents lingering objects from being reanimated on destination DCs that have used garbage collection to create, delete, and reclaim intentionally deleted objects.

The registry key for strict replication:

• Path: HKEY_LOCAL_MACHINEsystemccsservicesntdsparameters
• Setting: Strict Replication Consistency
• Type: reg_dword
• Value: 0 | 1

Repadmin syntax for enabling and disabling strict replication on a single or multiple DCs is as follows:

Syntax	Online help (Windows Server 2008 and later)	Enable on a single DC	Enable on all DCs in forest	Enable on all GCs in forest
repadmin /regkey [value [/reg_sz] ]	Repadmin /help:regkey	repadmin /regkey +strict	repadmin /regkey * +strict	repadmin /regkey gc: +strict

Set Allow replication with divergent and corrupt partner to 1 on the 8614 DC.

After any lingering objects are removed, disable the time-based replication quarantine:

Registry methodпјљ

• Registry path: HKEY_LOCAL_MACHINEsystemccsservicesntdsparameters
• Registry setting: Allow replication with divergent and corrupt partner Repadmin methodпјљ

Syntax	Online help (Windows Server 2008 and later)	Enable on a single DC	Enable on all DCs in forest	Enable on all GCs in forest
repadmin /regkey [value [/reg_sz] ]	Repadmin /help:regkey	repadmin /regkey dc01.contoso.com +allowDivergent	repadmin /regkey * +allowDivergent	repadmin /regkey GC: +allowDivergent

Resolve AD replication failures if they’re present.

When the 8614 error status is logged on a destination DC, prior replication errors that were logged in the previous TSL number of days are masked.

The fact that the 8614 error was reported by the destination DC doesn’t mean that the replication fault resides on the destination DC. Instead, the source of the replication failure could lie with the network or DNS name resolution. Or, there could be a problem with one of the following items:

• authentication
• jet database
• topology
• the replication engine on either the source DC or the destination DC

Review past Directory Service events and diagnostic output (dcdiag, repadmin logs) that was generated by the source DC, by the destination DC, and by alternative replication partners in the past to identify the scope and failure status that is preventing replication between the destination DC and the source DC.

Delete Allow replication with divergent and corrupt partner or set Allow replication with divergent and corrupt partner to 0 in the registry.

Monitor Active Directory replication daily going forward.

Monitor end-to-end replication in your Active Directory forest daily by using an Active Directory monitoring application. One inexpensive but effective option is to run repadmin /showrepl * /csv and then parse the results in Excel. For more information, see Method 2: Monitor replication by using a command line.

Identify DCs that are approaching replication failures for 50 percent and for 90 percent of tombstone lifetime. Put them on a watch list. At 50 percent of TSL, make a strong push to resolve replication errors. At 90 percent, consider demoting DCs that cause replication errors forcibly if it’s necessary. To do so, use the dcpromo /forceremoval command.

Again, replication errors that are logged on a destination DC may be caused by a problem on:

• The source DC
• The destination DC
• The underlying network

Therefore, try to determine the cause and where the fault is before you take preventive action.

Источник

Первичный (главный) контроллер домена — G002
Вторичный (подчиненный) контроллер домена — G004
ОС Windows 2008 R2 x64 Rus на обоих

Суть проблемы.
По ошибки и не знанию перевел дату на G004 с 2013 года на 2011 и через 5 мин вернул обратно.
После этого на следующее утро обнаружил ошибки репликации в логах на G002, при этом на подчиненном G004 все нормально.

Диагностика сервера каталогов

Выполнение начальной настройки:
Выполняется попытка поиска основного сервера.
Основной сервер = G002
* Идентифицирован лес AD.
Сбор начальных данных завершен.

Выполнение обязательных начальных проверок

Сервер проверки: Default-First-Site-NameG002
Запуск проверки: Connectivity
. G002 — пройдена проверка Connectivity

Выполнение основных проверок

Сервер проверки: Default-First-Site-NameG002
Запуск проверки: Advertising
. G002 — пройдена проверка Advertising
Запуск проверки: FrsEvent
. G002 — пройдена проверка FrsEvent
Запуск проверки: DFSREvent
За последние 24 часа после предоставления SYSVOL в общий доступ
зафиксированы предупреждения или сообщения об ошибках. Сбои при
репликации SYSVOL могут стать причиной проблем групповой политики.
. G002 — не пройдена проверка DFSREvent
Запуск проверки: SysVolCheck
. G002 — пройдена проверка SysVolCheck
Запуск проверки: KccEvent
Возникло предупреждение. Код события (EventID): 0x8000082C
Время создания: 04/11/2013 16:37:48
Строка события:
Возникла ошибка. Код события (EventID): 0xC00007FA
Время создания: 04/11/2013 16:39:24
Строка события:
С момента последней репликации этой машины с указанной исходной маши
ной прошло слишком много времени. Промежуток между репликациями с этим источнико
м превысил время жизни захоронения. Репликация с данного источника прекращена.
. G002 — не пройдена проверка KccEvent
Запуск проверки: KnowsOfRoleHolders
. G002 — пройдена проверка KnowsOfRoleHolders
Запуск проверки: MachineAccount
. G002 — пройдена проверка MachineAccount
Запуск проверки: NCSecDesc
. G002 — пройдена проверка NCSecDesc
Запуск проверки: NetLogons
. G002 — пройдена проверка NetLogons
Запуск проверки: ObjectsReplicated
. G002 — пройдена проверка ObjectsReplicated
Запуск проверки: Replications
[Replications Check,G002] Сбой при последней попытке репликации:
Из G004 в G002
Контекст именования: DC=zarya,DC=local
При репликации возникла ошибка (8614):
Репликация службы каталогов с этим сервером невозможна, поскольку вр
емя с момента последней репликации с этим сервером превышает время жизни захорон
ения.

Сбой возник в 2013-04-11 16:41:37.
Последняя успешная операция была в 2013-04-10 13:46:31. После
последней успешной операции было
1141 сбоев.
. G002 — не пройдена проверка Replications
Запуск проверки: RidManager
. G002 — пройдена проверка RidManager
Запуск проверки: Services
. G002 — пройдена проверка Services
Запуск проверки: SystemLog
. G002 — пройдена проверка SystemLog
Запуск проверки: VerifyReferences
. G002 — пройдена проверка VerifyReferences

Выполнение проверок разделов на: ForestDnsZones
Запуск проверки: CheckSDRefDom
. ForestDnsZones — пройдена проверка
CheckSDRefDom
Запуск проверки: CrossRefValidation
. ForestDnsZones — пройдена проверка
CrossRefValidation

Выполнение проверок разделов на: DomainDnsZones
Запуск проверки: CheckSDRefDom
. DomainDnsZones — пройдена проверка
CheckSDRefDom
Запуск проверки: CrossRefValidation
. DomainDnsZones — пройдена проверка
CrossRefValidation

Выполнение проверок разделов на: Schema
Запуск проверки: CheckSDRefDom
. Schema — пройдена проверка CheckSDRefDom
Запуск проверки: CrossRefValidation
. Schema — пройдена проверка
CrossRefValidation

Выполнение проверок разделов на: Configuration
Запуск проверки: CheckSDRefDom
. Configuration — пройдена проверка
CheckSDRefDom
Запуск проверки: CrossRefValidation
. Configuration — пройдена проверка
CrossRefValidation

Выполнение проверок разделов на: zarya
Запуск проверки: CheckSDRefDom
. zarya — пройдена проверка CheckSDRefDom
Запуск проверки: CrossRefValidation
. zarya — пройдена проверка CrossRefValidation

Выполнение проверок предприятия на: zarya.local
Запуск проверки: LocatorCheck
. zarya.local — пройдена проверка LocatorCheck
Запуск проверки: Intersite
. zarya.local — пройдена проверка Intersite

Диагностика сервера каталогов

Выполнение начальной настройки:
Выполняется попытка поиска основного сервера.
Основной сервер = G004
* Идентифицирован лес AD.
Сбор начальных данных завершен.

Выполнение обязательных начальных проверок

Сервер проверки: Default-First-Site-NameG004
Запуск проверки: Connectivity
. G004 — пройдена проверка Connectivity

Выполнение основных проверок

Сервер проверки: Default-First-Site-NameG004
Запуск проверки: Advertising
. G004 — пройдена проверка Advertising
Запуск проверки: FrsEvent
. G004 — пройдена проверка FrsEvent
Запуск проверки: DFSREvent
За последние 24 часа после предоставления SYSVOL в общий доступ
зафиксированы предупреждения или сообщения об ошибках. Сбои при
репликации SYSVOL могут стать причиной проблем групповой политики.
. G004 — не пройдена проверка DFSREvent
Запуск проверки: SysVolCheck
. G004 — пройдена проверка SysVolCheck
Запуск проверки: KccEvent
. G004 — пройдена проверка KccEvent
Запуск проверки: KnowsOfRoleHolders
. G004 — пройдена проверка KnowsOfRoleHolders
Запуск проверки: MachineAccount
. G004 — пройдена проверка MachineAccount
Запуск проверки: NCSecDesc
. G004 — пройдена проверка NCSecDesc
Запуск проверки: NetLogons
. G004 — пройдена проверка NetLogons
Запуск проверки: ObjectsReplicated
. G004 — пройдена проверка ObjectsReplicated
Запуск проверки: Replications
. G004 — пройдена проверка Replications
Запуск проверки: RidManager
. G004 — пройдена проверка RidManager
Запуск проверки: Services
. G004 — пройдена проверка Services
Запуск проверки: SystemLog
. G004 — пройдена проверка SystemLog
Запуск проверки: VerifyReferences
. G004 — пройдена проверка VerifyReferences

Выполнение проверок разделов на: ForestDnsZones
Запуск проверки: CheckSDRefDom
. ForestDnsZones — пройдена проверка
CheckSDRefDom
Запуск проверки: CrossRefValidation
. ForestDnsZones — пройдена проверка
CrossRefValidation

Выполнение проверок разделов на: DomainDnsZones
Запуск проверки: CheckSDRefDom
. DomainDnsZones — пройдена проверка
CheckSDRefDom
Запуск проверки: CrossRefValidation
. DomainDnsZones — пройдена проверка
CrossRefValidation

Выполнение проверок разделов на: Schema
Запуск проверки: CheckSDRefDom
. Schema — пройдена проверка CheckSDRefDom
Запуск проверки: CrossRefValidation
. Schema — пройдена проверка
CrossRefValidation

Выполнение проверок разделов на: Configuration
Запуск проверки: CheckSDRefDom
. Configuration — пройдена проверка
CheckSDRefDom
Запуск проверки: CrossRefValidation
. Configuration — пройдена проверка
CrossRefValidation

Выполнение проверок разделов на: zarya
Запуск проверки: CheckSDRefDom
. zarya — пройдена проверка CheckSDRefDom
Запуск проверки: CrossRefValidation
. zarya — пройдена проверка CrossRefValidation

Выполнение проверок предприятия на: zarya.local
Запуск проверки: LocatorCheck
. zarya.local — пройдена проверка LocatorCheck
Запуск проверки: Intersite
. zarya.local — пройдена проверка Intersite

netdom query fsmo c G002

netdom query fsmo c G004

repadmin /showutdvec c G002

C:Windowssystem32>repadmin /showutdvec g002.zarya.local dc=zarya,dc=local
Кэширование кодов GUID.
..
Default-First-Site-NameG002 @ USN 4749838 @ Время 2013-04-11 17:07:10
Default-First-Site-NameG004 @ USN 3892279 @ Время 2011-04-10 13:46:31

repadmin /showrepl с G002

Repadmin: выполнение команды /showrepl контроллере домена localhost с полным дос
тупом
Default-First-Site-NameG002
Параметры DSA: IS_GC
Параметры сайта: (none)
DSA — GUID объекта: 325ebd46-3d0d-469a-931d-c10a510af870
DSA — код вызова: 325ebd46-3d0d-469a-931d-c10a510af870

DC=zarya,DC=local
Default-First-Site-NameG004 через RPC
DSA — GUID объекта: 1304830e-bcc3-4503-ba44-bc2758f00955
Последняя попытка @ 2013-04-11 17:06:28 завершена с ошибкой, результат 8
614 (0x21a6):
Репликация службы каталогов с этим сервером невозможна, поскольку вр
емя с момента последней репликации с этим сервером превышает время жизни захорон
ения.
1149 последовательных ошибок.
Последний успех @ 2013-04-10 13:46:31.

CN=Configuration,DC=zarya,DC=local
Default-First-Site-NameG004 через RPC
DSA — GUID объекта: 1304830e-bcc3-4503-ba44-bc2758f00955
Последняя попытка @ 2013-04-11 16:51:48 успешна.

CN=Schema,CN=Configuration,DC=zarya,DC=local
Default-First-Site-NameG004 через RPC
DSA — GUID объекта: 1304830e-bcc3-4503-ba44-bc2758f00955
Последняя попытка @ 2013-04-11 16:51:48 успешна.

DC=DomainDnsZones,DC=zarya,DC=local
Default-First-Site-NameG004 через RPC
DSA — GUID объекта: 1304830e-bcc3-4503-ba44-bc2758f00955
Последняя попытка @ 2013-04-11 16:51:48 успешна.

DC=ForestDnsZones,DC=zarya,DC=local
Default-First-Site-NameG004 через RPC
DSA — GUID объекта: 1304830e-bcc3-4503-ba44-bc2758f00955
Последняя попытка @ 2013-04-11 16:51:48 успешна.

Источник: Default-First-Site-NameG004
******* 1147 ПОСЛЕДОВАТЕЛЬНЫХ ОШИБОК с 2013-04-10 13:46:31
Последняя ошибка: 8614 (0x21a6):
Репликация службы каталогов с этим сервером невозможна, поскольку вр
емя с момента последней репликации с этим сервером превышает время жизни захорон
ения.
C:Windowssystem32>

repadmin /showrepl с G004

Repadmin: выполнение команды /showrepl контроллере домена localhost с полным дос
тупом
Default-First-Site-NameG004
Параметры DSA: IS_GC
Параметры сайта: (none)
DSA — GUID объекта: 1304830e-bcc3-4503-ba44-bc2758f00955
DSA — код вызова: 9aebb0f8-f5d4-4fc1-81a6-ce6c7cb1723a

DC=zarya,DC=local
Default-First-Site-NameG002 через RPC
DSA — GUID объекта: 325ebd46-3d0d-469a-931d-c10a510af870
Последняя попытка @ 2013-04-11 17:10:15 успешна.

CN=Configuration,DC=zarya,DC=local
Default-First-Site-NameG002 через RPC
DSA — GUID объекта: 325ebd46-3d0d-469a-931d-c10a510af870
Последняя попытка @ 2013-04-11 16:50:00 успешна.

CN=Schema,CN=Configuration,DC=zarya,DC=local
Default-First-Site-NameG002 через RPC
DSA — GUID объекта: 325ebd46-3d0d-469a-931d-c10a510af870
Последняя попытка @ 2013-04-11 16:50:01 успешна.

DC=DomainDnsZones,DC=zarya,DC=local
Default-First-Site-NameG002 через RPC
DSA — GUID объекта: 325ebd46-3d0d-469a-931d-c10a510af870
Последняя попытка @ 2013-04-11 16:50:01 успешна.

DC=ForestDnsZones,DC=zarya,DC=local
Default-First-Site-NameG002 через RPC
DSA — GUID объекта: 325ebd46-3d0d-469a-931d-c10a510af870
Последняя попытка @ 2013-04-11 16:50:01 успешна.

Уже пробовал использовать команду с сервера G002 repadmin /replicate G004.zarya.local G002.zarya.local dc=zarya,dc=local
Команда отработала. Радостно сказала, что все ОК. Но ничего не изменилось

Проверил свойство userAccountControl.
Стоит значение 532480, как и должно быть.

Пробовал использовать команду repadmin /removelingeringobjects g004.zarya.local GUID_g002.zarya.local dc=zarya,dc=local /advisory_mode
В логах мусорных объектов не обнаружил. Пробовал в обоих направлениях. Везде 0.

Проверил наличие SYSVOL и NETLOGON. Присутствуют на обоих серверах. Совпадают по количеству файлов и папок, а также по размеру.

Помогите решить проблему. Моих знаний тут явно не хватает. Google и Yandex «по курил» — из того, что там нашел, ничего не помогло.

Источник

One day, you wanna rename a domain controller in the forest just like me did a couple days ago. You wanna make sure everything OK before making any changes to the system using repadmin tool (included in Windows Server 2008):

> repadmin /showrepl

But, a domain, called it DC-A, in the forest raises the 8614 error indicates that: «The Active Directory cannot replicate with this server because the time since the last replication with this server has exceeded the tombstone lifetime»

Oops…!

In this situation, to troubleshoot, I suggest that you should use 2 tools of the Windows server environment:

+ Event Viewer: to open it: Start -> Run -> type eventvwr

+ Command Prompt: Start -> Run -> cmd (if you find  the size of the command prompt window is too small, you can extend it following the instructions in my blog post here)

Here is how I can fix the issue:

1. Verify which Domain Controller raised the 8614 error by using:

> repadmin /showrepl
or
> repadmin /showreps

* Run this command line in any DC not DC-A.

* In addition, open Event Viewer, in Applications and Services Logs, Directory Service, you will see an error with event ID 2042

According to Mirosoft knowledge base, it’s maybe because the domain controller contains what so called lingering objects: http://support.microsoft.com/kb/2020053. This is the most possible reason for the error, because everything else are OK (time, default tombstone lifetime).

2. So, I have to remove those lingering objects from all DCs:

> repadmin /removelingeringobjects DC-A.MYDOMAIN.COM 5b0b944e-de7b-4f96-942b-1e040169db36 «CN=Configuration,DC=MYDOMAIN,DC=COM»

+ DC-A.MYDOMAIN.COM : FQDN of DC-A

+ 5b0b944e-de7b-4f96-942b-1e040169db36 : the GUID of DC-A. You can get it from the command repadmin /showrepl DC-A.

+ «CN=Configuration,DC=MYDOMAIN,DC=COM»: NC in which DC-A raise the error (from the output of the command repadmin /showrepl)


* Repeat in all other DCs in forest.

3. Evaluate setting strict replication on all DCs in forest:

> repadmin /regkey * +strict

4. Set «Allow replication with divergent and corrupt partner = 1» on all DCs:

> repadmin /regkey * +allowDivergent

5. Flush DNS Cache and restart netlogon service in DC-A:

+ > ipconfig /flushdns

+ > net stop netlogon

+ rename netlogon.dns and netlogon.dnb file which locate in C:WindowsSystem32

+ > ipconfig /flushdns

+ > net start netlogon (this command will re-create netlogon.dns and netlogon.dnb files)

+ > ipconfig /registerdns

6. Check the replication of all DCs again using repadmin and Event Viewer

> repadmin /showrepl

7. Delete «Allow replication with divergent and corrupt partner» or set «Allow replication with divergent and corrupt partner = 0» in the registry of all DCs.

> repadmin /regkey * -allowDivergent

8. Check the replication of all DCs again using repadmin and Event Viewer

And all the DCs will replicate successfully!

Now you can rename the DC as you wish.

References:

— http://support.microsoft.com/kb/2020053