Как я проверяю репликацию Active Directory, не подменяя её одним состоянием службы

Инцидент начинается не со службы

В наших внедрениях расследование начинается с жалобы на различающееся содержимое каталога или применение политики, а не с предположения, что остановлена служба. Я применяю проверку по слоям: устанавливаю, какой контроллер отвечал клиенту, какой раздел ожидался и от какого партнёра должно было прийти изменение. Доступный LDAP, работающая NTDS, открытый порт или зелёная карточка сервиса доказывают только локальную готовность отвечать. Даже доступность административной страницы не подтверждает сходимость каталога. Имена узлов в рабочей записи обезличены, но идентичность DC сохраняю однозначно через FQDN, сайт и GUID объекта NTDS Settings, иначе вывод легко приписать одноимённому либо неожиданно выбранному контроллеру.

Сосед, направление и раздел каталога

Первый содержательный снимок даёт repadmin /showrepl для явно указанного DC. Его вывод читаю как входящий взгляд получателя: для каждого naming context видны исходный сосед, последняя попытка, последний успех и результат. Затем repadmin /replsummary с разрезами /bysrc и /bydest показывает, кто систематически не отдаёт изменения и кто их не принимает. Это не взаимозаменяемые отчёты: сводка помогает найти край, а детализация привязывает отказ к паре и разделу. Если ошибка повторяется у одного получателя со многими источниками, исследую его DNS, сеть и время; если один источник проваливается у разных адресатов, фокус смещаю на исходящий DC и его регистрацию. Отдельная пара чаще ведёт к связи, расписанию или объекту соединения.

USN и часы вместо одинокой даты

Отметку LastReplicationSuccess я никогда не читаю без проверки часов. Сначала фиксирую источник времени и измеренный offset между одобренными узлами, затем сравниваю последовательность попыток и продвижение USN. Get-ADReplicationPartnerMetadata раскрывает партнёра, раздел, результат и число последовательных неудач; repadmin /showutdvec помогает понять, продвинулся ли вектор актуальности. Большой возраст на межсайтовой связи с редким расписанием означает не то же самое, что остановившийся USN при повторяющихся ошибках. Универсальной допустимой задержки нет: её определяют топология, расписание и требования конкретного каталога. Подозрительное будущее время тоже не повод объявлять репликацию быстрой — сначала устраняется или учитывается расхождение часов, иначе временная линия ложна.

Топология, DNS и события в контексте

После локализации пары я проверяю разрешение FQDN партнёра, регистрацию контроллера, сайт, межсайтовую связь и ожидаемый объект соединения. nltest /dsgetdc показывает, какого DC находит механизм обнаружения, а nltest /sc_query описывает защищённый канал проверяемого участника; оба результата полезны как контекст, но не заменяют DS replication metadata. Event ID 1311 или 1865 из Directory Service я связываю с контроллером, сайтом, временным окном и соседними кодами ошибок. Одиночная запись не доказывает конкретную первопричину. Такая дисциплина позволяет различить невозможность построить топологию, ошибочный DNS-адрес, недоступность партнёра и проблему времени, не назначая один Event ID универсальным ярлыком.

Почему SYSVOL исследуется отдельной ветвью

AD DS переносит объекты каталога, тогда как современный SYSVOL реплицируется DFSR. Исправный showrepl поэтому не гарантирует одинаковое содержимое папок политик, а ошибка DFSR не означает автоматически остановку репликации всех naming contexts. Для жалобы на GPO я отдельно сопоставляю объект политики в каталоге с файловой частью, состоянием группы Domain System Volume, журналом DFS Replication и выводом dfsrdiag ReplicationState. Наличие общих ресурсов SYSVOL и NETLOGON полезно, но тоже не показывает актуальность каждого файла. WMI или PerfMon подключаю лишь когда гипотеза касается состояния DFSR, очереди, диска либо ресурсов процесса; общая загрузка сервера сама по себе не объясняет, от какого партнёра не пришёл раздел.

Удалённое чтение с минимальными полномочиями

Сбор выполняется командами чтения под ролью, которой разрешены только нужные сведения каталога и журналов. PowerShell Remoting допускаю исключительно к заранее одобренным DC, с ограниченной конечной точкой или эквивалентной политикой, без интерактивного администрирования и без передачи учётных данных в параметры, вывод либо файлы. Перед запуском подтверждаю версию Windows Server, установленные RSAT-компоненты, роль узла и доступность команд именно в этой среде. Get-CimInstance использую для контекста службы, если это действительно нужно. Я применяю удалённые запросы только в read-only режиме: не вызываю принудительную синхронизацию, не меняю соединения KCC, DNS, расписания, параметры времени или DFSR.

Узкий ключ агента вместо командной строки

Для Zabbix я не включаю общий system.run и тем более wildcard с произвольными аргументами. На контроллере размещается проверенная администратором неизменяемая обёртка, которая сама запускает ровно один утверждённый read-only запрос, принимает ноль внешних параметров, нормализует поля, ограничивает длительность и размер ответа и возвращает структурированную ошибку при усечении. Политика AllowKey разрешает только конкретный ключ ad.replication.readonly через фиксированный UserParameter либо столь же узкое правило, а остальные команды остаются запрещёнными. Путь, владелец и ACL сценария исключают запись со стороны службы агента. Перед применением синтаксис обязательно сверяется с документацией и активной конфигурацией установленной версии Zabbix agent или agent 2, включая порядок AllowKey и DenyKey.

Как реконструкция превращается в доказательство

Финальная временная линия объединяет получателя, источник, раздел, код попытки, последний успех, USN, offset времени и связанное событие. По ней я могу осторожно атрибутировать отказ входящей стороне, исходящему партнёру, топологии, DNS или времени; ветвь DFSR остаётся отдельной. В наших внедрениях это защищает от удобной, но неверной развязки: перезапустить службу и принять исчезнувший симптом за восстановление. После исправления проверяются оба направления сводки, конкретные входящие соседи и продвижение метаданных, а для SYSVOL — его собственные свидетельства. Если картина неоднозначна, вывод так и фиксируется: наблюдений недостаточно, требуются дополнительные read-only данные, а не рискованная команда изменения.

Отвергнутые альтернативы

• Признать репликацию исправной по запущенной NTDS или доступному сервисуРабота службы, портов либо веб-интерфейса подтверждает доступность компонента, но ничего не говорит о прохождении разделов каталога между определёнными партнёрами.
• Назвать Event ID 1311 или 1865 готовым диагнозомЭти события указывают на репликационную или топологическую проблему в своём контексте, однако в одиночку не выбирают между DNS, временем, связью, расписанием и недоступным соседом.
• Считать возраст последнего успеха единым аварийным порогомИнтервалы межсайтовых связей, обслуживание и размер топологии различаются; значение оценивается вместе с расписанием, серией попыток, USN и смещением времени.
• Разрешить system.run с произвольными параметрамиШаблон с подстановкой аргументов создаёт удалённый командный интерфейс; безопаснее отдельный ключ без пользовательского ввода и заранее просмотренный неизменяемый сценарий.

Конфигурация и сбор

Утверждённая роль чтения AD DS и выбранных журналов на перечисленных DC; PowerShell Remoting только к этим узлам через контролируемую конечную точку. Секреты, пароли, экспорт токенов, изменение каталога и членство в привилегированных группах не требуются.

• Проверить версию Windows Server, роль DC, функциональные уровни, владельцев FSMO, редакцию и активные include-файлы Zabbix agent.
• Снять showrepl и replsummary, сохранив соответствие получателя, источника, раздела и кода результата.
• Добавить partner metadata, USN, last success, источник времени и offset для того же временного окна.
• Собрать контекст Directory Service, а сведения DFSR/SYSVOL поместить в отдельную ветвь без учётных данных.

Контролируемая проверка и свидетельство

Контролируемую проверку я провожу только в изолированной лаборатории на тестовых DC. Сначала фиксирую исходную синхронизацию, затем одним заранее обратимым воздействием приостанавливаю репликацию выбранной тестовой пары, не меняя одновременно DNS, время или топологию. Наблюдаю, как showrepl, replsummary, partner metadata и USN отражают именно эту переменную. После снятия паузы подтверждаю успешный цикл и продвижение метаданных; производственные контроллеры в эксперимент не включаются.

Фрагмент рабочего регламента

• Указать утверждённый DC по FQDN и подтвердить его сайт, роль, версию ОС и GUID NTDS Settings.
• Выполнить repadmin /showrepl для входящих соседей и repadmin /replsummary по источникам и получателям.
• Сопоставить партнёра, раздел, LastReplicationSuccess, результат, USN и измеренное расхождение часов.
• Проверить DNS, топологию и события 1311/1865 только в границах найденной пары и временного окна.
• При симптоме политики отдельно собрать DFSR/SYSVOL evidence; nltest и состояние служб оставить контекстом.
• Принять от узкого ключа Zabbix ограниченный ответ, не выполняя удалённых команд с аргументами.

Откат

Откат относится только к единственной лабораторной паузе: я возвращаю изменённое правило или состояние тестовой связи к зафиксированному исходному виду, не трогая остальные параметры. Затем проверяю успешную синхронизацию конкретных партнёров, продвижение USN и, если тест касался SYSVOL, отдельное восстановление DFSR. Производственная конфигурация этим сценарием не изменяется.

Ограничения вывода

Метод не задаёт общего порога лага и не заменяет проектирование сайтов, резервное копирование, authoritative restore либо анализ безопасности. Метки времени и USN интерпретируются только внутри подтверждённой топологии. Ограниченный ответ агента может потерять детали, поэтому при ошибке он ведёт к разрешённому ручному read-only сбору, а не к автоматическому исправлению.