Когда в инфраструктуре остаются контроллеры домена старых версий Windows Server, план модернизации часто выглядит слишком просто: добавить новые DC, перенести роли, вывести старые и повысить функциональный уровень. Проблема в том, что новая версия операционной системы не лечит старый домен. Она лишь наследует его текущее состояние — вместе с ошибками репликации, групповыми политиками и неправильной иерархией времени.
В этой части разберем подготовительный этап модернизации Active Directory на примере домена с двумя виртуальными контроллерами. Перед обновлением пришлось восстановить репликацию SYSVOL, проверить пригодность резервных копий, вернуть NETLOGON и заново выстроить Windows Time. И только после этого домен стал подходящей отправной точкой для ввода новых DC.
Почему нельзя сразу повышать функциональный уровень
Функциональный уровень определяет доступные возможности AD DS и версии Windows Server, которые допустимы в роли контроллеров. Он не исправляет репликацию и не синхронизирует файлы политик. Если SYSVOL уже расходится, повышение уровня только добавит ещё одно крупное изменение к неисправной системе.
Практический критерий готовности другой: каждый контроллер должен видеть одинаковые объекты AD и одинаковое файловое содержимое SYSVOL, публиковать SYSVOL/NETLOGON, проходить dcdiag, иметь согласованное время и восстанавливаться из проверяемой резервной копии.
Первый сюрприз: полная копия ВМ оказалась не тем, чем казалась
Контроллеры работали как ВМ в VMware vCloud Director, резервное копирование выполнял Veeam. Задание завершалось, но в журнале одного DC была строка Guest processing skipped (check VMware Tools status). Образ дисков существовал, однако Veeam не выполнил обработку гостевой Windows.
Для обычного файлового сервера crash-consistent копия часто приемлема как дополнительная страховка. Для Active Directory перед изменением DFSR этого мало. Нужна application-aware обработка на базе VSS: она подготавливает приложения внутри гостевой ОС и создаёт согласованный снимок. Причина оказалась простой — VMware Tools не были установлены. После установки журнал показал инвентаризацию гостевой системы и подготовку к hot backup, а задания обоих DC завершились без ошибок.
| Урок. Active Full и Application-Aware Processing отвечают за разные свойства backup. Первое — за цепочку резервных данных, второе — за согласованность приложений внутри Windows. |
Второй уровень страховки: отдельная копия GPO и SYSVOL
Даже при наличии Veeam перед авторитетной синхронизацией полезно сохранить GPO штатным Backup-GPO и скопировать SYSVOL с контроллера, которому мы доверяем как источнику. Это не заменяет System State или application-aware backup, но позволяет отдельно восстановить политики и проверить их состав.
| Import-Module GroupPolicy Backup-GPO -All -Path ‘X:\AD-Recovery\GPO’ robocopy ‘C:\Windows\SYSVOL\domain’ ‘X:\AD-Recovery\SYSVOL’ /E /COPYALL /DCOPY:DAT /XJ /R:1 /W:1 |
В нашем случае Backup-GPO сохранил пять политик, robocopy завершился с кодом 1, а gpt.ini Default Domain Policy присутствовал в копии. Код robocopy от 0 до 7 не считается ошибкой; 8 и выше требует остановки и разбора.
Авторитетный и неавторитетный участники: что мы фактически делаем
Для DFSR нет реестровых BurFlags D2/D4, знакомых по FRS. Microsoft использует атрибуты подписки SYSVOL в Active Directory. На доверенном DC1 подписка временно отключается и выставляется msDFSR-Options=1 — он становится авторитетным. На всех остальных DC подписка также отключается, но без флага авторитетности. После репликации AD DS участники включаются строго по порядку.
| Контроллер | Отключение | Инициализация | Ключевое событие |
| DC1 | msDFSR-Enabled=False; Options=1 | Авторитетная | 4602 |
| DC2 | msDFSR-Enabled=False | Неавторитетная от DC1 | 4614 → 4604 |
Сначала DFSR останавливается на всех DC и переводится в Manual. После изменения атрибутов обязательно форсируется и проверяется репликация AD DS. Затем запускается только DC1: событие 4114 подтверждает отключённую подписку. Подписка DC1 включается, выполняется dfsrdiag pollad, и событие 4602 фиксирует назначенного основного участника.
Только после 4602 запускается DC2. Он также должен сначала зарегистрировать 4114. После включения подписки и pollad появляются 4614 — ожидание initial sync — и 4604 — синхронизация завершена. Если включить второй контроллер раньше или сделать несколько DC авторитетными, можно получить конкурирующие источники и конфликты файлов.
| Стоп-условие. Нет 4602 на авторитетном DC — не запускаем остальные. Есть ошибки repadmin — не выполняем pollad. Это не бюрократия, а защита от размножения повреждённого состояния. |
Почему после успешного 4604 мог не появиться NETLOGON
На DC2 событие 4604 появилось, SYSVOL был опубликован, а NETLOGON — нет. Проверка показала: Netlogon работает, SysvolReady=1, оба пути scripts существуют. То есть файловая репликация завершилась, но служба не опубликовала ресурс.
Переключение SysvolReady 1→0→1 не помогло. Контролируемый перезапуск Netlogon заставил службу перечитать состояние, после чего NETLOGON появился с правильным путём. Ручное создание SMB-ресурса в таком сценарии было бы неправильным: оно маскирует неисправность механизма контроллера домена.
Контроль, без которого нельзя считать SYSVOL исправленным
| repadmin /replsummary repadmin /showrepl * /errorsonly dcdiag /s:DC-A /test:Advertising /test:SysVolCheck /test:NetLogons dfsrdiag backlog /rgname:»Domain System Volume» /rfname:»SYSVOL Share» /smem:DC1 /rmem:DC2 |
В результате AD DS реплицировался без ошибок, оба контроллера публиковали SYSVOL и NETLOGON, количество каталогов GPO совпало, а backlog DFSR отсутствовал в обоих направлениях. Но dcdiag на DC2 всё ещё проваливал Advertising: контроллер не объявлялся сервером времени.
Отдельная неисправность: все DC ходили к несуществующему NTP
w32tm показал на DC2 Free-running System Clock, stratum 0 и отсутствие успешной синхронизации. Конфигурация объяснила причину: Type=NTP и один внешний узел были навязаны политикой обоим контроллерам. Само имя внешнего NTP возвращало NXDOMAIN. Более того, оно было продублировано в двух общих GPO.
В домене должна работать иерархия: только PDC Emulator корневого домена получает время извне; остальные DC используют NT5DS и доверенную доменную синхронизацию. Общие NTP-настройки убрали из двух GPO, для PDC применили отдельную политику с WMI-фильтром DomainRole=5, а DC2 вернули к NT5DS.
| SELECT * FROM Win32_ComputerSystem WHERE DomainRole = 5 |
Перед заменой источника проверили DNS и UDP/123 через w32tm /stripchart. time.windows.com отвечал, смещение было менее секунды. VMware Tools Time Sync на обеих ВМ оказался отключён, поэтому с W32Time не конкурировал.
| Контроллер | Итоговый источник | Type | Stratum |
| DC1 / PDC | time.windows.com,0x9 | NTP | 5 |
| DC2 | DC2 | NT5DS | 6 |
После resync второй контроллер получил время от PDC, смещение составило около 16 мс, а Advertising, SysVolCheck и NetLogons прошли. На этом подготовительный этап можно было закрывать.
Что этот кейс меняет в плане модернизации
Теперь можно переходить к следующей части: инвентаризации DFL/FFL и schema, проверке FSMO/DNS/GC, резервированию AD CS, проектированию новых DC и поэтапному выводу старых. Повышение функционального уровня выполняется в конце, когда в домене не осталось несовместимых контроллеров и каждый предыдущий шаг подтверждён диагностикой.
| Практический вывод. Не начинайте модернизацию Active Directory с установки новой Windows Server. Начните с доказательства того, что текущий домен одинаково работает на каждом DC и способен восстановиться. |