ID 2042 при репликации Active Directory, решаем за минуту

Ative Directory

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов в рунете Pyatilistnik.org. В прошлый раз мы с вами разобрали методы оплаты телефона Билайн. В сегодняшней же публикации я хочу вам вновь показать практику траблшутинга активного каталога, и мы разберем очень частую ошибку репликации ID 2042, которую вы можете лицезреть в своем Active Directory, сразу скажу, что она не смертельная и решается весьма просто и без лишних телодвижений.

Описание проблемы вызывающей ошибку ID 2042

И так у меня есть установленные Active Directory на базе Windows Server 2019, который работает в виде виртуальных машин на гипервизоре ESXI 6.5. Была проблема с репликацией между двумя сайтами AD, где было установлено, что один из контроллеров домена не получал репликацию более 50 дней, там об этом сигнализировала ошибка "SyncAll exited with fatal Win32 error: 8440 (0x20f8)", которую мы успешно устранили. Как только пробежали все реплики, мы успокоились, но на следующий день у нас массово в логах Windows стали появляться события с кодом ID 2042:

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 DCs may contain lingering objects. Objects that have been deleted and garbage collected from an Active Directory Domain Services partition but still exist in the writable partitions of other DCs in the same domain, or read-only partitions of global catalog servers in other domains in the forest are known as "lingering objects". If the local destination DC was allowed to replicate with the source DC, these potential lingering object would be recreated in the local Active Directory Domain Services database.

Time of last successful replication:
2020-09-08 14:47:05
Invocation ID of source directory server:
f96c8e1b-f760-4e75-b2b2-ec464646d663
Name of source directory server:
d06896a3-be4b-4b8a-b75f-e524564526a0f._msdcs.root.pyatilistnik.org
Tombstone lifetime (days): 60

The replication operation has failed.

User Action:
The action plan to recover from this error can be found at http://support.microsoft.com/?id=314282.

If both the source and destination DCs are Windows Server 2003 DCs, then install the support tools included on the installation CD. To see which objects would be deleted without actually performing the deletion run "repadmin /removelingeringobjects <Source DC> <Destination DC DSA GUID> <NC> /ADVISORY_MODE". The event logs on the source DC will enumerate all lingering objects. To remove lingering objects from a source domain controller run "repadmin /removelingeringobjects <Source DC> <Destination DC DSA GUID> <NC>".

If either source or destination DC is a Windows 2000 Server DC, then more information on how to remove lingering objects on the source DC can be found at http://support.microsoft.com/?id=314282 or from your Microsoft support personnel.

If you need Active Directory Domain Services replication to function immediately at all costs and don't have time to remove lingering objects, enable replication by setting the following registry key to a non-zero value:

Registry Key:
HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Allow Replication With Divergent and Corrupt Partner

Replication errors between DCs sharing a common partition can prevent user and computer accounts, trust relationships, their passwords, security groups, security group memberships and other Active Directory Domain Services configuration data to vary between DCs, affecting the ability to log on, find objects of interest and perform other critical operations. These inconsistencies are resolved once replication errors are resolved. DCs that fail to inbound replicate deleted objects within tombstone lifetime number of days will remain inconsistent until lingering objects are manually removed by an administrator from each local DC. Additionally, replication may continue to be blocked after this registry key is set, depending on whether lingering objects are located immediately.

Alternate User Action:

Force demote or reinstall the DC(s) that were disconnected.

ID 2042 for Active Directory replication

Я выделил тут участок Tombstone lifetime (days): 60, именно это является ключевым вопросом. Так как у вас сбойный контроллер не принимал реплики более 60 дней, то ваш Active Directory просто перестраховывается, чтобы ничего не наломать, есть там такой защитный механизм, называется принудительный запрет репликации.

Событие 2042 - событие указывает на то, что включена строгая репликация, исходный контроллер домена не реплицировался в в период tombstone и пытается реплицировать, поэтому репликация отключена из источника. Событие предоставляет GUID источника в формате записи DNS CName:982a942e-40e4-4e3c-8609-bae0cfd2affb._msdcs.pyatilistnik.org. Понятное имя контроллера домена можно легко найти, просмотрев записи псевдонимов в зоне _msdcs в оснастке DNS.

Как устранить ошибку ID 2042

Первое, что вам необходимо сделать, это вычислить имя контроллера домена с которого у вас не идет репликация на сбойный, это можно сделать несколькими методами. В тексте ошибки есть GUID контроллера домена, выглядит он приблизительно вот так 5fc9cc16-b994-426d-81c8-c9ff27f29976._msdcs.root.pyatilistnik.org. Понятно, что для нас он не читаем. Откройте командную строку и введите команду PING.

ping 5fc9cc16-b994-426d-81c8-c9ff27f29976._msdcs.root.pyatilistnik.org

На выходе вы получите точное имя контроллера домена.

Как узнать GUID контроллера домена

Либо через оснастку DNS в разделе _msdcs.root, где вы увидите псевдонимы CNAME в виде привычных имен контроллеров домена.

ID 2042 при репликации Active Directory

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

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\NTDS\Parameters

Найдите там ключ "Allow Replication With Divergent and Corrupt Partner", по умолчанию он имеет значение "0". Поменяйте его на единицу "1". Перезагружать ничего не нужно, все применится сразу.

Allow Replication With Divergent and Corrupt Partner

Повторите эти действия на тех контролерах домена, на которых наблюдается ошибка 2042. После этого в командной строке вам нужно воспользоваться утилитой Repadmin.

repadmin /syncall

После того, как ошибка репликации ID 2042 исчезнет, вам необходимо ключу "Allow Replication With Divergent and Corrupt Partner" вернуть значение "0". Если не хотите возиться с реестром или вы боитесь это делать на контроллере домена, то можно через команду для определенного контроллера снять повышенные ограничения при репликации. Для этого в командной строке в режиме администратора вам нужно выполнить команды:

repadmin /regkey <hostname> -allowDivergent

  • /regkey - (+) Включает и отключает значение записи реестра Строгую согласованность репликации в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\ Parameters(-)
  • <hostname> - Имя контроллера домена с которого будет реплицироваться дельта, можно вообще поставить значок звездочки "*", чтобы разрешить репликацию со всех контроллеров домена.
  • +allowDivergent/-allowDivergent - Позволяет начать новую репликацию с партнером, убедитесь, что у вас удалены все устаревшие объекты (По поводу устаревших объектов можно почитать вот тут https://support.microsoft.com/ru-ru/help/4469622/active-directory-replication-event-id-2042-it-has-been-too-long-since и советую почитать про дублированные имена и ID 11)

repadmin /regkey dc2.root.pyatilistnik.org -allowDivergent

Для dc2.root.pyatilistnik.org будет установлен Allow Replication With Divergent and Corrupt Partner со значением "0". На этом у меня все, с вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.

Оцените статью
Настройка серверов windows и linux
Добавить комментарий

  1. Михаил

    Спасибо

  2. Иван Семин автор

    Добрый день! Рад, что смог помочь!

  3. Алексей П.

    Мне до сих пор не понятно, почему Microsoft не сделает это все на автоматическом режиме и без костылей.

  4. Игорь

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

  5. Дмитрий

    А repadmin/syncall то-же на сбойном dc запускать или на pdc?