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

Один из механизмов Active Directory (AD), с которым могут быть связаны всевозможные затруднения, это репликация. Репликация – критически важный процесс в работе одного или более доменов или контроллеров домена (DC), и не важно, находятся они на одном сайте или на разных. Неполадки с репликацией могут привести к проблемам с аутентификацией и доступом к сетевым ресурсам. Обновления объектов AD реплицируются на контроллеры домена, чтобы все разделы были синхронизированы. В крупных компаниях использование большого количества доменов и сайтов – обычное дело. Репликация должна происходить внутри локального сайта, так же как дополнительные сайты должны сохранять данные домена и леса между всеми DC.

В этой статье речь пойдет о методах выявления проблем с репликацией в AD. Кроме того, я покажу, как находить и устранять неисправности и работать с четырьмя наиболее распространенными ошибками репликации AD:

Error 2146893022 (главное конечное имя неверно);
Error 1908 (не удалось найти контроллер домена);
Error 8606 (недостаточно атрибутов для создания объекта);
Error 8453 (доступ к репликации отвергнут).

Вы также узнаете, как анализировать метаданные репликации с помощью таких инструментов, как AD Replication Status Tool, встроенная утилита командной строки RepAdmin.exe и Windows PowerShell.

Для всестороннего рассмотрения я буду использовать лес Contoso, который показан на рисунке. В таблице 1 перечислены роли, IP-адреса и настройки DNS-клиента для компьютеров данного леса.

Рисунок. Архитектура леса

Роли системы и настройки

Для обнаружения неполадок с репликацией AD запустите AD Replication Status Tool на рабочей станции администратора в корневом домене леса. Например, вы открываете этот инструмент из системы Win8Client, а затем нажимаете кнопку Refresh Replication Status для уверенности в четкой коммуникации со всеми контроллерами домена. В таблице Discovery Missing Domain Controllers на странице Configuration/Scope Settings инструмента можно увидеть два недостающих контроллера домена, как показано на экране 1.

Экран 1. Два недостающих контроллера домена

В таблице Replication Status Collection Details вы можете проследить статус репликации контроллеров домена, которые никуда не пропадали, как показано на экране 2.

Экран 2. Статус репликации контроллеров домена

Пройдя на страницу Replication Status Viewer, вы обнаружите некоторые ошибки в репликации. На экране 3 видно, что возникает немалое число ошибок репликации, возникающих в лесу Contoso. Из пяти контроллеров домена два не могут видеть другие DC, а это означает, что репликация не будет происходить на контроллерах домена, которые не видны. Таким образом, пользователи, подключающиеся к дочерним DC, не будут иметь доступ к самой последней информации, что может привести к проблемам.

Экран 3. Ошибки репликации, возникающие в лесу Contoso

Поскольку ошибки репликации все же возникают, полезно задействовать утилиту командной строки RepAdmin.exe, которая помогает получить отчет о состоянии репликации по всему лесу. Чтобы создать файл, запустите следующую команду из Cmd.exe:

Repadmin /showrel * /csv > ShowRepl.csv

Проблема с двумя DC осталась, соответственно вы увидите два вхождения LDAP error 81 (Server Down) Win32 Err 58 на экране, когда будет выполняться команда. Мы разберемся с этими ошибками чуть позже. А теперь откройте ShowRepl.csv в Excel и выполните следующие шаги:

Из меню Home щелкните Format as table и выберите один из стилей.
Удерживая нажатой клавишу Ctrl, щелкните столбцы A (Showrepl_COLUMNS) и G (Transport Type). Правой кнопкой мыши щелкните в этих столбцах и выберите Hide.
Уменьшите ширину остальных столбцов так, чтобы был виден столбец K (Last Failure Status).
Для столбца I (Last Failure Time) нажмите стрелку вниз и отмените выбор 0.
Посмотрите на дату в столбце J (Last Success Time). Это последнее время успешной репликации.
Посмотрите на ошибки в столбце K (Last Failure Status). Вы увидите те же ошибки, что и в AD Replication Status Tool.

Таким же образом вы можете запустить средство RepAdmin.exe из PowerShell. Для этого сделайте следующее:

1. Перейдите к приглашению PowerShell и введите команду

Repadmin /showrepl * /csv | ConvertFrom-Csv | Out-GridView

2. В появившейся сетке выберите Add Criteria, затем Last Failure Status и нажмите Add.

3. Выберите подчеркнутое слово голубого цвета contains в фильтре и укажите does not equal.

4. Как показано на экране 4, введите 0 в поле, так, чтобы отфильтровывалось все со значением 0 (успех) и отображались только ошибки.

Экран 4. Задание фильтра

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

Исправление ошибки AD Replication Error -2146893022

Итак, начнем с устранения ошибки -2146893022, возникающей между DC2 и DC1. Из DC1 запустите команду Repadmin для проверки статуса репликации DC2:

Repadmin /showrepl dc2

На экране 5 показаны результаты, свидетельствующие о том, что репликация перестала выполняться, поскольку возникла проблема с DC2: целевое основное имя неверно. Тем не менее, описание ошибки может указать ложный путь, поэтому приготовьтесь копать глубже.

Экран 5. Проблема с DC2 — целевое основное имя неверно

Во-первых, следует определить, есть ли базовое подключение LDAP между системами. Для этого запустите следующую команду из DC2:

Repadmin /bind DC1

На экране 5 видно, что вы получаете сообщение об ошибке LDAP. Далее попробуйте инициировать репликацию AD с DC2 на DC1:

Repadmin /replicate dc2 dc1 «dc=root,dc=contoso,dc=com»

И на этот раз отображается та же ошибка с главным именем, как показано на экране 5. Если открыть окно Event Viewer на DC2, вы увидите событие с Event ID 4 (см. экран 6).

Экран 6. Сообщение о событии с Event ID 4

Выделенный текст в событии указывает на причину ошибки. Это означает, что пароль учетной записи компьютера DC1 отличается от пароля, который хранится в AD для DC1 в Центре распределения ключей – Key Distribution Center (KDC), который в данном случае запущен на DC2. Значит, следующая наша задача – определить, соответствует ли пароль учетной записи компьютера DC1 тому, что хранится на DC2. В командной строке на DC1 введите две команды:

Repadmin /showobjmeta dc1 «cn=dc1,ou=domain controllers,

dc=root,dc=contoso,dc=com» > dc1objmeta1.txt

Repadmin /showobjmeta dc2 «cn=dc1,ou=domain controllers,

dc=root,dc=contoso,dc=com» > dc1objmeta2.txt

Далее откройте файлы dc1objmeta1.txt и dc1objmeta2.txt, которые были созданы, и посмотрите на различия версий для dBCSPwd, UnicodePWD, NtPwdHistory, PwdLastSet и lmPwdHistory. В нашем случае файл dc1objmeta1.txt показывает версию 19, тогда как версия в файле dc1objmeta2.txt – 11. Таким образом, сравнивая эти два файла, мы видим, что DC2 содержит информацию о старом пароле для DC1. Операция Kerberos не удалась, потому что DC1 не смог расшифровать билет службы, представленный DC2.

KDC, запущенный на DC2, не может быть использован для Kerberos вместе с DC1, так как DC2 содержит информацию о старом пароле. Чтобы решить эту проблему, вы должны заставить DC2 использовать KDC на DC1, чтобы завершить репликацию. Для этого вам, в первую очередь, необходимо остановить службу KDC на DC2:

Net stop kdc

Теперь требуется начать репликацию корневого раздела Root:

Repadmin /replicate dc2 dc1 «dc=root,dc=contoso,dc=com»

Следующим вашим шагом будет запуск двух команд Repadmin /showobjmeta снова, чтобы убедиться в том, что версии совпадают. Если все хорошо, вы можете перезапустить службу KDC:

Net start kdc

Обнаружение и устранение ошибки AD Replication Error 1908

Теперь, когда мы устранили ошибку -2146893022, давайте перейдем к ошибке репликации AD 1908, где DC1, DC2 и TRDC1 так и не удалось выполнить репликацию из ChildDC1. Решить проблему можно следующим образом. Используйте Nltest.exe для создания файла Netlogon.log, чтобы выявить причину ошибки 1908. Прежде всего, включите расширенную регистрацию на DC1, запустив команду:

Nltest /dbflag:2080fff

Теперь, когда расширенная регистрация включена, запустите репликацию между DC – так все ошибки будут зарегистрированы. Этот шаг поможет запустить три команды для воспроизведения ошибок. Итак, во-первых, запустите следующую команду на DC1:

Repadmin /replicate dc1 childdc1 dc=child,dc=root,
dc=contoso,dc=com

Результат, показанный на экране 7, говорит о том, что репликация не состоялась, потому что DC домена не может быть найден.

Экран 7. Репликация не состоялась, потому что DC домена не может быть найден

Во-вторых, из DC1 попробуйте определить местоположение KDC в домене child.root.contoso.com с помощью команды:

Nltest /dsgetdc:child /kdc

Результаты на экране 7 свидетельствуют, что такого домена нет. В-третьих, поскольку вы не можете найти KDC, попытайтесь установить связь с любым DC в дочернем домене, используя команду:

Nltest /dsgetdc:child

В очередной раз результаты говорят о том, что нет такого домена, как показано на экране 7.

Теперь, когда вы воспроизвели все ошибки, просмотрите файл Netlogon.log, созданный в папке C:Windowsdebug. Откройте его в «Блокноте» и найдите запись, которая начинается с DSGetDcName function called. Обратите внимание, что записей с таким вызовом будет несколько. Вам нужно найти запись, имеющую те же параметры, что вы указали в команде Nltest (Dom:child и Flags:KDC). Запись, которую вы ищете, будет выглядеть так:

DSGetDcName function called: client PID=2176,
Dom:child Acct:(null) Flags:KDC

Вы должны просмотреть начальную запись, равно как и последующие, в этом потоке. В таблице 2 представлен пример потока 3372. Из этой таблицы следует, что поиск DNS записи KDC SRV в дочернем домене был неудачным. Ошибка 1355 указывает, что заданный домен либо не существует, либо к нему невозможно подключиться.

Пример потока 3372

Поскольку вы пытаетесь подключиться к Child.root.contoso.com, следующий ваш шаг – выполнить для него команду ping из DC1. Скорее всего, вы получите сообщение о том, что хост не найден. Информация из файла Netlogon.log и ping-тест указывают на возможные проблемы в делегировании DNS. Свои подозрения вы можете проверить, сделав тест делегирования DNS. Для этого выполните следующую команду на DC1:

Dcdiag /test:dns /dnsdelegation > Dnstest.txt

На экране 8 показан пример файла Dnstest.txt. Как вы можете заметить, это проблема DNS. Считается, что IP-адрес 192.168.10.1 – адрес для DC1.

Экран 8. Пример файла Dnstest.txt

Чтобы устранить проблему DNS, сделайте следующее:

1. На DC1 откройте консоль управления DNS.

2. Разверните Forward Lookup Zones, разверните root.contoso.com и выберите child.

3. Щелкните правой кнопкой мыши (как в родительской папке) на записи Name Server и выберите пункт Properties.

4. Выберите lamedc1.child.contoso.com и нажмите кнопку Remove.

5. Выберите Add, чтобы можно было добавить дочерний домен сервера DNS в настройки делегирования.

6. В окне Server fully qualified domain name (FQDN) введите правильный сервер childdc1.child.root.contoso.com.

7. В окне IP Addresses of this NS record введите правильный IP-адрес 192.168.10.11.

8. Дважды нажмите кнопку OK.

9. Выберите Yes в диалоговом окне, где спрашивается, хотите ли вы удалить связующую запись (glue record) lamedc1.child.contoso.com [192.168.10.1]. Glue record – это запись DNS для полномочного сервера доменных имен для делегированной зоны.

10. Используйте Nltest.exe для проверки, что вы можете найти KDC в дочернем домене. Примените опцию /force, чтобы кэш Netlogon не использовался:

Nltest /dsgetdc:child /kdc /force

11. Протестируйте репликацию AD из ChildDC1 на DC1 и DC2. Это можно сделать двумя способами. Один из них – выполнить команду

Repadmin /replicate dc1 childdc1 «dc=child,dc=root,
dc=contoso,dc=com»

Другой подход заключается в использовании оснастки Active Directory Sites и Services консоли Microsoft Management Console (MMC), в этом случае правой кнопкой мыши щелкните DC и выберите Replicate Now, как показано на экране 9. Вам нужно это сделать для DC1, DC2 и TRDC1.

Экран 9. Использование оснастки Active Directory Sites и?Services

После этого вы увидите диалоговое окно, как показано на экране 10. Не учитывайте его, нажмите OK. Я вкратце расскажу об этой ошибке.

Экран 10. Ошибка при репликации

Когда все шаги выполнены, вернитесь к AD Replication Status Tool и обновите статус репликации на уровне леса. Ошибки 1908 больше быть не должно. Ошибка, которую вы видите, это ошибка 8606 (недостаточно атрибутов для создания объекта), как отмечалось на экране 10. Это следующая трудность, которую нужно преодолеть.

Устранение ошибки AD Replication Error 8606

Устаревший объект (lingering object) – это объект, который присутствует на DC, но был удален на одном или нескольких других DC. Ошибка репликации AD 8606 и ошибка 1988 в событиях Directory Service – хорошие индикаторы устаревших объектов. Важно учитывать, что можно успешно завершить репликацию AD и не регистрировать ошибку с DC, содержащего устаревшие объекты, поскольку репликация основана на изменениях. Если объекты не изменяются, то реплицировать их не нужно. По этой причине, выполняя очистку устаревших объектов, вы допускаете, что они есть у всех DC (а не только DCs logging errors).

Чтобы устранить проблему, в первую очередь убедитесь в наличии ошибки, выполнив следующую команду Repadmin на DC1:

Repadmin /replicate dc1 dc2 «dc=root,dc=contoso,dc=com»

Вы увидите сообщение об ошибке, как показано на экране 11. Кроме того, вы увидите событие с кодом в Event Viewer DC1 (см. экран 12). Обратите внимание, что событие с кодом 1988 только дает отчет о первом устаревшем объекте, который вам вдруг встретился. Обычно таких объектов много.

Экран 11. Ошибка из-за наличия устаревшего объекта

Экран 12. Событие с кодом 1988

Вы должны скопировать три пункта из информации об ошибке 1988 в событиях: идентификатор globally unique identifier (GUID) устаревшего объекта, сервер-источник (source DC), а также уникальное, или различающееся, имя раздела – distinguished name (DN). Эта информация позволит определить, какой DC имеет данный объект.

Прежде всего, используйте GUID объекта (в данном случае 5ca6ebca-d34c-4f60-b79c-e8bd5af127d8) в следующей команде Repadmin, которая отправляет результаты в файл Objects.txt:

Repadmin /showobjmeta * «e8bd5af127d8>» > Objects.txt

Если вы откроете файл Objects.txt, то увидите, что любой DC, который возвращает метаданные репликации для данного объекта, содержит один или более устаревших объектов. DC, не имеющие копии этого объекта, сообщают статус 8439 (уникальное имя distinguished name, указанное для этой операции репликации, недействительно).

Затем вам нужно, используя GUID объект Directory System Agent (DSA) DC1, идентифицировать все устаревшие объекты в разделе Root на DC2. DSA предоставляет доступ к физическому хранилищу информации каталога, находящейся на жестком диске. В AD DSA – часть процесса Local Security Authority. Для этого выполните команду:

Repadmin /showrepl DC1 > Showrepl.txt

В Showrepl.txt GUID объект DSA DC1 появляется вверху файла и выглядит следующим образом:

DSA object GUID: 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e

Ориентируясь на эту информацию, вы можете применить следующую команду, чтобы удостовериться в существовании устаревших объектов на DC2, сравнив его копию раздела Root с разделом Root DC1.

Repadmin /removelingeringobjects DC2 70ff33ce-2f41-4bf4-
b7ca-7fa71d4ca13e «dc=root,dc=contoso,dc=com»
/Advisory_mode

Далее вы можете просмотреть журнал регистрации событий Directory Service на DC2, чтобы узнать, есть ли еще какие-нибудь устаревшие объекты. Если да, то о каждом будет сообщаться в записи события 1946. Общее число устаревших объектов для проверенного раздела будет отмечено в записи события 1942.

Вы можете удалить устаревшие объекты несколькими способами. Предпочтительно использовать ReplDiag.exe. В качестве альтернативы вы можете выбрать RepAdmin.exe.

Используем ReplDiag.exe. С вашей рабочей станции администратора в корневом домене леса, а в нашем случае это Win8Client, вы должны выполнить следующие команды:

Repldiag /removelingeringobjects
Repadmin /replicate dc1 dc2 «dc=root,dc=contoso,dc=com»

Первая команда удаляет объекты. Вторая команда служит для проверки успешного завершения репликации (иными словами, ошибка 8606 больше не регистрируется). Возвращая команды Repadmin /showobjmeta, вы можете убедиться в том, что объект был удален из всех, что объект был удален DC. Если у вас есть контроллер только для чтения read-only domain controller (RODC) и он содержал данный устаревший объект, вы заметите, что он все еще там находится. Дело в том, что текущая версия ReplDiag.exe не удаляет объекты из RODC. Для очистки RODC (в нашем случае, ChildDC2) выполните команду:

Repadmin /removelingeringobjects childdc2.child.root.
contoso.com 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e
«dc=root,dc=contoso,dc=com» /Advisory_mode

После этого просмотрите журнал событий Directory Service на ChildDC2 и найдите событие с кодом 1939. На экране 13 вы видите уведомление о том, что устаревшие объекты были удалены.

Экран 13. Сообщение об удалении устаревших объектов

Используем RepAdmin.exe. Другой способ, позволяющий удалить устаревшие объекты – прибегнуть к помощи RepAdmin.exe. Сначала вы должны удалить устаревшие объекты главных контроллеров домена (reference DC) с помощью кода, который видите в листинге 1. После этого необходимо удалить устаревшие объекты из всех остальных контроллеров домена (устаревшие объекты могут быть показаны или на них могут обнаружиться ссылки на нескольких контроллерах домена, поэтому убедитесь, что вы удалили их все). Необходимые для этой цели команды приведены в листинге 2.

Как видите, использовать ReplDiag.exe гораздо проще, чем RepAdmin.exe, поскольку вводить команд вам придется намного меньше. Ведь чем больше команд, тем больше шансов сделать опечатку, пропустить команду или допустить ошибку в командной строке.

Устранение ошибки AD Replication Error 8453

Предыдущие ошибки репликации AD были связаны с невозможностью найти другие контроллеры домена. Ошибка репликации AD с кодом состояния 8453 возникает, когда контроллер домена видит другие DC, но не может установить с ними связи репликации.

Например, предположим, что ChildDC2 (RODC) в дочернем домене не уведомляет о себе как о сервере глобального каталога – Global Catalog (GC). Для получения статуса ChildDC2 запустите следующие команды на ChildDC2:

Repadmin /showrepl childdc2 > Repl.txt

Данная команда отправляет результаты Repl.txt. Если вы откроете этот текстовый файл, то увидите вверху следующее:

BoulderChildDC2
DSA Options: IS_GC DISABLE_OUTBOUND_REPL IS_RODC
WARNING: Not advertising as a global catalog

Если вы внимательно посмотрите на раздел Inbound Neighbors, то увидите, что раздел DC=treeroot,DC=fabrikam,DC=com отсутствует, потому что он не реплицируется. Взгляните на кнопку файла – вы увидите ошибку:

Source: BoulderTRDC1
******* 1 CONSECTUTIVE FAILURES since 2014-01-12 11:24:30
Last error: 8453 (0x2105):
Replication access was denied
Naming Context: DC=treeroot,DC=fabrikam,DC=com

Эта ошибка означает, что ChildDC2 не может добавить связь репликации (replication link) для раздела Treeroot. Как показано на экране 14, данная ошибка также записывается в журнал регистрации событий Directory Services на ChildDC2 как событие с кодом 1926.

Экран 14. Отсутствие связи репликации

Здесь вам нужно проверить, нет ли проблем, связанных с безопасностью. Для этого используйте DCDiag.exe:

Dcdiag /test:checksecurityerror

На экране 15 показан фрагмент вывода DCDiag.exe.

Экран 15. Фрагмент вывода DCDiag.exe

Как видите, вы получаете ошибку 8453, потому что группа безопасности Enterprise Read-Only Domain Controllers не имеет разрешения Replicating Directory Changes.

Чтобы решить проблему, вам нужно добавить отсутствующую запись контроля доступа – missing access control entry (ACE) в раздел Treeroot. В этом вам помогут следующие шаги:

1. На TRDC1 откройте оснастку ADSI Edit.

2. Правой кнопкой мыши щелкните DC=treeroot,DC=fabrikam,DC=com и выберите Properties.

3. Выберите вкладку Security.

4. Посмотрите разрешения на этот раздел. Отметьте, что нет записей для группы безопасности Enterprise Read-Only Domain Controllers.

5. Нажмите Add.

6. В окне Enter the object names to select наберите ROOTEnterprise Read-Only Domain Controllers.

7. Нажмите кнопку Check Names, затем выберите OK, если указатель объектов (object picker) разрешает имя.

8. В диалоговом окне Permissions для Enterprise Read-Only Domain Controllers снимите флажки Allow для следующих разрешений

*Read

*Read domain password & lockout policies («Чтение политики блокировки и пароля домена»)

*Read Other domain parameters

9. Выберите флажок Allow для разрешения Replicating Directory Changes, как показано на экране 16. Нажмите OK.

10. Вручную запустите Knowledge Consistency Checker (KCC), чтобы немедленно сделать перерасчет топологии входящей репликации на ChildDC2, выполнив команду

Repadmin /kcc childdc2

Экран 16. Включение разрешения Replicating Directory Change

Данная команда заставляет KCC на каждом целевом сервере DC незамедлительно делать перерасчет топологии входящей репликации, добавляя снова раздел Treeroot.

Состояние репликации критически важно

Репликация во всех отношениях в лесу AD имеет решающее значение. Следует регулярно проводить ее диагностику, чтобы изменения были видны всем контроллерам домена, иначе могут возникать различные проблемы, в том числе связанные с аутентификацией. Проблемы репликации нельзя обнаружить сразу. Поэтому если вы пренебрегаете мониторингом репликации (в крайнем случае, периодически делайте проверку), то рискуете столкнуться с трудностями в самый неподходящий момент. Моей задачей было показать вам, как проверять статус репликации, обнаруживать ошибки и в то же время как справиться с четырьмя типичными проблемами репликации AD.

Листинг 1. Команды для удаления устаревших объектов из Reference DC

REM Команды для удаления устаревших объектов
REM из раздела Configuration.
Repadmin /removelingeringobjects childdc1.child.root.
contoso.com 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e
«cn=configuration,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects childdc1.child.root.
contoso.com 3fe45b7f-e6b1-42b1-bcf4-2561c38cc3a6
«cn=configuration,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects childdc1.child.root.
contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848
«cn=configuration,dc=root,dc=contoso,dc=com»
REM Команды для удаления устаревших объектов
REM из раздела ForestDNSZones.
Repadmin /removelingeringobjects childdc1.child.root.
contoso.com 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e
«dc=forestdnszones,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects childdc1.child.root.
contoso.com 3fe45b7f-e6b1-42b1-bcf4-2561c38cc3a6
«dc=forestdnszones,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects childdc1.child.
root.contoso.com 0b457f73-96a4-429b-ba81-
1a3e0f51c848 «dc=forestdnszones,dc=root,
dc=contoso,dc=com»
REM Команды для удаления устаревших объектов
REM из раздела домена Root.
Repadmin /removelingeringobjects dc1.root.
contoso.com 3fe45b7f-e6b1-42b1-bcf4-2561c38cc3a6
«dc=root,dc=contoso,dc=com»
REM Команды для удаления устаревших объектов
REM из раздела DomainDNSZones.
Repadmin /removelingeringobjects dc1.root.
contoso.com 3fe45b7f-e6b1-42b1-bcf4-2561c38cc3a6
«dc=root,dc=contoso,dc=com»

Листинг 2. Команды для удаления устаревших объектов из остальных DC

REM Команды для удаления устаревших объектов
REM из раздела Configuration.
Repadmin /removelingeringobjects dc1.root.
contoso.com 0c559ee4-0adc-42a7-8668-e34480f9e604
«cn=configuration,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects dc2.root.
contoso.com 0c559ee4-0adc-42a7-8668-e34480f9e604
«cn=configuration,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects childdc2.child.root.
contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848
«cn=configuration,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects trdc1.treeroot.
fabrikam.com 0c559ee4-0adc-42a7-8668-e34480f9e604
«cn=configuration,dc=root,dc=contoso,dc=com»
REM Команды для удаления устаревших объектов
REM из раздела ForestDNSZones.
Repadmin /removelingeringobjects dc1.root.contoso.
com 0c559ee4-0adc-42a7-8668-e34480f9e604
«dc=forestdnszones,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects dc2.root.contoso.
com 0c559ee4-0adc-42a7-8668-e34480f9e604
«dc=forestdnszones,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects childdc2.child.root.
contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848
«dc=forestdnszones,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects trdc1.treeroot.
fabrikam.com 0c559ee4-0adc-42a7-8668-e34480f9e604
«dc=forestdnszones,dc=root,dc=contoso,dc=com»
REM Команды для удаления устаревших объектов
REM из раздела DomainDNSZones–Root.
Repadmin /removelingeringobjects dc2.child.root.
contoso.com 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e
«dc=domaindnszones,dc=root,dc=contoso,dc=com»
REM Команды для удаления устаревших объектов
REM из раздела домена Child.
Repadmin /removelingeringobjects dc1.root.contoso.
com 0c559ee4-0adc-42a7-8668-e34480f9e604
«dc=child,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects dc2.root.contoso.
com 0c559ee4-0adc-42a7-8668-e34480f9e604
«dc=child,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects childdc2.child.root.
contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848
«dc=child,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects trdc1.treeroot.
fabrikam.com 0c559ee4-0adc-42a7-8668-e34480f9e604
«dc=child,dc=root,dc=contoso,dc=com»
REM Команды для удаления устаревших объектов
REM из раздела DomainDNSZones-Child.
Repadmin /removelingeringobjects childdc2.child.root.
contoso.com 0c559ee4-0adc-42a7-8668-e34480f9e604
«dc=domaindnszones,dc=child,dc=root,dc=contoso,dc=com»
REM Команды для удаления устаревших объектов
REM из раздела домена TreeRoot.
Repadmin /removelingeringobjects childdc1.child.root.
contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848
«dc=treeroot,dc=fabrikam,dc=com»
Repadmin /removelingeringobjects childdc2.child.root.
contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848
«dc=treeroot,dc=fabrikam,dc=com»
Repadmin /removelingeringobjects dc1.root.contoso.com
0b457f73-96a4-429b-ba81-1a3e0f51c848
«dc=treeroot,dc=fabrikam,dc=com»
Repadmin /removelingeringobjects dc2.root.contoso.com
0b457f73-96a4-429b-ba81-1a3e0f51c848
«dc=treeroot,dc=fabrikam,dc=com»

Источник

Remove From My Forums

Общие обсуждения
Есть корневой домен AG1, также есть несколько доменов третьего уровня UFA1, BAL1, NOV1. На контроллере домена DCUFA1 появился устаревший объект CN=tulintsev,CN=Users,DC=ufa1,DC=ag1,DC=local. Делал по инструкции по удалению таких объектов:

repadmin /removelingeringobjects <ServerName> <ServerGUID> <DirectoryPartition>

в качестве <ServerName> подставляю DCUFA1, <ServerGUID>
— GUID DCAG1, <DirectoryPartition> — DC=ag1,DC=local.

В итоге получаю :

Repadmin /removelingeringobjects DCUFA1.ufa1.ag1.local ac7f27a0-9470-4e78-a9bf-cb37e5413bd8 «dc=ag1,dc=local»

После получаю сообщение что процедура прошла успешно, но объект не удален. Я так понимаю что ошибка в <DirectoryPartition>, что нужно указывать в этом
параметре?
- Изменен тип
  
  7 марта 2015 г. 11:22
  Тема переведена в разряд обсуждений по причине отсутствия активности

Источник

title	description	ms.date	author	ms.author	manager	audience	ms.topic	ms.prod	localization_priority	ms.reviewer	ms.custom	ms.technology
Troubleshoot replication error 8606	Provides a resolution to an issue where Active Directory replication fails with error 8606.	11/18/2021	Deland-Han	delhan	dcscontentpm	itpro	troubleshooting	windows-server	medium	kaushika	sap:active-directory-replication, csstroubleshoot	windows-server-active-directory

Active Directory Replication Error 8606: Insufficient attributes were given to create an object

This article provides help to troubleshoot Active Directory replication error 8606: Insufficient attributes were given to create an object.

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

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

Summary

This article describes the symptoms and causes of an issue in which Active Directory replication is unsuccessful and generates error 8606: «Insufficient attributes were given to create an object. This object may not exist because it may have been deleted.» This article also describes a resolution for this issue.

Symptoms

Symptom 1

The DCDIAG reports that the Active Directory Replications test failed with error 8606: «Insufficient attributes were given to create an object.»

Starting test: Replications
[Replications Check, <Destination DC>] A recent replication attempt failed:
From <source DC> to <destination DC>
Naming Context: <directory partition DN path>
The replication generated an error (8606):
Insufficient attributes were given to create an object. This object may not exist because it may have been deleted and already garbage collected
The failure occurred at <date> <time>
The last success occurred at <date> <time>

Symptom 2

Incoming replication that is triggered by the Replicate Now command in the Active Directory Sites and Services snap-in DSSITE.MSC is unsuccessful and generates the error «Insufficient attributes were given to create an object.» When you right-click a connection object from a source DC and then select Replicate now, the replication is unsuccessful and generates the following error: «Access is denied.» Additionally, you receive the following error message:

Dialog title text: Replicate Now
Dialog message text: The following error occurred during the attempt to synchronize naming context <%active directory partition name%> from domain controller <source DC> to domain controller <destination DC>:

Insufficient attributes were given to create an object. This object may not exist because it may have been deleted and already garbage collected.

The operation will not continue

Symptom 3

Various REPADMIN.EXE commands fail with error 8606. These commands include but are not limited to the following:

repadmin /add repadmin /replsum
repadmin /showrepl repadmin /showrepl
repadmin /syncall

Symptom 4

Event 1988 is logged shortly after one of the following events occurs:

The first domain controller in the forest is deployed.
Any update to the partial attribute set is made.

Symptom 5

NTDS replication event 1988 may be logged in the Directory Service event log of domain controllers that are trying to inbound-replicate Active Directory.

Type: Error
Source: NTDS Replication
Category: Replication
Event ID: 1988
User: NT AUTHORITYANONYMOUS LOGON
Computer: <hostname of DC that logged event, aka the «destination» DC in the replication attempt>
Description: The local domain controller has attempted to replicate the following object from the following source domain controller. This object is not present on the local domain controller because it may have been deleted and already garbage collected.
Source domain controller:
<fully qualified GUIDED CNAME of source DC>
Object:
<DN path of live object on source DC>
Object GUID:
<object GUID of object on source DCs copy of Active Directory>

Cause

Error 8606 is logged when the following conditions are true:

A source domain controller sends an update to an object (instead of an originating object create) that has already been created, deleted, and then reclaimed by garbage collection from a destination domain controller’s copy of Active Directory.
he destination domain controller was configured to run in strict replication consistency.

If the destination domain controller was configured to use loose replication consistency, the object would have been «reanimated» on the destination domain controller’s copy of the directory. Specific variations that can cause error are 8606 documented in the «More Information» section. However, the error is caused by one of the following:

A permanently lingering object whose removal will require admin intervention
A transient lingering object that will correct itself when the source domain controller performs its next garbage-collection cleanup. The introduction of the first domain controller in an existing forest and updates to the partial attribute set are known causes of this condition.
An object that was undeleted or restored at the cusp of tombstone lifetime expiration

When you troubleshoot 8606 errors, think about the following points:

Although error 8606 is logged on the destination domain controller, the problem object that is blocking replication resides on the source domain controller. Additionally, the source domain controller or a transitive replication partner of the source domain controller potentially did not inbound-replicate knowledge of a deleted tombstone lifetime number of days in the past.
Lingering objects may exist under the following circumstances:
- As «live» objects, as CNF or conflict mangled objects «live» objects, or as CNF or conflict mangled objects in the deleted objects container of the source domain controller
- In any directory partition except the schema partition. Lingering objects are most frequently found in read-only domain partitions on GCs. Lingering objects may also exist in writable domain partitions as well as the configuration partition. The schema partition does not support deletes.
- In any object class (users, computers, groups, and DNS records are most common).
Remember to search for potentially lingering objects by object GUID versus DN path so that objects can be found regardless of their host partition and parent container. Searching by objectguid will also locate objects that are in the deleted objects container without using the deleted objects LDAP control.
The NTDS Replication 1988 event identifies only the current object on the source domain controller that is blocking incoming replication by a strict mode destination domain controller. There are likely additional objects «behind» the object that is referenced in the 1988 event that is also lingering.
The presence of lingering objects on a source domain controller prevents or blocks strict mode destination domain controllers from inbound-replicating «good» changes that exist behind the lingering object in the replication queue.
Because of the way that domain controllers individually delete objects from their deleted object containers (the garbage-collection daemon runs every 12 hours from the last time each domain controller last started), the objects that are causing 8606 errors on destination domain controllers could be subject to removal in the next garbage-collection cleanup execution. Lingering objects in this class are transient and should remove themselves in no more than 12 hours from problem start.
The lingering object in question is likely one that was intentionally deleted by an administrator or application. Factor this into your resolution plan, and beware of reanimating objects, especially security principals that were intentionally deleted. Resolution

Resolution

Identify the current value for the forest-wide TombStoneLifeTime setting.
```
 c:>repadmin /showattr. "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=forest root domain,DC=TLD> /atts:tombstonelifetime  
```
See the «Tombstone lifetime and replication of deletions» section in the following article in the Microsoft Knowledge Base:
910205 Information about lingering objects in a Windows Server Active Directory forest.
For each destination domain controller that is logging the 8606 error, filter the Directory Service event log on NTDS Replication event 1988.
Collect metadata for each unique object that is cited in the NTDS Replication event 1988.
From each 1988 event that is logged on the destination domain controller that cites a new object, populate the following table:

Object DN path Object GUID Source DC Host partition Live or deleted? LastKnownParent IsDeleted value

Columns 1 through 5 of this table can be populated by reading values directly from fields in the NTDS Replication 1988 events that are logged in the Directory Service event logs of the destination domain controllers that are logging either the 1988 event or the 8606 replication status.

The date stamps for LastKnownParent and IsDeleted columns can be determined by running repadmin /showobjmeta and referencing the objectguid of the object that is cited in the NTDS replication 1988 event. To do this, use the following syntax:
```
c:>repadmin /showobjmeta <fqdn of source DC from 1988 event> "<GUID=GUID of object cited in the 1988 event>"
```
The date stamp for LastKnownParent identifies the date on which the object was deleted. The date stamp for IsDeleted tells you when the object was last deleted or reanimated. The version number tells you whether the last modification deleted or reanimated the object. An IsDeleteted value of 1 represents an initial delete. Odd-numbered values greater than 1 indicate a reanimation following at least one deletion. For example, an isDeleted value of 2 represents an object that was deleted (version 1) and then later undeleted or reanimated (version 2). Later even-numbered values for IsDeleted represent later reanimations or undeletes of the object.
Select the appropriate action based on the object metadata cited in the 1988 event.

Error 8606 / NTDS Replication event 1988 event is most frequently caused by long-term replication failures that are preventing domain controllers from inbound-replicating knowledge of all originating deletes in the forest. This results in lingering objects on one or more source domain controllers.

Review the metadata for object that is listed in the table that was created in step 4 of the «Resolution» section.

If the object in the 1988 event is either ((live on the source domain controller) but (deleted on the destination domain controller for longer than tombstone lifetime expiration)), see «Removing Lingering Objects» and «.» Objects in this condition must be manually removed by an administrator.

Deleted objects may have been prematurely purged from the deleted objects container if system time jumped forward in time on the destination domain controller. Review the «Check for Time Jumps» section.

If the object that is cited in the 1988 event exists in the deleted objects container of the source domain controller and its delete date is right at the cusp of tombstone lifetime expiration in such a way that the object was reclaimed by garbage collection by one or more destination domain controllers and will be reclaimed by garbage collection at the next garbage-collection interval on source domain controllers (that is, the lingering objects are transient), you have a choice. Either wait for the next garbage collection execution to delete the object, or manually trigger garbage collection on the source domain controller. See «Manually starting garbage collection.» The introduction of the first domain controller, or any change in the partial attribute set, can cause this condition.

If repadmin /showobjmeta output for the object that is cited in the 1988 event has a LastKnownParent value of 1, this indicates that the object was deleted, and an IsDeleted value that of 2 or some other even-numbered value, and that date stamp for IsDeleted is at the cusp of the tombstone lifetime number of days different from the date stamp for LastKnownParent, then the object was deleted and then undeleted / auth-restored while it was still live on the source domain controller but already reclaimed by garbage collection by destination domain controllers logging error 8606 / Event 1988. See Reanimations at the cusp of TSL expiration

How to remove lingering objects

While many methods exist to remove lingering objects, there are three primary tools commonly used: repadmin.exe, Lingering Object Liquidator (LoL) and repldiag.

Lingering Object Liquidator (LoL)

The easiest method to clean up Lingering Objects is to use the LoL. The LoL tool was developed to help automate the cleanup process against an Active Directory Forest. The tool is GUI-based and can scan the current Active Directory Forest and detect and cleanup lingering objects. The tool is available on Microsoft Download Center.

Repadmin

The following two commands in REPADMIN.EXE can remove lingering objects from directory partitions:

REPADMIN /REMOVELINGERINGOBJECTS
REPADMIN /REHOST

REPADMIN /REMOVELINGERINGOBJCTS can be used to remove lingering objects from writable and read-only directory partitions on source domain controllers. The syntax is as follows:

c:>repadmin /removelingeringobjects <Dest_DSA_LIST> <Source DSA GUID> <NC> [/ADVISORY_MODE]

Where:
<Dest_DSA_LIST> is the name of a domain controller that contains lingering objects (such as the source domain controller that is cited in the NTDS Replication 1988 event).

<Source DSA GUID> is the name of a domain controller that hosts a writable copy of the directory partition that contains lingering objects to which the domain controller in <Dest_DSA_LIST> has network connectivity. The DC to be cleaned up (first DC specified in the command) must be able to connect directly to port 389 on the DC that hosts a writable copy of the directory partition (specified second in the command).

<NC> is the DN path of the directory partition that is suspected of containing lingering objects, such as the partition that is specified in a 1988 event.

REPADMIN /REHOST can be used to remove lingering-objects domain controllers that host a read-only copy of a domain directory partition from domain controllers. The syntax is as follows:

 c:>repadmin /rehost DSA <Naming Context> <Good Source DSA Address>

Where:
DSA is the name of a domain controller that hosts a read-only domain directory partition for a nonlocal domain. For example, a GC in root.contoso.com can rehost its read-only copy of child.contoso.com but cannot rehost root.contoso.com.

<Naming Context> is the DN path of a read-only domain directory partition that is residing in a global catalog.

<Good Source DSA Address> is the name of a domain controller that hosts a writable copy of <Naming Context>. The domain controller must be network-available to the DSA computer.

If the lingering object that is reported in the 1988 event is not removed by repadmin, evaluate whether the object on the source domain controller was created in USN gap, or whether the objects originating domain controller does not exist in the source domain controller’s up-to-dateness vector.

Repldiag

[!NOTE]
Lingering objects can also be removed by using repldiag.exe. This tool automates the repadmin /removelingeringobjects process. Removing lingering objects from a forest with repldiag is as simple as running repldiag /removelingeringobjects. However, it is usually best to exercise some control over the process in larger environments. The option /OverRideReferenceDC allows you to select which DC is used for cleanup. The option /outputrepadmincommandlinesyntax allows you to see what a forest-wide cleanup looks like using repadmin.

Launch the following TechNet on-demand lab for guided troubleshooting practice of this and other AD replication errors:

In the lab, you use both repadmin and repldiag.exe to remove lingering objects
Troubleshooting Active Directory Replication Errors
In this lab, you’ll walk through the troubleshooting, analysis and implementation phases of commonly encountered Active Directory replication errors. You’ll use a combination of ADREPLSTATUS, repadmin.exe, and other tools to troubleshoot a five DC, three-domain environment. AD replication errors encountered in the lab include -2146893022, 1256, 1908, 8453 and 8606.»

Monitoring Active Directory replication health daily

If error 8606 / Event 1988 was caused by the domain controller’s failing to replicate Active Directory changes in the last tombstone lifetime number of days, make sure that Active Directory replication health is being monitored on a day-to-day basis going forward. Replication health may be monitored by using a dedicated monitoring application or by viewing the output from the one inexpensive but effective option to run repadmin /showrepl * /csv command in a spreadsheet application such as Microsoft Excel. (See «Method 2: Monitor replication by using a command line» in Microsoft Knowledge Base article 910205).

Domain controllers that have not inbound-replicated in 50 percent of tombstone lifetime number of days should be put in a watch list that receive priority admin attention to make replication operational. Domain controllers that cannot be made to successfully replicate should be force-demoted if they have not replicated within 90 percent of TSL.

Replication failures that appear on a destination domain controller may be caused by the destination domain controller, by the source domain controller, or by the underlying network and DNS infrastructure.

Check for time jumps

To determine whether a time jump occurred, check date stamps in Event and diagnostic logs (Event Viewer, repadmin /showreps, netlogon logs, dcdiag reports) on destination domain controllers that are logging error 8606 / NTDS Replication 1988 events for the following:

Date stamps that predate the release of an operating system (for example, date stamps from CY 2003 for an OS released in CY 2008)
Date stamps that predate the installation of the operating system in your forest
Date stamps in the future
Having no events that are 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, you should correct it and 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 questions include the following:

Was the forest root PDC configured by using an external time source?
Are reference online time sources available on the network and resolvable in DNS?
Was the Microsoft or third-party time service running and in an error-free state?
Are domain controller role computers configured to use NT5DS hierarchy to source time?
Was time rollback protection that is described in Microsoft Knowledge Base article 884776 in place?
Do system clocks have good batteries and accurate time in the BIOS on domain controllers on virtual host computers?
Are virtual host and guest computers configured to source time according to the hosting manufacturer’s recommendations?
Microsoft Knowledge Base article 884776 documents steps to help protect domain controllers from «listening» to invalid time samples. More information about MaxPosPhaseCorrection and MaxNegPhaseCorrection is available in the W32Time Blog post Windows Time Service.

Check for lingering objects by using repadmin /removelingeringobjects /advisorymode, and then remove them as required.

Relax «Allow replication with Divergent and corrupt partner» as required.

How to manually start garbage collection

Several options exist to manually trigger garbage collection on a specific domain controller:

Run «repadmin /setattr «» «» doGarbageCollection add 1″

Run LDIFDE /s <server> /i /f dogarbage.ldif where dobarbage.ldif contains the text:

dn:
changetype: modify
replace: DoGarbageCollection
dogarbagecollection: 1
—

[!NOTE]
The final «-» character is a required element of the .ldif file.

Reanimations at the cusp of TSL expiration

For this condition to exist, repadmin /showobject "<GUID=object guid for object in 1988 event>" should report that the object is
«not found» on the destination domain controller but is live on the source domain controller and is either a deleted or a nondeleted object.

A review of key fields from repadmin /showobjmeta on the source domain controller should report that the following are true:
LastKnownParent has a value of 1, and its date stamp is at the cusp of TSL days in the past. Its date stamp indicates the delete date of the object.

IsDeleted has a version number of 2 (or another even-numbered value), where version 1 defined the original deletion and version 2 is the restore / reanimation. The date stamp for «isDeleted=2» should be ~ TSL number of days later than the last change date for LastKnownParent.

Evaluate whether the object in question should remain a live object or a deleted object. If LastKnownParent has a value of 1, something or someone deleted the object. If this was not an accidental deletion, chances are good that the object should be deleted from any source domain controllers that have a live copy of the object.

If the object should exist on all replicas, the options are as follows:

Enable loose replication on strict mode destination domain controllers that do not have the object.
Force-demote the domain controllers that have already garbage collected the object.
Delete the object and then re-create it.

More information

Launch the following TechNet on-demand lab for guided troubleshooting practice of this and other AD replication errors:

Troubleshooting Active Directory Replication Errors
In this lab, you will walk through the troubleshooting, analysis, and implementation phases of commonly encountered Active Directory replication errors. You will use a combination of ADREPLSTATUS, repadmin.exe, and other tools to troubleshoot a five DC, three-domain environment. AD replication errors encountered in the lab include -2146893022, 1256, 1908, 8453 and 8606.»

Causes of lingering objects

Cause 1: The source domain controller sends updates to objects that have already been reclaimed by garbage collection on the destination domain controller because the source domain controller either was offline or failed replication for TSL elapsed number of days

The CONTOSO.COM domain contains two domain controllers in the same domain. Tombstone lifetime = 60 days. Strict replication is enabled on both domain controllers. DC2 experiences a motherboard failure. Meanwhile, DC1 makes originating deletes for stale security groups daily over the next 90 days. After it is offline for 90 days, DC2 receives a replacement motherboard, powers up, and then originates a DACL or SACL change on all user accounts before it inbound-replicates knowledge of originating deletes from DC1. DC1 logs 8606 errors for updates security groups that are purged on DC1 for the first 30 days that DC2 was offline.

Cause 2: The source DC sends updates to objects at the cusp of TSL expiration that have already been reclaimed by garbage collection by a strict mode destination DC

The CONTOSO.COM domain contains two domain controllers in the same domain. Tombstone lifetime = 60 days. Strict replication is enabled on both domain controllers. DC1 and DC2 replicate every 24 hours. DC1 originates-deletes daily. DC1 is in-place upgraded. This stamps new attribute on all objects in the configuration and writable domain partitions. This includes objects that are currently in the deleted objects container. Some of them were deleted 60 days ago and are now at the cusp of tombstone expiration. DC2 reclaims some objects by garbage collection that were deleted TSL days ago before the replication schedule opens with DC2. Error 8606 is logged until DC1 reclaims the blocking objects by garbage collection.

Any updates to the partial attribute set can cause temporary lingering objects that will clear themselves up after source domain controllers garbage-collect deleted objects at the cusp of TSL expiration (for example, the addition of the first W2K8 R2 domain controller to an existing forest).

Cause 3: A time jump on a destination domain controller prematurely speeds up the garbage collection of deleted objects on a destination domain controller

The CONTOSO.COM domain contains two domain controllers in the same domain. Tombstone lifetime = 60 days. Strict replication is enabled on both domain controllers. DC1 and DC2 replicate every 24 hours. DC1 originates deletes daily. The reference time source that is used by DC1 (but not DC2) rolls forward to calendar year 2039. This causes DC2 to also use a system time in CY2039. This causes DC1 to prematurely delete objects that are deleted today from its deleted objects container. Meanwhile, DC2 originates changes to attributes on users, computers, and groups that are live on DC2 but deleted and now prematurely garbage collected on DC1. DC1 will log error 8606 when it next inbound-replicates changes for the premature deleted objects.

Cause 4: An object is reanimated at the cusp of TSL expiration

The CONTOSO.COM domain contains two domain controllers in the same domain. Tombstone lifetime = 60 days. Strict replication is enabled on both domain controllers. DC1 and DC2 replicate every 24 hours. DC1 originates deletes daily. An OU that contains users, computers, and groups are accidentally deleted. A system state backup that is made at the cusp of TSL in the past is auth-restored on DC2. The backup contains objects that are live on DC2 but already deleted and reclaimed by garbage collection on DC1.

Cause 5: A USN bubble is triggered the logging of the 8606

Say that you create an object in a USN bubble in such a way that it does not outbound-replicate because the destination domain controller «thinks» it has the object because of the bubble. Now, after the bubble closes, and after changes start to replicate again, a change is created for that object on the source domain controller and is displayed as a lingering object to the destination domain controller. The destination controller logs event 8606.

Requirements for end-to-end replicate knowledge of originating deletes

Active Directory domain controllers support multi-master replication where any domain controller (that holds a writable partition) can originate a create, change, or delete of an object or attribute (value). Knowledge of object / attribute deletes are persisted by the originating domain controller and any domain controller that has incoming replicated knowledge of an originating delete for TSL number of days. (See Microsoft Knowledge Base articles 216996 and 910205)

Active Directory requires end-to-end replication from all partition holders to transitively replicate all originating deletes for all 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 was intentionally deleted by at least one domain controller but that incorrectly exists on destination domain controllers that did not inbound-replicate the transient knowledge of all unique deletions.

Источник

title	description	ms.date	author	ms.author	manager	audience	ms.topic	ms.prod	localization_priority	ms.reviewer	ms.custom	ms.technology
Troubleshoot replication error 8606	Provides a resolution to an issue where Active Directory replication fails with error 8606.	11/18/2021	Deland-Han	delhan	dcscontentpm	itpro	troubleshooting	windows-server	medium	kaushika	sap:active-directory-replication, csstroubleshoot	windows-server-active-directory

Active Directory Replication Error 8606: Insufficient attributes were given to create an object

This article provides help to troubleshoot Active Directory replication error 8606: Insufficient attributes were given to create an object.

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

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

Summary

Symptoms

Symptom 1

The DCDIAG reports that the Active Directory Replications test failed with error 8606: «Insufficient attributes were given to create an object.»

Starting test: Replications
[Replications Check, <Destination DC>] A recent replication attempt failed:
From <source DC> to <destination DC>
Naming Context: <directory partition DN path>
The replication generated an error (8606):
Insufficient attributes were given to create an object. This object may not exist because it may have been deleted and already garbage collected
The failure occurred at <date> <time>
The last success occurred at <date> <time>

Symptom 2

Dialog title text: Replicate Now
Dialog message text: The following error occurred during the attempt to synchronize naming context <%active directory partition name%> from domain controller <source DC> to domain controller <destination DC>:

Insufficient attributes were given to create an object. This object may not exist because it may have been deleted and already garbage collected.

The operation will not continue

Symptom 3

Various REPADMIN.EXE commands fail with error 8606. These commands include but are not limited to the following:

repadmin /add repadmin /replsum
repadmin /showrepl repadmin /showrepl
repadmin /syncall

Symptom 4

Event 1988 is logged shortly after one of the following events occurs:

The first domain controller in the forest is deployed.
Any update to the partial attribute set is made.

Symptom 5

NTDS replication event 1988 may be logged in the Directory Service event log of domain controllers that are trying to inbound-replicate Active Directory.

Type: Error
Source: NTDS Replication
Category: Replication
Event ID: 1988
User: NT AUTHORITYANONYMOUS LOGON
Computer: <hostname of DC that logged event, aka the «destination» DC in the replication attempt>
Description: The local domain controller has attempted to replicate the following object from the following source domain controller. This object is not present on the local domain controller because it may have been deleted and already garbage collected.
Source domain controller:
<fully qualified GUIDED CNAME of source DC>
Object:
<DN path of live object on source DC>
Object GUID:
<object GUID of object on source DCs copy of Active Directory>

Cause

Error 8606 is logged when the following conditions are true:

A source domain controller sends an update to an object (instead of an originating object create) that has already been created, deleted, and then reclaimed by garbage collection from a destination domain controller’s copy of Active Directory.
he destination domain controller was configured to run in strict replication consistency.

A permanently lingering object whose removal will require admin intervention
A transient lingering object that will correct itself when the source domain controller performs its next garbage-collection cleanup. The introduction of the first domain controller in an existing forest and updates to the partial attribute set are known causes of this condition.
An object that was undeleted or restored at the cusp of tombstone lifetime expiration

When you troubleshoot 8606 errors, think about the following points:

Although error 8606 is logged on the destination domain controller, the problem object that is blocking replication resides on the source domain controller. Additionally, the source domain controller or a transitive replication partner of the source domain controller potentially did not inbound-replicate knowledge of a deleted tombstone lifetime number of days in the past.
Lingering objects may exist under the following circumstances:
- As «live» objects, as CNF or conflict mangled objects «live» objects, or as CNF or conflict mangled objects in the deleted objects container of the source domain controller
- In any directory partition except the schema partition. Lingering objects are most frequently found in read-only domain partitions on GCs. Lingering objects may also exist in writable domain partitions as well as the configuration partition. The schema partition does not support deletes.
- In any object class (users, computers, groups, and DNS records are most common).
Remember to search for potentially lingering objects by object GUID versus DN path so that objects can be found regardless of their host partition and parent container. Searching by objectguid will also locate objects that are in the deleted objects container without using the deleted objects LDAP control.
The NTDS Replication 1988 event identifies only the current object on the source domain controller that is blocking incoming replication by a strict mode destination domain controller. There are likely additional objects «behind» the object that is referenced in the 1988 event that is also lingering.
The presence of lingering objects on a source domain controller prevents or blocks strict mode destination domain controllers from inbound-replicating «good» changes that exist behind the lingering object in the replication queue.
Because of the way that domain controllers individually delete objects from their deleted object containers (the garbage-collection daemon runs every 12 hours from the last time each domain controller last started), the objects that are causing 8606 errors on destination domain controllers could be subject to removal in the next garbage-collection cleanup execution. Lingering objects in this class are transient and should remove themselves in no more than 12 hours from problem start.
The lingering object in question is likely one that was intentionally deleted by an administrator or application. Factor this into your resolution plan, and beware of reanimating objects, especially security principals that were intentionally deleted. Resolution

Resolution

Identify the current value for the forest-wide TombStoneLifeTime setting.
```
 c:>repadmin /showattr. "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=forest root domain,DC=TLD> /atts:tombstonelifetime  
```
See the «Tombstone lifetime and replication of deletions» section in the following article in the Microsoft Knowledge Base:
910205 Information about lingering objects in a Windows Server Active Directory forest.
For each destination domain controller that is logging the 8606 error, filter the Directory Service event log on NTDS Replication event 1988.
Collect metadata for each unique object that is cited in the NTDS Replication event 1988.
From each 1988 event that is logged on the destination domain controller that cites a new object, populate the following table:

Object DN path Object GUID Source DC Host partition Live or deleted? LastKnownParent IsDeleted value

Columns 1 through 5 of this table can be populated by reading values directly from fields in the NTDS Replication 1988 events that are logged in the Directory Service event logs of the destination domain controllers that are logging either the 1988 event or the 8606 replication status.

The date stamps for LastKnownParent and IsDeleted columns can be determined by running repadmin /showobjmeta and referencing the objectguid of the object that is cited in the NTDS replication 1988 event. To do this, use the following syntax:
```
c:>repadmin /showobjmeta <fqdn of source DC from 1988 event> "<GUID=GUID of object cited in the 1988 event>"
```
The date stamp for LastKnownParent identifies the date on which the object was deleted. The date stamp for IsDeleted tells you when the object was last deleted or reanimated. The version number tells you whether the last modification deleted or reanimated the object. An IsDeleteted value of 1 represents an initial delete. Odd-numbered values greater than 1 indicate a reanimation following at least one deletion. For example, an isDeleted value of 2 represents an object that was deleted (version 1) and then later undeleted or reanimated (version 2). Later even-numbered values for IsDeleted represent later reanimations or undeletes of the object.
Select the appropriate action based on the object metadata cited in the 1988 event.

Error 8606 / NTDS Replication event 1988 event is most frequently caused by long-term replication failures that are preventing domain controllers from inbound-replicating knowledge of all originating deletes in the forest. This results in lingering objects on one or more source domain controllers.

Review the metadata for object that is listed in the table that was created in step 4 of the «Resolution» section.

If the object in the 1988 event is either ((live on the source domain controller) but (deleted on the destination domain controller for longer than tombstone lifetime expiration)), see «Removing Lingering Objects» and «.» Objects in this condition must be manually removed by an administrator.

Deleted objects may have been prematurely purged from the deleted objects container if system time jumped forward in time on the destination domain controller. Review the «Check for Time Jumps» section.

If the object that is cited in the 1988 event exists in the deleted objects container of the source domain controller and its delete date is right at the cusp of tombstone lifetime expiration in such a way that the object was reclaimed by garbage collection by one or more destination domain controllers and will be reclaimed by garbage collection at the next garbage-collection interval on source domain controllers (that is, the lingering objects are transient), you have a choice. Either wait for the next garbage collection execution to delete the object, or manually trigger garbage collection on the source domain controller. See «Manually starting garbage collection.» The introduction of the first domain controller, or any change in the partial attribute set, can cause this condition.

If repadmin /showobjmeta output for the object that is cited in the 1988 event has a LastKnownParent value of 1, this indicates that the object was deleted, and an IsDeleted value that of 2 or some other even-numbered value, and that date stamp for IsDeleted is at the cusp of the tombstone lifetime number of days different from the date stamp for LastKnownParent, then the object was deleted and then undeleted / auth-restored while it was still live on the source domain controller but already reclaimed by garbage collection by destination domain controllers logging error 8606 / Event 1988. See Reanimations at the cusp of TSL expiration

How to remove lingering objects

While many methods exist to remove lingering objects, there are three primary tools commonly used: repadmin.exe, Lingering Object Liquidator (LoL) and repldiag.

Lingering Object Liquidator (LoL)

Repadmin

The following two commands in REPADMIN.EXE can remove lingering objects from directory partitions:

REPADMIN /REMOVELINGERINGOBJECTS
REPADMIN /REHOST

REPADMIN /REMOVELINGERINGOBJCTS can be used to remove lingering objects from writable and read-only directory partitions on source domain controllers. The syntax is as follows:

c:>repadmin /removelingeringobjects <Dest_DSA_LIST> <Source DSA GUID> <NC> [/ADVISORY_MODE]

Where:
<Dest_DSA_LIST> is the name of a domain controller that contains lingering objects (such as the source domain controller that is cited in the NTDS Replication 1988 event).

<NC> is the DN path of the directory partition that is suspected of containing lingering objects, such as the partition that is specified in a 1988 event.

REPADMIN /REHOST can be used to remove lingering-objects domain controllers that host a read-only copy of a domain directory partition from domain controllers. The syntax is as follows:

 c:>repadmin /rehost DSA <Naming Context> <Good Source DSA Address>

<Naming Context> is the DN path of a read-only domain directory partition that is residing in a global catalog.

<Good Source DSA Address> is the name of a domain controller that hosts a writable copy of <Naming Context>. The domain controller must be network-available to the DSA computer.

Repldiag

[!NOTE]
Lingering objects can also be removed by using repldiag.exe. This tool automates the repadmin /removelingeringobjects process. Removing lingering objects from a forest with repldiag is as simple as running repldiag /removelingeringobjects. However, it is usually best to exercise some control over the process in larger environments. The option /OverRideReferenceDC allows you to select which DC is used for cleanup. The option /outputrepadmincommandlinesyntax allows you to see what a forest-wide cleanup looks like using repadmin.

Launch the following TechNet on-demand lab for guided troubleshooting practice of this and other AD replication errors:

Monitoring Active Directory replication health daily

Check for time jumps

Date stamps that predate the release of an operating system (for example, date stamps from CY 2003 for an OS released in CY 2008)
Date stamps that predate the installation of the operating system in your forest
Date stamps in the future
Having no events that are logged in a given date range

Was the forest root PDC configured by using an external time source?
Are reference online time sources available on the network and resolvable in DNS?
Was the Microsoft or third-party time service running and in an error-free state?
Are domain controller role computers configured to use NT5DS hierarchy to source time?
Was time rollback protection that is described in Microsoft Knowledge Base article 884776 in place?
Do system clocks have good batteries and accurate time in the BIOS on domain controllers on virtual host computers?
Are virtual host and guest computers configured to source time according to the hosting manufacturer’s recommendations?
Microsoft Knowledge Base article 884776 documents steps to help protect domain controllers from «listening» to invalid time samples. More information about MaxPosPhaseCorrection and MaxNegPhaseCorrection is available in the W32Time Blog post Windows Time Service.

Check for lingering objects by using repadmin /removelingeringobjects /advisorymode, and then remove them as required.

Relax «Allow replication with Divergent and corrupt partner» as required.

How to manually start garbage collection

Several options exist to manually trigger garbage collection on a specific domain controller:

Run «repadmin /setattr «» «» doGarbageCollection add 1″

Run LDIFDE /s <server> /i /f dogarbage.ldif where dobarbage.ldif contains the text:

dn:
changetype: modify
replace: DoGarbageCollection
dogarbagecollection: 1
—

[!NOTE]
The final «-» character is a required element of the .ldif file.

Reanimations at the cusp of TSL expiration

If the object should exist on all replicas, the options are as follows:

Enable loose replication on strict mode destination domain controllers that do not have the object.
Force-demote the domain controllers that have already garbage collected the object.
Delete the object and then re-create it.

More information

Launch the following TechNet on-demand lab for guided troubleshooting practice of this and other AD replication errors:

Troubleshooting Active Directory Replication Errors
In this lab, you will walk through the troubleshooting, analysis, and implementation phases of commonly encountered Active Directory replication errors. You will use a combination of ADREPLSTATUS, repadmin.exe, and other tools to troubleshoot a five DC, three-domain environment. AD replication errors encountered in the lab include -2146893022, 1256, 1908, 8453 and 8606.»

Causes of lingering objects

Cause 1: The source domain controller sends updates to objects that have already been reclaimed by garbage collection on the destination domain controller because the source domain controller either was offline or failed replication for TSL elapsed number of days

Cause 2: The source DC sends updates to objects at the cusp of TSL expiration that have already been reclaimed by garbage collection by a strict mode destination DC

Cause 3: A time jump on a destination domain controller prematurely speeds up the garbage collection of deleted objects on a destination domain controller

The CONTOSO.COM domain contains two domain controllers in the same domain. Tombstone lifetime = 60 days. Strict replication is enabled on both domain controllers. DC1 and DC2 replicate every 24 hours. DC1 originates deletes daily. The reference time source that is used by DC1 (but not DC2) rolls forward to calendar year 2039. This causes DC2 to also use a system time in CY2039. This causes DC1 to prematurely delete objects that are deleted today from its deleted objects container. Meanwhile, DC2 originates changes to attributes on users, computers, and groups that are live on DC2 but deleted and now prematurely garbage collected on DC1. DC1 will log error 8606 when it next inbound-replicates changes for the premature deleted objects.

Cause 4: An object is reanimated at the cusp of TSL expiration

The CONTOSO.COM domain contains two domain controllers in the same domain. Tombstone lifetime = 60 days. Strict replication is enabled on both domain controllers. DC1 and DC2 replicate every 24 hours. DC1 originates deletes daily. An OU that contains users, computers, and groups are accidentally deleted. A system state backup that is made at the cusp of TSL in the past is auth-restored on DC2. The backup contains objects that are live on DC2 but already deleted and reclaimed by garbage collection on DC1.

Cause 5: A USN bubble is triggered the logging of the 8606

Requirements for end-to-end replicate knowledge of originating deletes

Источник

Ошибка обнаружилась, когда в удаленных контроллерах доменов перестали появляться объекты, созданные в корневом. При проверке репликации командой:

repadmin /showrepl

на корневом контроллере домена данные говорят, что ошибки как бы и нет, но это не так и мы это знаем. Проверяем репликацию всех контроллеров Active Directory Replication Status Tool и видим следующую картину:

Из неё следует что основная ошибка репликации 8606, как ее исправить?

Для начала собираем свод данных по репликации командой:
repadmin /replsummary
И видим следующие:

Из чего следует что у нас ошибка репликации только между S-DC-01 и S-DC-02. Далее заходим на обо этих сервера и запускаем regedit и переходим в
HKLMSYSTEMCurrentControlSetServicesNTDSParameters
И меняем значение Strict Replication Consistency с 1 на 0

И запускаем репликацию вручную (консоль запускать из-под Администратора):

repadmin /syncall

После завершения проверяем статус репликации:
repadmin /showrepl

Видим что ошибок нет. Заходим в Active Directory Replication Status Tool и запускаем проверку, и тут ошибок нет.

Опять заходим на S-DC-01 и S-DC-02 и возвращаем значение параметра Strict Replication Consistency с 0 на 1.
Всё.

Источник

Okay, I’m not sure if I fixed the problem or just temporarily got rid of it and it will appear again. After running the command
dcdiag /c /v provided by Gary D Williams, I noticed that one particular machine kept being called out as having a problem. I also noticed this line «If you need Active Directory Domain Services replication to function immediately at all costs and don’t have time to remove lingering objects, enable loose replication consistency by unsetting the following registry key». I wasn’t getting anywhere tracking down the «lingering object» so I temporarily removed the Strict Replication Consistency key in the registry, ran the Replicate Now option in ADSS and added the key back to the registry. I am now showing what is in the picture below, no failures. I’ll keep an eye on it to make sure it doesn’t pop up again. Image: post content

1 found this helpful
thumb_up
thumb_down

Источник

Remove From My Forums

Question
Error: 8606, Insufficient attributes were given to create an object. This object may not exist because it may have been deleted and already garbage collected.

Answers

Gautam Ji,

One more suggestion: please run the following setp by step procedure in the link below to determine if there are any Duplicate AD Integrated Zones in the AD database. You must check the following in ADSI Edit:
- The ForestDnsZones partition
- The DomainDnsZones partition of each domain
- The DomainNC partition of each domain
.

Using ADSI Edit to Resolve Conflicting or Duplicate AD Integrated DNS zones

Published by acefekay on Sep 2, 2009 at 2:34 PM 7748 2
http://msmvps.com/blogs/acefekay/archive/2009/09/02/using-adsi-edit-to-resolve-conflicting-or-duplicate-ad-integrated-dns-zones.aspx

.

.

Please also describe the way the parent-child DNS resolution is setup:
- Is it a Parent-Child DNS Delegation? (This means the stan.org zone is only replicated to the stan.org DCs, and each child zone is only replicated between DCs in their own domain, and there is a forwarder from all DNS servers in each child domain back to
  the parent domain’s DNS servers.)
OR
- Is the stan.org zone replicated forest-wide? (This means that the stand.org zone is replicated to all DCs in the whole forest, and all child zones appear as child sub-folders under the stan.org zone.)
.

To get a better idea of what I am referring to, please see the DNS Design options available to insure forest wide DNS resolution in a multi-domain environment:

DNS Design Options in a Multi-Domain Forest — How to create a Parent-Child DNS Delegation, and How to Configure DNS to create a new Tree in the Forest
Published by Ace Fekay, MCT, MVP DS on Oct 1, 2010 at 12:22 PM
http://msmvps.com/blogs/acefekay/archive/2010/10/01/dns-parent-child-dns-delegation-how-to-create-a-dns-delegation.aspx

.

.

One more thing, how are the AD Sites setup?
- Are they in a mesh, where all AD sites are replicating with all other AD Sites? In this design, the physical network must provide complete mesh communications, meaning that all sites can directly ping and ommunicate with each other unobstructed
  by any firewalls or route issues.
OR
- Are they in a Hub and Spoke design? This design requires individual IP links created and only the Hub site and the respective remote site are in the IP Site link. This design is normally chosen when the physical network does not or is not
  allowed communication between each site and only between a remote location and the Hub site. In this design, you would also disable AutoSiteLinkBridging.
.

The reason I am asking this is because I’ve seen AD Site designs that were not designed properly based on network communications limitations, cause lingering object issues, which are one of the issues that one will see. Others, including this, are:
- Possible AD duplicate zones
- Lingering objects
- Failed DC replication to the point they haven’t replicated beyond the AD Tombstone limit (which will require forceremoval of those DCs)
Ace Fekay
MVP, MCT, MCITP EA, MCTS Windows 2008/R2, Exchange 2007 & Exchange 2010, Exchange 2010 EA, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP — Directory Services
Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

This post is provided AS-IS with no warranties or guarantees and confers no rights.
- Edited by
  
  Monday, July 30, 2012 3:59 AM
- Proposed as answer by
  Sandesh Dubey
  Monday, July 30, 2012 6:07 AM
- Marked as answer by
  Cicely Feng
  Wednesday, August 1, 2012 6:33 AM
On which I am getting the Event ID .. Means destination DC

No, not that DC.

The DC showing the event is telling you the one that has the lingering object that you have to run /removelingeringobject. The DC with the problem is the GUID in the event error:

Source domain controller:

<snipped>

and this is the object in question:

Object:

<snipped>

Object
GUID:
<snipped>

.

Ace Fekay
MVP, MCT, MCITP EA, MCTS Windows 2008/R2, Exchange 2007 & Exchange 2010, Exchange 2010 EA, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP — Directory Services
Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

This post is provided AS-IS with no warranties or guarantees and confers no rights.
- Marked as answer by
  Cicely Feng
  Wednesday, August 1, 2012 6:34 AM
- Edited by
  Ace Fekay [MCT]
  Saturday, August 11, 2012 3:56 PM
  — edited uto remove private data pon request

Источник

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

Исправление ошибки AD Replication Error -2146893022

Обнаружение и устранение ошибки AD Replication Error 1908

Устранение ошибки AD Replication Error 8606

Устранение ошибки AD Replication Error 8453

Состояние репликации критически важно

Общие обсуждения

Active Directory Replication Error 8606: Insufficient attributes were given to create an object

Summary

Symptoms

Symptom 1

Symptom 2

Symptom 3

Symptom 4

Symptom 5

Cause

Resolution

How to remove lingering objects

Lingering Object Liquidator (LoL)

Repadmin

Repldiag

Monitoring Active Directory replication health daily

Check for time jumps

How to manually start garbage collection

Reanimations at the cusp of TSL expiration

More information

Causes of lingering objects

Cause 1: The source domain controller sends updates to objects that have already been reclaimed by garbage collection on the destination domain controller because the source domain controller either was offline or failed replication for TSL elapsed number of days

Cause 2: The source DC sends updates to objects at the cusp of TSL expiration that have already been reclaimed by garbage collection by a strict mode destination DC

Cause 3: A time jump on a destination domain controller prematurely speeds up the garbage collection of deleted objects on a destination domain controller

Cause 4: An object is reanimated at the cusp of TSL expiration

Cause 5: A USN bubble is triggered the logging of the 8606

Requirements for end-to-end replicate knowledge of originating deletes

Active Directory Replication Error 8606: Insufficient attributes were given to create an object

Summary

Symptoms

Symptom 1

Symptom 2

Symptom 3

Symptom 4

Symptom 5

Cause

Resolution

How to remove lingering objects

Lingering Object Liquidator (LoL)

Repadmin

Repldiag

Monitoring Active Directory replication health daily

Check for time jumps

How to manually start garbage collection

Reanimations at the cusp of TSL expiration

More information

Causes of lingering objects

Cause 1: The source domain controller sends updates to objects that have already been reclaimed by garbage collection on the destination domain controller because the source domain controller either was offline or failed replication for TSL elapsed number of days

Cause 2: The source DC sends updates to objects at the cusp of TSL expiration that have already been reclaimed by garbage collection by a strict mode destination DC

Cause 3: A time jump on a destination domain controller prematurely speeds up the garbage collection of deleted objects on a destination domain controller

Cause 4: An object is reanimated at the cusp of TSL expiration

Cause 5: A USN bubble is triggered the logging of the 8606

Requirements for end-to-end replicate knowledge of originating deletes

Question

Answers

А вот еще интересные материалы: