Диагностика сервера каталогов
Выполнение начальной настройки:
Основной сервер = MSK-DC16
* Определен лес AD.
Сбор начальных данных завершен.
Выполнение обязательных начальных проверок
Сервер проверки: SITEMSK-DC16
Запуск проверки: Connectivity
Выполнение основных проверок
Сервер проверки: MaslovkaMSK-DC16
Запуск проверки: Advertising
Запуск проверки: FrsEvent
Запуск проверки: DFSREvent
За последние 24 часа после предоставления SYSVOL в общий доступ
зафиксированы предупреждения или сообщения об ошибках. Сбои при
Запуск проверки: SysVolCheck
Запуск проверки: KccEvent
Запуск проверки: KnowsOfRoleHolders
Запуск проверки: MachineAccount
Запуск проверки: NCSecDesc
Запуск проверки: NetLogons
выполнение данной операции.
Учетная запись, используемая для этой проверки, должна иметь права на
вход в сеть
для домена данного компьютера.
Запуск проверки: ObjectsReplicated
Запуск проверки: Replications
DsReplicaGetInfo(PENDING_OPS, NULL), ошибка 0x2105
«Доступ к репликации отвергнут.»
Запуск проверки: RidManager
Запуск проверки: Services
Не удалось открыть службу NTDS в MSK-DC16, ошибка 0x5
«Отказано в доступе.»
Запуск проверки: SystemLog
Запуск проверки: VerifyReferences
Выполнение проверок разделов на: ForestDnsZones
Запуск проверки: CheckSDRefDom
Запуск проверки: CrossRefValidation
Выполнение проверок разделов на: DomainDnsZones
Выполнение проверок разделов на: Schema
Выполнение проверок разделов на: Configuration
Выполнение проверок разделов на: DOMEN
Выполнение проверок предприятия на: DOMEN.local
Запуск проверки: LocatorCheck
Запуск проверки: Intersite
Один из механизмов Active Directory (AD), с которым могут быть связаны всевозможные затруднения, это репликация. Репликация – критически важный процесс в работе одного или более доменов или контроллеров домена (DC), и не важно, находятся они на одном сайте или на разных. Неполадки с репликацией могут привести к проблемам с аутентификацией и доступом к сетевым ресурсам. Обновления объектов AD реплицируются на контроллеры домена, чтобы все разделы были синхронизированы. В крупных компаниях использование большого количества доменов и сайтов – обычное дело. Репликация должна происходить внутри локального сайта, так же как дополнительные сайты должны сохранять данные домена и леса между всеми DC.
В этой статье речь пойдет о методах выявления проблем с репликацией в AD. Кроме того, я покажу, как находить и устранять неисправности и работать с четырьмя наиболее распространенными ошибками репликации AD:
- Error 1908 (не удалось найти контроллер домена);
- Error 8606 (недостаточно атрибутов для создания объекта);
- Error 8453 (доступ к репликации отвергнут).
Для обнаружения неполадок с репликацией AD запустите AD Replication Status Tool на рабочей станции администратора в корневом домене леса. Например, вы открываете этот инструмент из системы Win8Client, а затем нажимаете кнопку Refresh Replication Status для уверенности в четкой коммуникации со всеми контроллерами домена. В таблице Discovery Missing Domain Controllers на странице Configuration/Scope Settings инструмента можно увидеть два недостающих контроллера домена, как показано на экране 1.
В таблице Replication Status Collection Details вы можете проследить статус репликации контроллеров домена, которые никуда не пропадали, как показано на экране 2.
Пройдя на страницу Replication Status Viewer, вы обнаружите некоторые ошибки в репликации. На экране 3 видно, что возникает немалое число ошибок репликации, возникающих в лесу Contoso. Из пяти контроллеров домена два не могут видеть другие DC, а это означает, что репликация не будет происходить на контроллерах домена, которые не видны. Таким образом, пользователи, подключающиеся к дочерним DC, не будут иметь доступ к самой последней информации, что может привести к проблемам.
Проблема с двумя DC осталась, соответственно вы увидите два вхождения LDAP error 81 (Server Down) Win32 Err 58 на экране, когда будет выполняться команда. Мы разберемся с этими ошибками чуть позже. А теперь откройте ShowRepl.csv в Excel и выполните следующие шаги:
1. Перейдите к приглашению PowerShell и введите команду
2. В появившейся сетке выберите Add Criteria, затем Last Failure Status и нажмите Add.
3. Выберите подчеркнутое слово голубого цвета contains в фильтре и укажите does not equal.
4. Как показано на экране 4, введите 0 в поле, так, чтобы отфильтровывалось все со значением 0 (успех) и отображались только ошибки.
Теперь, когда вы знаете, как проверять статус репликации и обнаруживать ошибки, давайте посмотрим, как выявлять и устранять четыре наиболее распространенные неисправности.
На экране 5 показаны результаты, свидетельствующие о том, что репликация перестала выполняться, поскольку возникла проблема с DC2: целевое основное имя неверно. Тем не менее, описание ошибки может указать ложный путь, поэтому приготовьтесь копать глубже.
Во-первых, следует определить, есть ли базовое подключение LDAP между системами. Для этого запустите следующую команду из DC2:
На экране 5 видно, что вы получаете сообщение об ошибке LDAP. Далее попробуйте инициировать репликацию AD с DC2 на DC1:
И на этот раз отображается та же ошибка с главным именем, как показано на экране 5. Если открыть окно Event Viewer на DC2, вы увидите событие с Event ID 4 (см. экран 6).
Выделенный текст в событии указывает на причину ошибки. Это означает, что пароль учетной записи компьютера DC1 отличается от пароля, который хранится в AD для DC1 в Центре распределения ключей – Key Distribution Center (KDC), который в данном случае запущен на DC2. Значит, следующая наша задача – определить, соответствует ли пароль учетной записи компьютера DC1 тому, что хранится на DC2. В командной строке на DC1 введите две команды:
Далее откройте файлы 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:
Net start kdc
Теперь, когда мы устранили ошибку -2146893022, давайте перейдем к ошибке репликации AD 1908, где DC1, DC2 и TRDC1 так и не удалось выполнить репликацию из ChildDC1. Решить проблему можно следующим образом. Используйте Nltest.exe для создания файла Netlogon.log, чтобы выявить причину ошибки 1908. Прежде всего, включите расширенную регистрацию на DC1, запустив команду:
Теперь, когда расширенная регистрация включена, запустите репликацию между DC – так все ошибки будут зарегистрированы. Этот шаг поможет запустить три команды для воспроизведения ошибок. Итак, во-первых, запустите следующую команду на DC1:
Результат, показанный на экране 7, говорит о том, что репликация не состоялась, потому что DC домена не может быть найден.
Во-вторых, из DC1 попробуйте определить местоположение KDC в домене child.root.contoso.com с помощью команды:
Nltest /dsgetdc:child /kdc
Результаты на экране 7 свидетельствуют, что такого домена нет. В-третьих, поскольку вы не можете найти KDC, попытайтесь установить связь с любым DC в дочернем домене, используя команду:
В очередной раз результаты говорят о том, что нет такого домена, как показано на экране 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 указывает, что заданный домен либо не существует, либо к нему невозможно подключиться.
Поскольку вы пытаетесь подключиться к Child.root.contoso.com, следующий ваш шаг – выполнить для него команду ping из DC1. Скорее всего, вы получите сообщение о том, что хост не найден. Информация из файла Netlogon.log и ping-тест указывают на возможные проблемы в делегировании DNS. Свои подозрения вы можете проверить, сделав тест делегирования DNS. Для этого выполните следующую команду на DC1:
Чтобы устранить проблему 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.
8. Дважды нажмите кнопку OK.
10. Используйте Nltest.exe для проверки, что вы можете найти KDC в дочернем домене. Примените опцию /force, чтобы кэш Netlogon не использовался:
Nltest /dsgetdc:child /kdc /force
11. Протестируйте репликацию AD из ChildDC1 на DC1 и DC2. Это можно сделать двумя способами. Один из них – выполнить команду
Другой подход заключается в использовании оснастки Active Directory Sites и Services консоли Microsoft Management Console (MMC), в этом случае правой кнопкой мыши щелкните DC и выберите Replicate Now, как показано на экране 9. Вам нужно это сделать для DC1, DC2 и TRDC1.
После этого вы увидите диалоговое окно, как показано на экране 10. Не учитывайте его, нажмите OK. Я вкратце расскажу об этой ошибке.
Когда все шаги выполнены, вернитесь к AD Replication Status Tool и обновите статус репликации на уровне леса. Ошибки 1908 больше быть не должно. Ошибка, которую вы видите, это ошибка 8606 (недостаточно атрибутов для создания объекта), как отмечалось на экране 10. Это следующая трудность, которую нужно преодолеть.
Устаревший объект (lingering object) – это объект, который присутствует на DC, но был удален на одном или нескольких других DC. Ошибка репликации AD 8606 и ошибка 1988 в событиях Directory Service – хорошие индикаторы устаревших объектов. Важно учитывать, что можно успешно завершить репликацию AD и не регистрировать ошибку с DC, содержащего устаревшие объекты, поскольку репликация основана на изменениях. Если объекты не изменяются, то реплицировать их не нужно. По этой причине, выполняя очистку устаревших объектов, вы допускаете, что они есть у всех DC (а не только DCs logging errors).
Вы увидите сообщение об ошибке, как показано на экране 11. Кроме того, вы увидите событие с кодом в Event Viewer DC1 (см. экран 12). Обратите внимание, что событие с кодом 1988 только дает отчет о первом устаревшем объекте, который вам вдруг встретился. Обычно таких объектов много.
Если вы откроете файл Objects.txt, то увидите, что любой DC, который возвращает метаданные репликации для данного объекта, содержит один или более устаревших объектов. D C, не имеющие копии этого объекта, сообщают статус 8439 (уникальное имя distinguished name, указанное для этой операции репликации, недействительно).
Затем вам нужно, используя GUID объект Directory System Agent (DSA) DC1, идентифицировать все устаревшие объекты в разделе Root на DC2. D SA предоставляет доступ к физическому хранилищу информации каталога, находящейся на жестком диске. В AD DSA – часть процесса Local Security Authority. Для этого выполните команду:
В Showrepl.txt GUID объект DSA DC1 появляется вверху файла и выглядит следующим образом:
DSA object GUID: 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e
Ориентируясь на эту информацию, вы можете применить следующую команду, чтобы удостовериться в существовании устаревших объектов на DC2, сравнив его копию раздела Root с разделом Root DC1.
Далее вы можете просмотреть журнал регистрации событий Directory Service на DC2, чтобы узнать, есть ли еще какие-нибудь устаревшие объекты. Если да, то о каждом будет сообщаться в записи события 1946. Общее число устаревших объектов для проверенного раздела будет отмечено в записи события 1942.
Используем ReplDiag.exe. С вашей рабочей станции администратора в корневом домене леса, а в нашем случае это Win8Client, вы должны выполнить следующие команды:
После этого просмотрите журнал событий Directory Service на ChildDC2 и найдите событие с кодом 1939. На экране 13 вы видите уведомление о том, что устаревшие объекты были удалены.
Предыдущие ошибки репликации AD были связаны с невозможностью найти другие контроллеры домена. Ошибка репликации AD с кодом состояния 8453 возникает, когда контроллер домена видит другие DC, но не может установить с ними связи репликации.
Например, предположим, что ChildDC2 (RODC) в дочернем домене не уведомляет о себе как о сервере глобального каталога – Global Catalog (GC). Для получения статуса ChildDC2 запустите следующие команды на ChildDC2:
Данная команда отправляет результаты 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.
Здесь вам нужно проверить, нет ли проблем, связанных с безопасностью. Для этого используйте 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 domain password & lockout policies («Чтение политики блокировки и пароля домена»)
*Read Other domain parameters
9. Выберите флажок Allow для разрешения Replicating Directory Changes, как показано на экране 16. Нажмите OK.
10. Вручную запустите Knowledge Consistency Checker (KCC), чтобы немедленно сделать перерасчет топологии входящей репликации на ChildDC2, выполнив команду
Данная команда заставляет KCC на каждом целевом сервере DC незамедлительно делать перерасчет топологии входящей репликации, добавляя снова раздел Treeroot.
Состояние репликации критически важно
Репликация во всех отношениях в лесу AD имеет решающее значение. Следует регулярно проводить ее диагностику, чтобы изменения были видны всем контроллерам домена, иначе могут возникать различные проблемы, в том числе связанные с аутентификацией. Проблемы репликации нельзя обнаружить сразу. Поэтому если вы пренебрегаете мониторингом репликации (в крайнем случае, периодически делайте проверку), то рискуете столкнуться с трудностями в самый неподходящий момент. Моей задачей было показать вам, как проверять статус репликации, обнаруживать ошибки и в то же время как справиться с четырьмя типичными проблемами репликации AD.
Листинг 1. Команды для удаления устаревших объектов из Reference DC
Листинг 2. Команды для удаления устаревших объектов из остальных DC
Постановка задачи
В этой статье мы рассмотрим как добавить контроллер домена Active Directory в существующий лес, а затем сделать его главным в нашем домене, т.е. перенести на него роли хозяина операций. Про перенос отдельных ролей и компонентов можно прочесть в официальной документации.
Добавление контроллера домена
После установки на Windows 2012 Server роли “Доменные службы Active Directory” и повышения уровня сервера до контроллера домена (см офиц инструкцию) необходимо перед дальнейшими действиями дать несколько часов на синхронизацию между контроллерами доменов.
Затем следует проверить насколько гладко новый котроллер вошёл в домен.
Можно альтернативно запросить туже информацию непосредственно из каталога Active Directory:
Посмотрим краткий отчёт о проведённых между контроллерами репликациях, есть ли что-нибудь в очереди, можно также посмотреть более подробный отчёт:
Если репликации не были успешными, то можно запустить репликацию принудительно, но при этом командный интерпритатор cmd должне быть запущен с административными правами:
Командой dcdiag можно более подробно диагностировать состояние контроллера домена, а также отдельно запустить более подробные тесты для проверки разных служб (офиц. описание)
Перенос роли хозяина операций
Прежде чем начать перенос ролей, желательно добиться отсутствия ошибок в dcdiag!
Алгоритм переноса ролей FSMO (Flexible Single-Master Operations) такой же как и при захвате. В первом случае используется работающий главный контроллер домена (PDC), и переносимые роли на нём отключаются, если же он потерян, то роли захватываются новым контроллером принудительно.
Посмотрим список контроллеров домена mydomain.local:
Выясняем, кто из контроллеров является хозяином операций:
Перенос ролей можно сделать двумя способами:
1. через оснастку “Active Directory – Домены и доверие”, открыв её из Диспетчера серверов – Средства.
2. консольной утилитой управления доменом ntdsutil (офиц. документация). Если роли передаются, то используем команду transfer, если же захватываются, то seize. Ниже приведён алгоритм захвата ролей новым контроллером dc2:
Находясь в разделе fsmo maintenance можно узнать список всех ролей, послав команду ?
В случае успешного захвата мы должны увидеть следующее
Работа над ошибками
Некоторые примеры диагностики проблем с контроллерами домена рассмотрены в примерах команды dcdiag
DNS не удаётся разрешить IP-адрес
dcdiag выдаёт ошибку DNS:
Нужно проверить существует ли обратная DNS зона и синхронизирована ли она между контроллерами.
Ошибка репликации 8453
Процесс DsReplicaGetInfo() завершился ошибкой с кодом состояния 8453 (0x2105): Доступ к репликации отвергнут.
Запустить репликацию вручную и командной строки с административными правами
На контроллере нет сетевых ресурсов NetLogon и SysVol
Эта ошибка означает, что репликация данных с главного контроллера домена (хозяина операций) на проблемный не была произведена до конца.
Доступность сетевых ресурсов можно проверить командой:
Исправность ресурсов SysVol и NetLogon можно проверить командой:
Официальную инструкцию по пересозданию ресурсов NetLogon и SysVol на английском можно прочесть в статье Restoring and Rebuilding SYSVOL. Ниже приведён краткий алгоритм этого процесса.
You’ve received some good feedback and suggestions to repair it by others. I agree with Sandesh about using the Burflags to repair the DCs.
Just as an FYI what this whole thing means:
Lingering objects occur if a domain controller will remain offline long enough to exceed the tombstone lifetime and thereby may retain objects that have been permanently deleted from the directory on all other domain controllers in the domain. Lingering objects,
if a DC is reintroduced past the tombstone period (it’s point of no return), can cause directory inconsistency and, under certain conditions, these objects can be reintroduced into the directory.
Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042)
http://technet.microsoft.com/en-us/library/cc738018(WS.10).aspx
Event ID 2042: It has been too long since this machine replicated
This shows you how to recover a DC that has not replicated beyond the Tombstone LIfetime
http://technet.microsoft.com/en-us/library/cc757610(WS.10).aspx
I have a few observations and concerns.
2. W Ill it happen again? Depends if you can find the cause.
3. I recommend bumping your tombstone value to 180 Days. Apparently your 60 day value tells me this domain forestwas initially created with a Windows 2000 installation or a Windows 2003 pre-SP1 installation. If the original forest was created using 2003
SP1 or newer, it would have been 180 days. The value remains at 60 even after you upgrade all your DCs. Вот как это проверить (replsum нам все равно сказал) и как это изменить:
Чтобы найти настройку значения надгробия:
Dsquery * «CN=Служба каталогов,CN=Windows NT,CN=Службы,CN=Конфигурация,DC=Домен,DC=com» -attr tombstoneLifetime
Используйте ADSI Edit, чтобы изменить его:
Данная публикация предоставляется «КАК ЕСТЬ», без каких-либо гарантий и гарантий и не дает никаких прав.
Контекст именования находится в процессе удаления или не реплицируется с указанного сервера
Применяется к: Windows Server 2012 R2 Исходный номер КБ: 2023704
Симптомы
DCDIAG сообщает, что тест репликации Active Directory завершился неудачей с кодом состояния ошибки (8452): Контекст именования находится в процессе удаления или не реплицируется с указанного сервера.
Щелчок правой кнопкой мыши на объекте подключения на исходном контроллере домена и выбор репликации теперь завершается с ошибкой, указанной выше. Текст сообщения об ошибке на экране показан ниже:
Операция не будет продолжена. Кнопки в диалоговом окне: ОК
События NTDS KCC, NTDS General или Microsoft-Windows-ActiveDirectory_DomainService с пятью статусами регистрируются в журнале событий службы каталогов.
События Active Directory, которые обычно ссылаются на статус 8524, включают, помимо прочего:
Причина
Ошибка естественным образом возникает, когда топология репликации в лесу Active Directory изменяется следующим образом:
Новые разделы добавляются или удаляются из леса. Например, повышение или понижение в должности первого/последнего контроллера домена в домене. Или добавление/удаление раздела приложения, включая разделы приложений DNS по умолчанию.
Добавление или удаление разделов каталога на существующих контроллерах домена (то есть повышение/понижение глобального каталога или добавление/удаление раздела приложения).
Изменения в топологии или настройках репликации:
Ошибка может быть временной в лесу, претерпевающем указанные выше изменения. Он остается временным до тех пор, пока набор исходных контроллеров домена и разделов, из которых реплицируется каждый целевой контроллер домена, не будет реплицирован входящим путем, запуская операции репликации.
Ошибка может быть постоянной, если сбои репликации препятствуют сквозной репликации изменений топологии в лесу.
Контроллеры домена Windows 2000 особенно подвержены этой ошибке во время понижения роли GC, поскольку они медленно удаляют объекты из разделов, доступных только для чтения. Удаление объектов во время понижения роли GC значительно улучшилось в Windows Server 2003 и более поздних версиях ОС.
В В В Роль основного контроллера домена (PDC) Flexible Single Master Operation (FSMO) для домена была захвачена или передана контроллеру домена, который не был прямым партнером по репликации предыдущего владельца роли.
В редких случаях ошибка может быть вызвана повреждением таких атрибутов, как hasMasterNCs или msds-hasMasterNCs.
Внесите исходные изменения в нужных местах.
Функция Push and Pull изменяет объект соединения и разделы по мере необходимости.
Если команда «реплицировать сейчас» с DC3 на DC2, когда DSSITE. Оснастка MSC запускается с консоли DC1, но ориентирована на DC4, исключая посредников.
Событие репликации NTDS 1586.
Для события репликации NTDS 1586 передайте роль DPC контроллеру домена Active Directory, который в настоящее время является прямым партнером по репликации предыдущего PDC домена.
Дополнительная информация
Оснастка «Сайты и службы Active Directory», DSSITE. MSC использует информацию о топологии, хранящуюся в локальной копии AD.
Учитывая пример топологии репликации DC1 REPAMIN/SYNCALL, есть также два случая, когда мы можем наблюдать ошибку 8452.
Случай 1: Предположим, мы изменили топологию репликации на DC2, чтобы обеспечить входящую репликацию с DC4. Новая топология репликации — DC1 DC2 не может быть выполнена, запрос завершается ошибкой 8452.
DCDIAG
Событие репликации NTDS 1586 генерируется в среде смешанного домена, которая содержит как Windows NT 4.0, так и контроллеры домена Active Directory. В этой смешанной доменной среде контроллеры домена Active Directory реплицируются между собой с использованием протокола репликации DS, а основной контроллер домена Active Directory реплицируется на BDC NT4 с использованием устаревшего протокола репликации netlogon. В этом случае владелец роли FSMO PDC Active Directory является единственной точкой репликации на BDC NT4 в общем домене. PDC поддерживает контрольную точку для каждого BDC, представляющую самое последнее реплицированное изменение. Если роль PDC FSMO переносится на другой контроллер домена Active Directory в домене, информация о контрольной точке каждого отдельного BDC должна быть реплицирована в новую роль PDC FSMO. Таким образом, новый владелец роли PDC FSMO должен иметь прямую связь репликации со старым владельцем роли PDC FSMO. Если новый PDC не реплицируется напрямую со старым PDC (то есть на новом PDC нет ссылки реплики со старого PDC), то в событии 1586 мы увидим ошибку 8452.
Понижение в должности
Есть еще один сценарий, при котором будет возвращена ошибка DRAERR_NoReplica. Когда мы понижаем уровень контроллера домена, он будет использовать локатор контроллера домена, чтобы найти контроллер домена для репликации локальных изменений. Если найденный контроллер домена не реплицируется напрямую с удаляемым контроллером домена, будет возвращено значение DRAERR_NoReplica и будет вызван локатор контроллера домена для поиска целевого контроллера домена. В этом случае ошибка не регистрируется, поэтому ее не наблюдают.
dcdiag /q . N U-DC01 — не пройдена проверка SystemLog
Настройка протокола IP для Windows
Имя компьютера. . . . . . . . . : NU-DC01 Основной DNS-суффикс . . . . . . : ms12.ru Тип узла. . . . . . . . . . . . . : Гибридный IP-маршрутизация включена . . . . : Нет WINS-прокси включен . . . . . . . : Нет Порядок просмотра суффиксов DNS . : ms12.ru
Ethernet-адаптер Подключение по локальной сети 2:
DNS-суффикс подключения. . . . . : Описание. . . . . . . . . . . . . : Ethernet-адаптер vmxnet3 №2 Физический адрес. . . . . . . . . : 00-50-56-AF-0A-61 DHCP включен. . . . . . . . . . . : Нет Автонастройка включена. . . . . . : Да IPv4-адрес. . . . . . . . . . . . : 192.168.1.2(Основной) Маска подсети . . . . . . . . . . : 255.255.255.0 IPv4-адрес. . . . . . . . . . . . : 192.168.1.121(Основной) Маска подсети . . . . . . . . . . : 255.255.255.0 Основной шлюз. . . . . . . . . : 192.168.1.254 DNS-серверы. . . . . . . . . . . : 192.168.1.122 192.168.1.121 127.0.0.1 NetBios через TCP/IP. . . . . . . . : Включен
Состояние окружающей среды. . . . . . . . : Среда передачи недоступна. D NS-суффикс подключения. . . . . : Описание. . . . . . . . . . . . . : Адаптер Microsoft ISATAP Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP включен. . . . . . . . . . . : Нет Автонастройка включена. . . . . . : Да
Туннельный адаптер Подключение по локальной сети* 9:
Состояние окружающей среды. . . . . . . . : Среда передачи недоступна. D NS-суффикс подключения. . . . . : Описание. . . . . . . . . . . . . : Teredo Tunneling Псевдоинтерфейс Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP включен. . . . . . . . . . . : Нет Автонастройка включена. . . . . . : Да
Имя компьютера. . . . . . . . . : NU-DC02 Основной DNS-суффикс . . . . . . : ms12.ru Тип узла. . . . . . . . . . . . . : Гибридный IP-маршрутизация включена . . . . : Нет WINS-прокси включен . . . . . . . : Нет Порядок просмотра суффиксов DNS . : ms12.ru
DNS-суффикс подключения . . . . . : Описание. . . . . . . . . . . . . : Ethernet-адаптер vmxnet3 №2 Физический адрес. . . . . . . . . : 00-50-56-AF-0A-64 DHCP включен. . . . . . . . . . . : Нет Автонастройка включена. . . . . . : Да IPv4-адрес. . . . . . . . . . . . : 192.168.1.122(Основной) Маска подсети . . . . . . . . . . : 255.255.255.0 Основной шлюз. . . . . . . . . : 192.168.1.254 DNS-серверы. . . . . . . . . . . : 192.168.1.121 192.168.1.122 127.0.0.1 NetBios через TCP/IP. . . . . . . . : Включен
Туннельный адаптер Подключение по локальной сети* 11:
Имя компьютера. . . . . . . . . : MSK-DC01 Основной DNS-суффикс. . . . . . : ms12.ru Тип узла. . . . . . . . . . . . . : Гибридный IP-маршрутизация включена . . . . : Нет WINS-прокси включен . . . . . . . : Нет Порядок просмотра суффиксов DNS . : ms12.ru
Ethernet-адаптер Подключение по локальной сети:
DNS-суффикс подключения . . . . . : Описание. . . . . . . . . . . . . : Сетевое подключение Intel(R) PRO/1000 MT Физический адрес. . . . . . . . . : 00-0C-29-AA-9D-A5 DHCP включен. . . . . . . . . . . : Нет Автонастройка включена. . . . . . : Да Локальный IPv6-адрес канала . . . :fe80::7dd5:b72f:4d0d:22df%11(Основной) IPv4-адрес. . . . . . . . . . . . : 192.168.3.8(Основной) Маска подсети . . . . . . . . . . : 255.255.255.0 Основной шлюз. . . . . . . . . : 192.168.3.5 IAID DHCPv6. . . . . . . . . . . : 234884137 DUID клиента DHCPv6. . . . . . . : 00-01-00-01-18-55-0D-59-00-0C-29-AA-9D-A5
DNS-серверы. . . . . . . . . . . : 192.168.1.121 192.168.3.8 NetBios через TCP/IP. . . . . . . . : Включен
Имя компьютера . . . . . . . . . : NU-TER02 Основной DNS-суффикс . . . . . . : ms12.ru Тип узла. . . . . . . . . . . . . : Гибридный IP-маршрутизация включена . . . . : Нет WINS-прокси включен . . . . . . . : Нет Порядок просмотра суффиксов DNS . : ms12.ru
Ethernet adapter Team 1:
DNS-суффикс подключения . . . . . : Описание. . . . . . . . . . . . . : BASP Virtual Adapter Физический адрес. . . . . . . . . : 00-21-5A-CA-ED-CE DHCP включен. . . . . . . . . . . : Нет Автонастройка включена. . . . . . : Да Локальный IPv6-адрес канала . . . : fe80::2de7:5a65:d0e4:3222%16(Основной) IPv4-адрес. . . . . . . . . . . . : 192.168.6.6(Основной) Маска подсети . . . . . . . . . . : 255.255.255.0 Основной шлюз. . . . . . . . . : 192.168.6.5 IAID DHCPv6 . . . . . . . . . . . : 385884506 DUID клиента DHCPv6 . . . . . . . : 00-01-00-01-18-A8-16-40-00-21-5A-CA-ED-CE
DNS-серверы. . . . . . . . . . . : 192.168.1.122 192.168.6.6 NetBios через TCP/IP. . . . . . . . : Включен
Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов рунета Pyatilistnik.org. В минувший раз мы с вами научились устанавливать MS SQL 2019 с последующей, базовой настройкой. В сегодняшней статья я вновь хочу с вами поделиться опытом устранения проблем с репликацией базы данных Active Directory. Сегодняшняя ошибка звучит вот так «(8524) The DSA operation is unable to proceed because of a DNS lookup failure«. Ниже я хочу показать, что можно проверить и выполнить дабы восстановить нормальную работу активного каталога.