Как проверить состояние Active Directory перед изменениями

Зафиксируйте границы и исходное состояние

Изменения в доменной инфраструктуре нельзя начинать с предположения, что она исправна. Ошибка репликации, устаревшая DNS-запись или недоступный контроллер могли существовать неделями, а обновление или перезагрузка лишь сделают проблему заметной. До окна работ определите, что именно меняется: операционная система контроллера, функциональный уровень, схема, DNS, топология сайтов, групповая политика или состав контроллеров. Для каждого изменения нужен собственный критерий успеха и отката.

Соберите перечень доменов и доверительных отношений, контроллеров, глобальных каталогов, сайтов, подсетей и владельцев FSMO-ролей. Запишите версии Windows Server, IP-адреса, источники времени, состояние виртуализации и наличие физического или консольного доступа. В многодоменном лесу диагностика одного домена недостаточна: проблемы разделов Configuration и Schema могут проявляться на контроллерах других доменов.

Сохраняйте вывод команд в каталог заявки с датой и временем, но не отправляйте его в публичные сервисы. Диагностика раскрывает DNS-имена, адреса, структуру OU и иногда имена учётных записей. В журнале работ отдельно отметьте уже известные предупреждения и согласованные исключения, чтобы после изменения не принять старое событие за новый дефект.

Проверьте доступность, время и базовые службы

Сначала исключите инфраструктурные причины. Все контроллеры должны разрешать имена друг друга через внутренний DNS и обмениваться трафиком по требуемым портам. Проверяйте не только ICMP: успешный ping не подтверждает доступность RPC, LDAP, Kerberos, SMB и динамического диапазона RPC. Если между сайтами установлен firewall, сопоставьте его правила с актуальными требованиями Microsoft и журналами блокировок.

Kerberos чувствителен к расхождению времени. Эмулятор PDC корневого домена леса обычно синхронизируется с надёжным внешним источником, остальные доменные узлы следуют иерархии домена. Проверьте источник и смещение на каждом контроллере. Ручная настройка одного узла на случайный публичный NTP-сервер нарушает предсказуемую модель времени и затрудняет диагностику.

Убедитесь, что службы Active Directory Domain Services, DNS Server, Kerberos Key Distribution Center, Netlogon и DFS Replication работают в соответствии с ролью узла. Незапущенная служба — симптом, а не основание сразу менять тип запуска: сначала изучите системный журнал и зависимости. Также проверьте свободное место на томах с NTDS, SYSVOL и журналами; дефицит места способен остановить нормальную работу базы и репликации.

w32tm /query /status
w32tm /monitor
sc.exe query ntds
sc.exe query netlogon
Get-Volume | Sort-Object DriveLetter | Format-Table DriveLetter, SizeRemaining, Size

Выполните dcdiag осмысленно

Dcdiag запускайте из повышенной консоли учётной записью, которой достаточно прав для диагностики. Общий прогон по предприятию даёт удобную исходную картину, но его объём велик. Сначала сохраните полный результат, затем повторите отдельные тесты для проблемного контроллера. Не оценивайте состояние только по последней строке: предупреждение выше по выводу может объяснять периодические ошибки, даже если итоговый тест отмечен как успешный.

Особое внимание уделите Advertising, Services, Replications, SysVolCheck, NetLogons и DNS. Тест DNS с ключом /e охватывает контроллеры предприятия, а /v добавляет детали. Некоторые проверки зависят от сетевой доступности и полномочий, поэтому Access denied или RPC unavailable нельзя автоматически считать повреждением AD: подтвердите контекст запуска, разрешение имени, маршрут и firewall.

Разбирайте каждую ошибку по первопричине и повторяйте только связанный тест после исправления. Массовый перезапуск служб, очистка журналов или принудительная регистрация всех DNS-записей до диагностики уничтожает полезные признаки. Цель проверки — получить объяснимое состояние, а не любой ценой добиться визуально чистого вывода.

dcdiag /e /c /v /f:C:\Temp\dcdiag-full.txt
dcdiag /s:DC01 /test:Advertising /test:Services /v
dcdiag /e /test:DNS /v /f:C:\Temp\dcdiag-dns.txt
dcdiag /s:DC01 /test:SysVolCheck /test:NetLogons

Параметры и состав тестов различаются в зависимости от роли и версии системы; перед автоматизацией сверяйте синтаксис со справкой dcdiag.

Разберите репликацию через repadmin

Сводка repadmin показывает долю ошибок и максимальную задержку по входящей и исходящей репликации. Нулевая доля ошибок важна, но недостаточна: контроллер, который давно не участвовал в репликации, может отсутствовать в ожидаемом контексте или показывать большую delta. Сопоставьте список со своей инвентаризацией и убедитесь, что в нём присутствуют все действующие контроллеры.

Для каждой ошибки откройте подробности входящих партнёров и определите раздел каталога, время последней попытки, время последнего успеха и код результата. Разделы DomainDnsZones и ForestDnsZones так же важны, как доменный раздел: сбой их репликации создаёт расхождения DNS. Коды RPC, DNS lookup failure и target principal name incorrect требуют разных действий; принудительная синхронизация без устранения причины только повторяет ошибку.

Команду синхронизации не используйте как универсальное лечение. Сначала восстановите DNS, время, secure channel или сетевую связность, затем подтвердите штатную репликацию. Если контроллер был изолирован дольше срока жизни tombstone, не подключайте его вслепую: оцените поддерживаемый сценарий удаления метаданных или восстановления по документации Microsoft.

1. Сохранить repadmin /replsummary и проверить список всех контроллеров.
2. Открыть repadmin /showrepl для узла с ошибкой и определить затронутый раздел.
3. Расшифровать код через repadmin /showrepl * /errorsonly и системные журналы.
4. Устранить первопричину, дождаться штатного цикла и повторить сводку.
5. Сравнить результат с исходным файлом и приложить его к протоколу работ.

repadmin /replsummary
repadmin /showrepl * /csv > C:\Temp\showrepl.csv
repadmin /showrepl DC01 /all /verbose
repadmin /showrepl * /errorsonly

Проверьте DNS, SYSVOL и групповые политики

Active Directory использует DNS для поиска контроллеров и служб. На сетевых интерфейсах контроллеров указывают DNS-серверы, обслуживающие доменные зоны; адрес провайдера или публичный resolver там не заменяет внутренний DNS. Проверьте SRV-записи _ldap и _kerberos, записи контроллеров, делегирование дочерних зон и обратное разрешение там, где оно входит в эксплуатационный стандарт.

Сравните содержимое SYSVOL и состояние DFS Replication. Общие папки SYSVOL и NETLOGON должны публиковаться, а журнал DFS Replication не должен содержать необъяснённых повторяющихся ошибок. Наличие файлов на одном контроллере не доказывает их репликацию. Для критичных GPO сравните версии в Group Policy Management и убедитесь, что клиент получает политику от ожидаемого контроллера.

Не удаляйте DNS-записи только потому, что они кажутся старыми. Сначала определите владельца адреса, настройки scavenging и связи с отключёнными, но ещё не выведенными контроллерами. Аналогично не копируйте SYSVOL вручную между рабочими контроллерами: для восстановления DFSR существуют документированные процедуры с авторитетной и неавторитетной синхронизацией.

nslookup -type=SRV _ldap._tcp.dc._msdcs.contoso.local
nslookup -type=SRV _kerberos._tcp.contoso.local
net share
dfsrdiag ReplicationState
dcdiag /test:DNS /DnsRecordRegistration

Сопоставьте журналы и резервное копирование

Просмотрите Directory Service, DNS Server, DFS Replication и System как минимум за период, покрывающий несколько циклов репликации и недавние перезагрузки. Важна последовательность: сетевой разрыв может породить вторичные события DNS, Kerberos и репликации. Фильтрация только по уровню Error скрывает предупреждения, которые предшествуют отказу, а чтение одного события без соседних записей часто ведёт к неверному выводу.

До изменения должна существовать актуальная резервная копия, пригодность которой подтверждена процедурой восстановления. Для контроллеров домена учитывайте System State и особенности безопасного восстановления AD DS. Snapshot виртуальной машины не равнозначен полноценной стратегии резервного копирования; поддержка VM-Generation ID снижает часть рисков виртуализации, но не отменяет независимую копию и регламент восстановления.

Проверьте, кто имеет доступ к backup, где хранятся ключи шифрования и как действовать при недоступности доменных учётных записей. План отката должен учитывать необратимые или распределённые операции. Например, изменение схемы нельзя рассматривать как обычный файл, который возвращается копированием; перед таким действием особенно важны совместимость, резервирование и отдельный план восстановления леса.

• Нет повторяющихся необъяснённых ошибок NTDS, DNS и DFSR.
• Последний backup завершён успешно и соответствует принятому RPO.
• Известно местонахождение копии и доступны отдельные учётные данные.
• Инструкция restore проверена, а ответственные знают порядок эскалации.

Примите решение по измеримым критериям

Готовность — это не отсутствие красных строк любой ценой, а документированное понимание состояния. Все ожидаемые контроллеры доступны, репликация разделов проходит без ошибок в допустимом интервале, DNS возвращает корректные записи, SYSVOL опубликован и согласован, время следует утверждённой иерархии, а свободного места достаточно для операции и отката. Известные предупреждения должны иметь владельца и объяснение.

Для окна работ подготовьте порядок действий, контрольные точки и условия остановки. После каждого значимого этапа повторяйте ограниченный набор проверок: доступность, dcdiag для затронутого узла, сводку репликации, DNS и журналы. Если появился новый класс ошибок, не продолжайте план автоматически. Зафиксируйте время возникновения и решите, безопаснее ли устранить проблему или выполнить согласованный откат.

После завершения выдержите период наблюдения, включающий штатные циклы репликации и применение политик. Сравните результаты с baseline, проверьте аутентификацию тестового пользователя и доступ к зависимым сервисам. Итоговый протокол должен содержать фактические команды, результаты, отклонения и дальнейшие действия — этого достаточно для воспроизводимости без выдуманных оценок надёжности.

• Инвентаризация совпадает с фактическим списком контроллеров и FSMO.
• Dcdiag и repadmin не содержат необъяснённых сбоев.
• DNS, время, SYSVOL и Netlogon проверены отдельно.
• Резервная копия и процедура восстановления доступны.
• Определены контрольные точки, условия остановки и план отката.
• Назначено наблюдение после изменения.