Устранение ошибки репликации Active Directory 8614

2025-01-15

В этой статье приведены действия по устранению неполадок с ошибкой репликации Active Directory 8614.

Исходный номер базы знаний: 2020053

Примечание.

Домашние пользователи: эта статья предназначена только для агентов технической поддержки и ИТ-специалистов. Если вы ищете помощь с проблемой, обратитесь к сообществу Майкрософт.

Симптомы

DCDIAG сообщает, что сбой теста репликации Active Directory с кодом состояния ошибки 8614: Active Directory не может реплицироваться с этим сервером, так как время после последней репликации с этим сервером превысило время существования могилы.

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.

REPADMIN.EXE сообщает, что последняя попытка репликации завершилась ошибкой состояния 8614. Команды REPADMIN, которые обычно ссылаются на состояние 8614, но не ограничиваются:
- REPADMIN /REPLSUM
- REPADMIN /SHOWREPL
- REPADMIN /SHOWREPS
- REPADMIN /SYNCALL
Пример выходных данных из REPADMIN /SHOWREPS изображения входящего репликации из CONTOSO-DC2 в CONTOSO-DC1, завершив ошибку доступа к репликации, показана ниже:
```
 efault-First-Site-Name\CONTOSO-DC1  
 DSA Options: IS_GC  
 Site Options: (none)  
 DSA object GUID:  
 DSA invocationID:  

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

DC=contoso,DC=com  
Default-First-Site-Name\CONTOSO-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>.  
```

События NTDS KCC, NTDS General или Microsoft-Windows-ActiveDirectory_DomainService с пятью состояниями регистрируются в журнале событий службы каталогов.

События Active Directory, которые обычно ссылаются на состояние 8524, но не ограничиваются:

Источник событий	ID	Строка события
NTDS KCC	1925	Сбой попытки установить ссылку репликации для следующего раздела каталога, допускаемого для записи.

Событие репликации NTDS 2042 может быть зарегистрировано в журнале событий службы каталогов:

Event Type: Error
Event Source: NTDS Replication
Event Category: Replication
Event ID: 2042
User: NT AUTHORITY\ANONYMOUS 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.

Команда репликации теперь в сайтах и службах Active Directory возвращает следующее сообщение:

Active Directory не может реплицировать с этим сервером, так как время после последней репликации с этим сервером превысило время существования могилы.

Щелкните правой кнопкой мыши объект подключения из исходного контроллера домена и выберите реплицировать сейчас в сайтах и службах Active Directory (DSSITE). MSC) неудачно. Отобразится следующее сообщение.

Active Directory не может реплицировать с этим сервером, так как время после последней репликации с этим сервером превысило время существования могилы.

Текст сообщения об ошибке на экране выглядит следующим образом:

Текст заголовка диалогового окна: репликация
Текст сообщения диалогового окна: во время попытки синхронизации контекста <именования %directory partition name%> from Domain Controller <Source DC to Domain Controller <Destination DC>>:

Active Directory не может реплицироваться с этим сервером, так как время после последней репликации с этим сервером превысило время существования могилы.
Операция не продолжится

Кнопки в диалоговом окне: ОК

Причина

Контроллеры домена Active Directory поддерживают репликацию с несколькими узлами. Любой контроллер домена, содержащий записываемую секцию, может создавать, изменять или удалять объект или атрибут (значение). Знание удаления объектов или атрибутов сохраняется в течение времени существования могилы в днях. (См. раздел Сведения о задерживающихся объектах в лесу Windows Server Active Directory.

Active Directory требует сквозной репликации от всех владельцев секций, чтобы транзитивно реплицировать все исходящие удаления для секций каталогов всем владельцам секций. Сбой входящего репликации секции каталога в скользящем количестве дней TSL приводит к затяжке объектов. Задерживающийся объект — это объект, который намеренно удален по крайней мере одним контроллером домена, но неправильно существует на целевых контроллерах домена, которые не смогли реплицировать временные знания обо всех уникальных удалениях.

Ошибка 8614 — это пример логики, добавленной в контроллеры домена под управлением Windows Server 2003 или более поздней версии. Он помещает в карантин распространение задерживающихся объектов и определяет долгосрочные сбои репликации, которые вызывают несогласованные секции каталогов.

К первопричинам ошибки 8614 и события репликации NTDS 2042 относятся:

Целевой контроллер домена, регистрируемый ошибкой 8614, не удалось выполнить реплицирование секции каталога из одного или нескольких исходных контроллеров домена для числа дней существования могилы.
Системное время на целевом контроллере домена перемещено или перескочило, время существования могилы в течение одного или нескольких дней в будущем с момента последней успешной репликации. Он предоставляет обработчику репликации, который целевой контроллер домена не смог выполнить реплицировать входящий раздел каталога для времени существования могилы, истекшего в течение нескольких дней.

Скачки времени могут возникать, когда выполняются следующие условия:
- Целевой контроллер домена успешно реплицирует входящий трафик, принимает недопустимый TSL системного времени или более дней в будущем.
- Затем целевой контроллер домена пытается реплицировать входящий трафик из источника, который последний раз реплицировался из TSL или более дней в прошлом.
Or

Время переходит с текущего времени на дату и время существования могилы или более дней в прошлом, успешно реплицирует входящий трафик. Затем он пытается реплицировать входящий трафик после принятия TSL времени или более дней в будущем.

В основном причина и разрешение ошибки репликации 8614 применяются одинаково к причине и разрешению события репликации NTDS 2042.

Решение

Примечание.

Существует два плана действий для восстановления контроллеров домена Active Directory, которые регистрируют состояние ошибки 8614 или событие репликации NTDS 2042. Вы можете принудительно понижение контроллера домена или использовать приведенный ниже план действий. Проверьте наличие необходимых исправлений, найдите временные переходы, проверьте наличие неустранимых объектов и удалите их, если они присутствуют, удалите карантины репликации, устраните сбои репликации, а затем снова поместите контроллер домена в службу. Принудительное понижение таких контроллеров данных может быть проще и быстрее, но может привести к потере исходных обновлений (т. е. потере данных) на контроллере домена, который принудительно понижен. Active Directory корректно восстанавливается из этого условия, выполнив приведенные ниже действия. Выберите оптимальное решение для вашего сценария. Не предполагайте, что принудительное понижение является единственным рабочим решением, особенно если сбой репликации легко устранить или является внешним для Active Directory.

Проверьте наличие недефакционных значений времени существования могилы.

По умолчанию время существования tombstone использует либо 60, либо 180 дней в зависимости от версии Windows, развернутой в лесу. служба поддержки Майкрософт регулярно отображает контроллеры домена, которые завершились сбоем входящего репликации в течение этих периодов времени. Также возможно, что время существования могилы было настроено на короткий период, например два дня. Если да, контроллеры домена, которые не реплицировали входящий трафик, скажем, пять дней завершится сбоем следующего теста:

Все контроллеры домена должны реплицироваться с скользящим числом дней TSL

Используется repadmin /showattr для просмотра того, настроено ли недедефолтное значение для атрибута TombstoneLifetime .
```
repadmin /showattr <DC_name> "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<forest root domain>,DC=<top level domain>"
```
Если атрибут отсутствует в выходных showattr данных, используется внутреннее значение по умолчанию.
Проверьте наличие контроллеров домена, которые завершили сбой входящего репликации для TSL в течение нескольких дней.

Выполните repadmin /showrepl * /csv синтаксический анализ с помощью Excel, как указано в разделе "Проверка успешной репликации в контроллер домена ". Отсортируйте выходные данные replsum в Excel в столбце последнего успешного выполнения репликации в порядке от наименьшего текущего до последней даты и времени.
Проверьте время скачков.

Чтобы определить, произошло ли скачок времени, проверьте журналы событий и диагностики (repadmin /showrepsжурналы dcdiag) на целевых контроллерах домена, которые регистрируют ошибки 8614 для следующих меток времени:
- Метки дат, предшествующие выпуску операционной системы. Например, метки дат из Windows Server 2003 для ОС, выпущенной в Windows Server 2008.
  - Метки даты, предшествующие установке операционной системы в лесу.
  - Метки дат в будущем.
  - События, регистрированные в заданном диапазоне дат, не регистрируются.
служба поддержки Майкрософт команды видели системное время на рабочих контроллерах домена неправильно переходные часы, дни, недели, годы и даже десятки лет в прошлом и будущем.

Если системное время было найдено неточным, исправьте его. Затем попробуйте определить, почему время прыгнуло, и что можно сделать, чтобы предотвратить неточное время идти вперед и просто исправлять плохое время. Возможные области для изучения:
- Настроен ли корневой PDC леса с помощью внешнего источника времени?
  - Доступны ли источники времени ссылки в Сети, доступны ли в сети и разрешены в DNS?
  - Запущена ли служба майкрософт или стороннего времени и в состоянии без ошибок?
  - Настроены ли компьютеры dc-role для использования иерархии NT5DS для исходного времени?
  - Была ли защита отката времени, описанная в разделе "Как настроить службу времени Windows для большого смещения времени" на месте?
  - Есть ли системные часы хорошие батареи и точное время в BIOS?
  - Настроены ли виртуальные узлы и гостевые компьютеры в соответствии с рекомендациями производителей размещения?
В этой статье описано, как настроить службу времени Windows для выполнения больших шагов смещения времени, чтобы защитить контроллеры домена от прослушивания недопустимых примеров времени. Дополнительные сведения о MaxPosPhaseCorrection и MaxNegPhaseCorrection доступны в службе времени Windows.

Проверьте и удалите неустранимые объекты, если они присутствуют.

Точка карантина репликации ошибок 8614 заключается в том, чтобы проверить наличие неустранимых объектов и удалить их, если они присутствуют, в каждой локально удерживаемой секции, прежде чем задать параметр Allow Replication с дивергентным и поврежденным партнером 1 в реестре целевого контроллера домена, даже если вы считаете, что все целевые контроллеры домена в лесу выполняются в строгой согласованности репликации.

Удаление задерживающихся объектов выходит за рамки этой статьи. Дополнительные сведения см. в следующих статьях:

Repadmin Здесь показан синтаксис:

Синтаксис	Справка по Сети (Windows Server 2008 и более поздние версии)
`c:\>repadmin /removelingeringobjects <Dest_DSA_LIST> <Source DSA GUID> <NC> [/advisory_mode]`	`c:\>repadmin /help:removelingeringobject`

Оцените строгую репликацию на целевых контроллерах домена.

Репликация в строгом режиме предотвращает повторное анимирование объектов на целевых контроллерах домена, которые использовали сборку мусора для создания, удаления и восстановления намеренно удаленных объектов.

Раздел реестра для строгой репликации:

Путь: HKEY_LOCAL_MACHINE\system\ccs\services\ntds\parameters.
Параметр. Строгая согласованность репликации <— не учитывает регистр>
Тип: reg_dword
Значение: 0 | 1

Repadmin Синтаксис включения и отключения строгой репликации на одном или нескольких контроллерах домена выглядит следующим образом:

Синтаксис	Справка по Сети (Windows Server 2008 и более поздние версии)	Включение в одном контроллере домена	Включение на всех контроллерах домена в лесу	Включение для всех GCs в лесу
`repadmin /regkey <DSA_LIST> <{+\|-}key> [value [/reg_sz]`]	`Repadmin /help:regkey`	`repadmin /regkey <fully qualified computer name> +strict`	`repadmin /regkey * +strict`	`repadmin /regkey gc: +strict`

Установите для параметра Allow replication with divergent and corrupt partner to 1 on the 8614 DC.

После удаления всех задерживающихся объектов отключите карантин репликации на основе времени:

Метод реестра:

Путь к реестру: HKEY_LOCAL_MACHINE\system\ccs\services\ntds\parameters
Параметр реестра: разрешить репликацию с развергентным и поврежденным партнером <— не учитывает регистр》
Значение реестра: 0 = запретить, 1 = разрешить

Repadmin Метод:

Синтаксис	Справка по Сети (Windows Server 2008 и более поздние версии)	Включение в одном контроллере домена	Включение на всех контроллерах домена в лесу	Включение для всех GCs в лесу
`repadmin /regkey <DSA_LIST> <{+\|-}key> [value [/reg_sz]`]	`Repadmin /help:regkey`	`repadmin /regkey dc01.contoso.com +allowDivergent`	`repadmin /regkey * +allowDivergent`	`repadmin /regkey GC: +allowDivergent`

Устраните сбои репликации AD, если они присутствуют.

Когда состояние ошибки 8614 регистрируется в целевом контроллере домена, предыдущие ошибки репликации, зарегистрированные в предыдущем номере TSL, маскируются.

Тот факт, что ошибка 8614 была сообщена целевым контроллером домена, не означает, что ошибка репликации находится в целевом контроллере домена. Вместо этого источник сбоя репликации может быть связан с разрешением сетевых или DNS-имен. Или может возникнуть проблема с одним из следующих элементов:
- проверка подлинности
- Реактивная база данных
- Топология
- подсистема репликации в исходном контроллере домена или целевом контроллере домена
Просмотрите прошлые события службы каталогов и выходные данные диагностики (dcdiag, repadmin журналы), созданные исходным контроллером домена, конечным контроллером домена и альтернативными партнерами репликации в прошлом, чтобы определить область и состояние сбоя, которое предотвращает репликацию между конечным контроллером домена и исходным контроллером домена.
Удаление разрешения репликации с использованием разных и поврежденных партнеров или установка разрешения репликации с разнонаправленным и поврежденным партнером 0 в реестре.
Отслеживайте репликацию Active Directory ежедневно.

Мониторинг сквозной репликации в лесу Active Directory ежедневно с помощью приложения мониторинга Active Directory. Один из недорогих, но эффективных вариантов заключается в выполнении repadmin /showrepl * /csv и анализе результатов в Excel. Дополнительные сведения см . в методе 2. Мониторинг репликации с помощью командной строки.

Определите контроллеры домена, которые приближаются к сбоям репликации на 50 процентов и на 90 процентов времени существования могилы. Поместите их в список наблюдения. При 50 процентах TSL сделайте сильную отправку для устранения ошибок репликации. На 90 процентов рекомендуется понизить контроллеры домена, которые вызывают ошибки репликации принудительно, если это необходимо. Это можно сделать с помощью команды dcpromo /forceremoval.

Опять же, ошибки репликации, зарегистрированные в целевом контроллере домена, могут быть вызваны проблемой:
- Исходный контроллер домена
- Целевой контроллер домена
- Базовая сеть
Поэтому попробуйте определить причину и место сбоя перед выполнением профилактического действия.

Сбор данных

Если вам нужна помощь от службы поддержки Майкрософт, мы рекомендуем собрать информацию, выполнив действия, описанные в разделе "Сбор сведений" с помощью TSS для проблем с репликацией Active Directory.

Ссылки

Устранение проблем с объектом репликации Lingering (идентификаторы событий 1388, 1988, 2042)