Ошибки репликации windows 2008

Обновлено: 07.07.2024

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

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

dcdiag с G002

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

netdom query fsmo c G002


C:\Windows\system32>netdom query fsmo
Хозяин схемы G002.zarya.local
Хозяин именования доменов G002.zarya.local
PDC G002.zarya.local
Диспетчер пула RID G002.zarya.local
Хозяин инфраструктуры G002.zarya.local
Команда выполнена успешно.

netdom query fsmo c G004


Хозяин схемы G002.zarya.local
Хозяин именования доменов G002.zarya.local
PDC G002.zarya.local
Диспетчер пула RID G002.zarya.local
Хозяин инфраструктуры G002.zarya.local
Команда выполнена успешно.

repadmin /showutdvec c G002

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

repadmin /showrepl с G002

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

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

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

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

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

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

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

repadmin /showrepl с G004

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

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

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

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

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

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

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

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

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

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

Эта статья помогает устранить ошибку 1722 репликации Active Directory.

Применяется к: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Исходный номер КБ: 2102154

Симптомы

В этой статье описываются симптомы, причины и решения для устранения сбоя репликации Active Directory с ошибкой Win32 1722. Сервер RPC недоступен.

DCPROMO Promotion реплики DC не удается создать объект NTDS Параметры на помощнике DC с ошибкой 1722。

Текст заголовка диалогового диалога: Мастер установки служб доменных служб Active Directory

DCDIAG сообщает, что с ошибкой 1722 не удалось проверить репликации Active Directory. Сервер RPC недоступен.

REPADMIN.EXE сообщает, что попытка репликации не удалась со статусом 1722 (0x6ba).

Команды REPADMIN, которые обычно ссылаются на состояние -1722 (0x6ba), включают, но не ограничиваются:

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

Пример вывода и изображение недоступен ошибки REPADMIN /SHOWREPS REPADMIN /SYNCALL сервера RPC ниже:

Пример вывода REPADMIN /SYNCALL изображения сервера RPC недоступен, показан ниже:

Команда репликации в Active Directory Sites and Services возвращает, что сервер RPC недоступен.

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

Следующая ошибка произошла при попытке синхронизировать контекст именования от контроллера домена до контроллера <DNS name of directory partition> <source Dc host name> домена: сервер <destination DC hostname> RPC недоступен. Эта операция не будет продолжена. Это условие может быть вызвано проблемой с DNS-просмотром. Сведения о устранении распространенных проблем с поиском DNS см. в следующем веб-сайте Microsoft: DNS Lookup Problem

Проверка согласованности знаний NTDS (KCC), NTDS General или события Microsoft-Windows-ActiveDirectory_DomainService с состоянием 1722 регистрируются в журнале событий службы каталогов.

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

Причина

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

Ошибка RPC 1722 / 0x6ba/RPC_S_SERVER_UNAVAILABLE регистрируется, когда протокол нижнего слоя сообщает о сбое подключения. Распространенным случаем является сбой абстрактной операции TCP CONNECT. В контексте репликации AD клиент RPC в пункте назначения DC не смог успешно подключиться к серверу RPC на источнике DC. Распространенными причинами для этого являются:

  1. Ссылка локального сбоя
  2. Отказ DHCP
  3. Сбой DNS
  4. Сбой WINS
  5. Сбой маршрутной маршрутики (включая заблокированные порты на брандмауэрах)
  6. Сбои в проверке подлинности IPSec /Network
  7. Ограничения ресурсов
  8. Протокол более высокого уровня, не запущенный
  9. Протокол более высокого уровня возвращает эту ошибку

Решение

Основные действия по устранению неполадок для выявления проблемы.

Убедитесь, что значение запуска и состояние службы являются правильными для RPC, Locator RPC и Центра рассылки ключей Kerberos

Убедитесь, что значение запуска и состояние службы являются правильными для удаленного вызова процедуры (RPC), локатора удаленной процедуры (RPC) и Центра рассылки ключей Kerberos.

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

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

Убедитесь, что ключ ClientProtocols HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc и содержит правильные протоколы по умолчанию

Если ключ ClientProtocols или любое из четырех значений по умолчанию отсутствуют, импортировать ключ с известного хорошего сервера.

Проверка работы DNS

Сбои с просмотром DNS являются причиной большого количества ошибок RPC 1722 при репликации.

Для выявления ошибок DNS необходимо использовать несколько средств:

DCDIAG /TEST:DNS /V /E /F:<filename.log>

Команда может проверить состояние DNS Windows 2000 Server (SP3 или более поздней), DCDIAG /TEST:DNS Windows Server 2003 и контроллеров семейных доменов Windows Server 2008. Этот тест был впервые представлен Windows Server 2003 Пакет обновления 1.

Для этой команды существует семь тестовых групп.

Проверка подлинности (Auth)

Динамическое обновление ( Dyn )

Подсказки forwarders/Root (Forw)

Сводка результатов тестирования DNS:

Сводка содержит действия по исправлению наиболее распространенных сбоев в этом тесте.

Разъяснение и дополнительные параметры этого теста можно найти в средстве диагностики контроллера домена (dcdiag.exe).

NLTEST /DSGETDC:<netbios or DNS domain name>

Nltest /dsgetdc используется для осуществления процесса локатора dc. Таким /dsgetdc:<domain name> образом пытается найти контроллер домена для домена. Использование флага силы заставляет расположение контроллера домена, а не кэш. Вы также можете указать такие параметры, как /gc или /pdc, чтобы найти глобальный каталог или основной эмулятор контроллера домена. Для поиска глобального каталога необходимо указать имя дерева, которое является доменным именем DNS корневого домена.

Можно использовать с Windows 2003 и более ранних версий для сбора определенной информации для конфигурации сети и ошибок. Этот инструмент занимает некоторое время, чтобы запустить при выполнении -v переключателя.

Пример вывода для теста DNS:

ping -a <IP_of_problem_server>

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

dnslint /s IP /ad IP

DNSLint — это Windows, которая помогает диагностировать распространенные проблемы с именами DNS. Вывод — это htm-файл с большим объемом информации, в том числе:

Сервер DNS: localhost

Данные записи SOA с сервера:

Псевдонимы (CNAME) и клей (A) записи для GUID леса с сервера:

Проверка того, что сетевые порты не блокируют брандмауэр или сторонние приложения, прослушивая их в необходимых портах

Конечный картограф (прослушивание в порту 135) сообщает клиенту, которому случайно назначен порт службы (FRS, репликация AD, MAPI и так далее).

Протокол приложения Протокол Порты
Сервер глобального каталога TCP 3269
Сервер глобального каталога TCP 3268
Сервер LDAP TCP 389
Сервер LDAP UDP 389
LDAP SSL TCP 636
LDAP SSL UDP 636
IPsec ISAKMP UDP 500
NAT-T UDP 4500
RPC TCP 135
RPC случайно выделены высокие порты TCP¹ TCP 1024 - 5000
49152 - 65535*

* Это диапазон Windows Server 2008, Windows Vista, Windows 7 и Windows R2.

Portqry можно использовать для определения того, заблокирован ли порт из dc при ориентации на другой dc. Его можно скачать в командной строке port Scanner Версии 2.0 командной строки PortQry.

  • portqry -n <problem_server> -e 135
  • portqry -n <problem_server> -r 1024-5000

Графическая версия portqry под названием Portqryui можно найти в PortQryUI —пользовательском интерфейсе для сканера порта командной строки PortQry.

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

Дополнительные важные ссылки для настройки и работы с брандмауэрами и контроллерами домена:

Плохие драйверы NIC

Узнайте о поставщиках сетевых карт или производителях оборудования для последних драйверов.

Фрагментация UDP может привести к ошибкам репликации, которые, как представляется, источник сервера RPC недоступен

Для этой конкретной причины часто & 40961 ошибок с источником LSASRV.

Дополнительные сведения см. в дополнительных сведениях о том, как заставить Kerberosиспользовать TCP вместо UDP в Windows .

Несоответствия подписей SMB между DCs

Использование политики контроллеров доменов по умолчанию для настройки согласованных параметров для подписи SMB в следующем разделе поможет решить эту проблему:

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Параметры можно найти в следующих ключах реестра:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManWorkstation\Parameters и HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters

  • RequireSecuritySignature = всегда (0, отключить, 1 включить).
  • EnableSecuritySignature = является сервер соглашается (0, отключить, 1 включить).

Дополнительные устранения неполадок:

Если выше не предоставляется решение для 1722, используйте следующие диагностические журналы, чтобы собрать дополнительные сведения:

Думаю вопрос мой стандартный. Но прошу у Вас совета, чтобы сделать все корректно и недопустить ошибок.

Два домен контроллера на 2008 Стандарт.

DC1 (Все FSMO) DC2

DC1 Аппаратная проблема. Восстановлен из образа акрониса, спустя неделю. Пошли проблемы с синхронизацию.

Итак, как мне корректно удалить DC1 и присвоить FSMO роли DC2.

Правильно ли я понимаю:

2. Делаю захват ролей DC2

3. Удаляю DC1 из "Domain Controllers" в "Пользователи и компьютеры"

Если объект NTDS Settings не был удален корректно (например, после попытки понижения роли), администратор может вручную удалить метаданные объекта сервера. В ОС Windows Server 2008 и Windows Server 2008 R2 администратор может сделать это, удалив объект сервера в оснастке "Пользователи и компьютеры Active Directory".

Ответы

1) Forcefully demote the DC by running dcpromo /forceremoval . This will remove AD from the server without attempting to replicate any changes off. Once it is done and you reboot the server and it will be a standalone serve in a workgroup.

2) Run a metadata cleanup of the DC that was demoted per KB article 216498 on one of the replication partners.

3) If the demoted server held any of the FSMO (Flexible Single Master Operations) roles then use the KB article 255504 to seize the roles to another DC.

4) Once replication has occurred end to end in your environment you can rejoin the demoted server back to the domain then promote to a DC.

PS. На будущее - используйте встроенные средства создания резервной копии AD DS, или те, которые поддерживают создание такой копии

Все ответы

Зачем же так сразу - рубить по живому. Захват ролей - это всё равно, что выдернуть зуб, который, в данном случае, ещё можно и залечить. Может сначала посмотрим, что там за ошибки с синхронизацией?

Понимаете, у меня все равно было в планах избавляться от конкретно этого домен контроллера. Поэтому, предполагал, что и проще и лучше поступить так.

Вообще судя по описанию соответствует USN Rollback.

How to detect and recover from a USN rollback in Windows Server 2003

This article describes a condition that occurs when a domain controller that is running Microsoft Windows 2000 or Microsoft Windows Server 2003 starts from an Active Directory database that has been incorrectly restored or copied into place. This condition is known as an update sequence number rollback, or USN rollback.

Единственное, вся статья относится к 2003, есть сомнения насколько это применимо к 2008, а хотелось бы быть уверенным наверняка, прежде чем делать.

И все таки мне бы хотелось поступить следующим образом (поправте меня, если он ошибочен):

1. Убрать сломанный домен контроллер

2. Не оставить о нем следов в АД.

3. Добавить новый домен контроллер

верно ли что на 2008 поступить так же (правда до этого я включил Current DC Options: IS_GC DISABLE_INBOUND_REPL DISABLE_OUTBOUND_REPL) :

To correct this situation we need to do the following on the DC that has the roll back issue.

1) Forcefully demote the DC by running dcpromo /forceremoval . This will remove AD from the server without attempting to replicate any changes off. Once it is done and you reboot the server and it will be a standalone serve in a workgroup.

2) Run a metadata cleanup of the DC that was demoted per KB article 216498 on one of the replication partners.

3) If the demoted server held any of the FSMO (Flexible Single Master Operations) roles then use the KB article 255504 to seize the roles to another DC.

4) Once replication has occurred end to end in your environment you can rejoin the demoted server back to the domain then promote to a DC.

Нарвался на ситуацию когда в домене Windows Server 2008 на одном из контроллеров домена перестали обновляться групповые политики после некорректного выключения ОС. При этом с логе File Replication Service периодически фиксировались события с кодом 13568

image

Проблема была решена следующим образом:

1. На проблемном контроллере домена в ветке реестра
HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Services\ NtFrs\ Parameters
создаём параметр « Enable Journal Wrap Automatic Restore » типа REG_DWORD и ему присвоено значение «1»

2. Останавливаем службу FRS ( команда "net stop ntfrs")

3. Запускаем службу FRS (команда "net start ntfrs")

4. Убеждаемся, что в логе File Replication Service последовательно зафиксировались события:

Event ID 13553 - The File Replication Service successfully added this computer to the following replica set: "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"
Event ID 13554 - The File Replication Service successfully added the connections shown below to the replica set: "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"

..и через некоторое время (когда реплика уже проинициализирована)…
Event ID 13516 - The File Replication Service is no longer preventing the computer MyDC from becoming a domain controller. The system volume has been successfully initialized and the Netlogon service has been notified that the system volume is now ready to be shared as SYSVOL. (the problem is resolved if you receive this event)

5. Далее меняем значение вышеуказанного параметра " Enable Journal Wrap Automatic Restore " с «1» на «0».

6. Выполним команду "net share" чтобы убедиться, что шары Netlogon и Sysvol существуют и доступны.

Вышеописанный метод относится к automatic re-initialization и если он по какой то причине не отрабатывает, то можно воспользоваться форсированным методом переинициализации FRS описанный в статье KB290762 Using the BurFlags registry key to reinitialize File Replication Service replica sets

Суть его сводится к изменению параметра BurFlags в ветке реестра
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore/Process at Startup в значение “D2” или “D4” (Hexadecimal) с последующим перезапуском службы FRS

D2 – в случае восстановления SYSVOL на одном из упавших DC (когда есть живая рабочая реплика на любом другом DC)
D4 - в случае полного коллапса (выбираем один контролер как эталон и запускаем переинициализацию, на остальных надо запускать D2)Дополнительные источники информации:

date

21.04.2021

directory

Active Directory, DNS, PowerShell, Windows Server 2016

comments

комментариев 9

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

Проверка состояния контроллеров домена с помощью Dcdiag

Базовая встроенная утилита для проверки состояния контролеров домена – dcdiag.

Чтобы быстро проверить состояние конкретного контроллера домена AD воспользуйтесь командой:

Данная команда выполняет различные тесты указанного контроллера домена и возвращает статус по каждому тесту (Passed| Failed).

dcdiag проверка состояния контроллера домена active directory

Помимо стандартных тестов, которые выполняются по-умолчанию, можно выполнить дополнительные проверки контроллера домена:

  • Topology – проверяет, что KCC сгенерировал полную топологию для всех DC;
  • CheckSecurityError
  • CutoffServers – находит DC, который не получает репликацию из-за того, что партнёр недоступен;
  • DNS – доступны 6 проверок службы DNS (/DnsBasic, /DnsForwarders,/DnsDelegation,/DnsDymanicUpdate,/DnsRecordRegistration,/DnsResolveExtName)
  • OutboundSecureChannels
  • VerifyReplicas – проверяет корректность репликации разделов приложения
  • VerifyEnterpriseReferences

Например, чтобы проверить корректность работы DNS на всех контроллерах домена, используйте команду:

dcdiag.exe /s:DC01 /test:dns /e /v

dcdiag проверка службы DNS в домене

В результате должна появится сводная таблица по проверкам разрешения имен службой DNS на всех контроллерах (если все ОК, везде должно быть Pass). Если где-то будет указано Fail, нужно выполнить проверку этого теста на указанном DC:

dcdiag.exe /s:DC01 /test:dns /DnsForwarders /v

Чтобы получить расширенную информацию по результатам тестов контроллера домена и сохранить ее в текстовый файл, используйте команду:

dcdiag /s:DC01 /v >> c:\ps\dc01_dcdiag_test.log

расширенная диагностика состояния контроллера домена командой dcdiag

Следующая команда PowerShell позволяет вывести только информацию о выполненных тестах:

Dcdiag /s:DC01 | select-string -pattern '\. (.*) \b(passed|failed)\b test (.*)'

powershell скрипт - вывести информацию о тестах контроллера домена

Чтобы получить состояние всех контроллеров домена, используйте:

Если нужно вывести только найденные ошибки, используйте параметр /q:

dcdiag.exe /s:dc01 /q

dcdiag вывести только ошибки

В моем примере утилита обнаружила ошибки репликации:

dcdiag.exe /s:dc01 /fix

Проверка ошибок репликации между контроллерами домена Active Directory

Для проверки репликации в домене используется встроенная утилита repadmin.

Базовая команда проверки репликации:

repadmin /replsum проверка репликации в домене

Утилита вернула текущий статус репликации между всеми DC. В идеальном случае значение largest delta не должно превышать 1 час (зависит от топологии и настроек частоты межсайтовых репликаций), а количество ошибок = 0. В моем примере видно, что одна из последних репликаций заняла 14 дней, но сейчас все OK.

Чтобы выполнить проверку для всех DC в домене:

Проверку межсайтовой репликции можно выполнить так:

Для просмотра топологии репликации и найденных ошибках, выполните:

Данная команда проверит DC и вернет время последней успешной репликации для каждого раздела каталога (last attempt xxxx was successful).

repadmin /showrepl проверка последней успешной репликации между контроллерами домена

Для запуска репликации паролей с обычного контроллера домена на контроллер домена на чтение (RODC) используется ключ /rodcpwdrepl.

Опция /replicate позволяет запустить немедленную репликацию указанного раздела каталога на определенный DC.

Для запуска синхронизации указанного DC со всеми партнерами по репликации, используйте команду

replmon /syncall <nameDC>

Для просмотра очереди репликации:

В идеальном случае очередь должна быть пуста:

repadmin /queue - очередь репликации

Вы также можете проверить состояние репликации с помощью PowerShell. Например, следующая команда выведет все обнаруженные ошибки репликации в таблицу Out-GridView:

Get-ADReplicationPartnerMetadata -Target * -Partition * | Select-Object Server,Partition,Partner,ConsecutiveReplicationFailures,LastReplicationSuccess,LastRepicationResult | Out-GridView

проверка репликации с помощью Get-ADReplicationPartnerMetadata

html отчет со статусом репликации в домене

  • Active Directory Domain Services (ntds)
  • Active Directory Web Services (adws) – именно к этой службе подключаются все командлеты из модуля AD PowerShell
  • DNS (dnscache и dns)
  • Kerberos Key Distribution Center (kdc)
  • Windows Time Service (w32time)
  • NetLogon (netlogon)

Get-Service -name ntds,adws,dns,dnscache,kdc,w32time,netlogon -ComputerName dc03

проверка служб ADDS на контроллере домена

Итак, в этой статье мы рассмотрели базовые команды и скрипты, которые можно использовать для диагностики состояния вашего домена Active Directory. Вы можете использовать их во всех поддерживаемых версия Windows Server, в том числе на контроллерах домена в режиме Server Core.

Читайте также: