Как проверить репликацию домена Active Directory
Репликация домена Active Directory обеспечивает синхронизацию учетных записей, групп, политик, DNS-зон и других объектов между контроллерами домена. Если она работает с ошибками, пользователи могут получать разные результаты при входе на разные серверы, новые пароли не применяются, а групповые политики обновляются не везде. Регулярная проверка репликации позволяет обнаружить проблему до того, как она повлияет на работу инфраструктуры.
Что нужно проверить перед диагностикой
Для проверки потребуются права администратора домена или разрешения на просмотр состояния репликации. Выполнять команды лучше непосредственно на контроллере домена либо с административной рабочей станции, где установлены средства удаленного администрирования. Важно убедиться, что контроллеры включены, доступны по сети и используют корректные DNS-серверы.
Каждый контроллер домена должен разрешать имена остальных контроллеров через внутреннюю DNS-зону Active Directory. В настройках сетевого адаптера не следует указывать публичные DNS-серверы как основные: это часто приводит к ошибкам поиска партнеров репликации. Также проверьте синхронизацию времени. Существенное расхождение часов вызывает проблемы с аутентификацией Kerberos и может косвенно нарушать обмен данными между серверами.
Быстрая проверка состояния репликации
Основной инструмент диагностики — repadmin. Команда repadmin /replsummary выводит сводку по входящей и исходящей репликации: количество ошибок, процент неудачных попыток и время последнего успешного обмена. В исправной среде число ошибок должно быть нулевым, а время последней успешной репликации не должно заметно превышать обычный интервал для вашей топологии.
Для детального просмотра используйте repadmin /showrepl. Команда показывает партнеров конкретного контроллера, разделы каталога, дату последней успешной синхронизации и код последней ошибки. Особенно внимательно изучайте разделы Domain, Configuration, Schema и DNS-зоны, интегрированные в Active Directory. Ошибка по одному разделу может не проявляться в остальных, но все равно привести к неполной синхронизации объектов.
Если требуется проверить все контроллеры, полезна команда repadmin /showrepl * /csv. Ее результат удобно сохранить и проанализировать: так проще найти сервер, который не получает изменения или долго не отправляет их партнерам. После исправления причин можно инициировать синхронизацию командой repadmin /syncall с параметрами для обхода всех партнеров.
Как интерпретировать типовые ошибки
Ошибки репликации часто связаны не с самой базой Active Directory, а с сетевой инфраструктурой. Сообщения о невозможности найти сервер RPC обычно указывают на проблемы с DNS, маршрутизацией, межсетевым экраном или отключенными службами. Необходимо проверить разрешение имен, доступность нужного контроллера по сети и правила, разрешающие RPC-трафик между серверами.
Ошибка отказа в доступе может означать нарушение доверительных отношений между контроллерами, проблемы с учетной записью компьютера сервера или рассинхронизацию времени. В такой ситуации нельзя сразу удалять контроллер из домена: сначала проверьте журнал Directory Service, системный журнал, состояние безопасного канала и актуальность времени.
Сообщения о длительном отсутствии репликации требуют особого внимания. Контроллер, который не синхронизировался длительный период, может содержать устаревшие объекты. Принудительная репликация не всегда безопасна: сначала определите, не превышен ли допустимый срок хранения удаленных объектов в лесу. При серьезном отставании может потребоваться корректное удаление проблемного контроллера и его повторное введение в домен.
Проверка DNS, служб и журналов событий
DNS является критически важной частью репликации. Проверьте, что на каждом контроллере есть актуальные записи хоста и служебные записи в зоне домена. Команда dcdiag /test:dns помогает выявить ошибки регистрации записей, делегирования и разрешения имен. Для общей проверки состояния контроллера можно запустить dcdiag /v: расширенный отчет покажет проблемы с рекламированием служб, сетевым подключением, SYSVOL и другими компонентами.
В Просмотре событий анализируйте журналы Directory Service, DNS Server, DFS Replication и System. События следует сопоставлять по времени с ошибками repadmin. Например, сбой DFS Replication способен привести к тому, что объекты Active Directory реплицируются, а содержимое SYSVOL с групповыми политиками — нет. Поэтому проверка только каталога не гарантирует полную исправность доменной инфраструктуры.
Убедитесь, что работают службы Active Directory Domain Services, DNS Server при его использовании на контроллере, Netlogon, Kerberos Key Distribution Center и DFS Replication. После восстановления сети или DNS иногда требуется перерегистрировать записи Netlogon, перезапустить службу или выполнить контролируемую синхронизацию, но такие действия нужно фиксировать в журнале изменений.
Безопасный порядок устранения неполадок
Начинайте с определения масштаба проблемы: затронут один контроллер, один сайт или весь домен. Затем проверьте сетевую доступность, разрешение DNS-имен, время, свободное место на дисках и состояние служб. После этого изучите вывод repadmin /showrepl и журналы событий, чтобы установить точную причину, а не устранять последствия.
Не удаляйте объекты подключения, не запускайте принудительную синхронизацию и не выполняйте очистку метаданных без понимания топологии и состояния остальных контроллеров. Перед значимыми изменениями убедитесь в наличии актуальной резервной копии состояния системы хотя бы одного исправного контроллера. После исправления повторите repadmin /replsummary, проверьте репликацию всех разделов и убедитесь, что изменения учетной записи или тестовой группы появились на каждом контроллере.
Для постоянного контроля полезно настроить регулярный сбор отчетов repadmin и уведомления при росте числа ошибок или увеличении времени последней успешной репликации. Такой подход помогает выявлять недоступные филиалы, неверно настроенные DNS-серверы и проблемы каналов связи до того, как они станут критичными.