Откатил оба контроллера Windows Server 2025 к снимкам: AD реплицируется, а SYSVOL остановился — почему VM-Generation ID не восстановил всё

<p>Классическая ловушка виртуализированного домена: откатили два контроллера Windows Server 2025 к снимкам гипервизора, репликация Active Directory поднялась сама — спасибо VM-Generation ID, — а SYSVOL встал намертво, GPO не применяются, Netlogon-шара то есть, то нет. В карточках инцидента это обычно списывают на «баг DFSR», хотя на деле это ожидаемое поведение двух разных защитных механизмов, один из которых просто не покрывает файловую репликацию. Разбираю, что на самом деле спасает VM-Generation ID, почему SYSVOL остаётся без прикрытия, и как мы поднимаем такие домены без переустановки контроллеров — с точными атрибутами, событиями и командами.</p>

Что произошло: инцидент, который мы разбирали у клиента на WS2025

Ситуация типична для инфраструктуры юрлица на 30–50 рабочих мест с одним сайтом Active Directory и двумя контроллерами домена на Windows Server 2025 под Hyper-V. Перед рискованным обновлением GPO администратор снял контрольные точки (checkpoint) на обоих DC почти одновременно — с разницей в пару минут. Обновление пошло не так: часть политик применилась некорректно, decided откатить обе машины к снимкам. Откат тоже прошёл почти синхронно.

После старта обеих машин картина была обнадёживающей: repadmin /showrepl не показывал ошибок 8606/8614/2042, входящая и исходящая репликация Active Directory шла, объекты сходились. Но на одном из контроллеров пропала шара \\DC02\SYSVOL, вторая половина групповых политик не применялась на рабочих станциях, а dfsrdiag replicationstate показывал бэклог, который не двигался часами. Дальше — разбор, почему так вышло и что с этим делать без переустановки контроллеров с нуля.

Почему вообще снимали checkpoint на обоих DC разом, а не по очереди: администратор клиента рассуждал логично с точки зрения гипервизора — «если что-то пойдёт не так с групповыми политиками, откачусь и посмотрю по журналам, что случилось», не разделяя в голове два разных домена риска — состояние базы AD и состояние файлового ресурса SYSVOL. Это типичная ошибка, и мы видим её не первый раз: снимок воспринимается как универсальная страховка «для всего сервера», хотя контроллер домена — это фактически два независимых хранилища с разной логикой консистентности, живущих в одной ОС.

Бизнес-последствие было ощутимым в течение суток: у пользователей, чьи компьютеры проходили обновление групповой политики именно через застрявший DC, перестали применяться новые правила блокировки USB-накопителей — то есть контроль, ради которого всё затевалось, фактически отключился на части парка, оставшись формально включённым в консоли GPMC.

VM-Generation ID: что он реально защищает — и это не файлы

С Windows Server 2012 контроллеры домена на гипервизорах, поддерживающих VM-Generation ID (Hyper-V, а также VMware vSphere при поддержанной версии виртуального железа), получают отдельный идентификатор поколения виртуальной машины. Значение хранится в атрибуте msDS-GenerationId объекта компьютера DC в самой базе AD (NTDS.dit) и параллельно экспонируется гипервизором в гостевую ОС через ACPI-таблицу материнской платы виртуальной машины.

При каждой загрузке DC, а также периодически во время работы, служба каталогов сравнивает значение, которое отдаёт гипервизор, со значением, сохранённым в DIT. Если они расходятся — а расходятся они именно тогда, когда применили снимок, склонировали ВМ или восстановили её из бэкапа гипервизора, — AD DS выполняет две вещи: сбрасывает invocationID контроллера и отбрасывает выданный ему пул RID. Сброс invocationID меняет «личность» источника изменений с точки зрения репликации, поэтому USN, которые контроллер уже разослал партнёрам до отката, больше не пересекаются с USN, которые он начнёт генерировать после отката — то есть исключается повторное использование номеров обновлений (USN reuse), а значит и классический USN rollback базы AD.

Проверить текущее значение после инцидента можно так:

Get-ADComputer -Identity DC02 -Properties msDS-GenerationId, whenChanged

Ключевой момент для разбора именно этого инцидента: весь механизм целиком живёт внутри процесса lsass.exe/ntdsa.dll и оперирует только базой NTDS.dit. Он не знает о существовании SYSVOL как отдельного файлового ресурса и ничего не делает для DFS Replication — это отдельная служба со своим движком версионирования.

Важные практические условия работы механизма, которые мы всегда проверяем на аудите инфраструктуры: функция требует, чтобы гипервизор явно поддерживал VM-Generation ID (для Hyper-V это Windows Server 2012 и новее, для ВМ второго поколения поддержка идёт «из коробки»; для VMware vSphere нужна согласованная версия виртуального железа и включённая опция генерации ID), а сама гостевая ОС контроллера — Windows Server 2012 и новее, куда входит и Windows Server 2025 из нашего кейса. Если хотя бы одно из условий не выполняется — например, ВМ мигрировала со старого гипервизора без переноса конфигурации виртуального железа, — проверка тихо не срабатывает, и тогда откат снимка приводит уже к полноценному USN rollback базы AD, а не к штатному сбросу invocationID.

Отдельно стоит отметить, что отброшенный пул RID — это не побочный эффект, а часть той же защиты: если бы контроллер после отката продолжил выдавать идентификаторы безопасности (SID) из старого пула RID, который он уже частично раздал новым объектам до отката, это создало бы дублирующиеся SID у разных учётных записей в лесу. Запрос нового пула у хозяина операций RID (RID Master) при следующей же выдаче закрывает и этот риск.

Почему из двух хранилищ на контроллере защищено только одно

На контроллере домена фактически два независимых репликационных механизма. Первый — сама Active Directory (NTDS.dit), где каждое изменение атрибута получает USN в разрезе конкретного invocationID, и именно этот механизм прикрыт VM-Generation ID. Второй — DFS Replication, который реплицирует SYSVOL (GPO, скрипты входа, NETLOGON) как обычные файлы на NTFS-томе. У DFSR своя система отслеживания изменений: она построена на журнале изменений NTFS (USN Journal) конкретного тома, где физически лежит SYSVOL, плюс на собственных векторах версий (version vector) для каждой реплицируемой папки.

Служба DFSR (Dfsr.exe) не читает атрибут msDS-GenerationId и никак не участвует в проверке VM-Generation ID — это зона ответственности исключительно NTDS. Поэтому откат снимка одинаково затрагивает оба тома (том с NTDS.dit и том с SYSVOL), но защищённой от последствий оказывается только база каталога. Журнал изменений NTFS на томе SYSVOL после отката снимка может быть инвалидирован гипервизором так же, как и любой другой USN Journal — это стандартное поведение NTFS при откате состояния тома, если снимок делался средствами гипервизора, а не VSS-совместимым бэкапом.

Отсюда практическое правило, которое мы формулируем клиентам: снимок гипервизора (checkpoint/snapshot) — это не то же самое, что wbadmin start systemstatebackup. Системный бэкап состояния идёт через VSS-writer NTDS и вызывает у DFSR собственную процедуру подготовки, которая корректно помечает реплицируемые папки для последующего безопасного восстановления. Обычный снимок гипервизора такой подготовки не делает — с точки зрения DFSR это внешнее, неконтролируемое изменение тома.

Хорошая аналогия для объяснения руководству без глубокого технического бэкграунда: представьте, что на одном сервере живут два разных архива с разными системами инвентарных номеров. Один архив (AD) получил современную сигнализацию, которая понимает, что его кто-то тайком подменил чужой копией, и сама пересчитывает номера, чтобы не было путаницы. Второй архив (SYSVOL) — обычная картотека без сигнализации: если её подменили, об этом узнают только тогда, когда два хранителя картотеки начнут сверяться друг с другом и обнаружат нестыковку. VM-Generation ID — это сигнализация только для первого архива.

Это принципиально отличается от того, как раньше (до перехода на DFSR) работала легаси-служба FRS: у неё тоже не было интеграции с VM-Generation ID, и рекомендации Microsoft по безопасной виртуализации контроллеров домена изначально писались с оговоркой «SYSVOL нужно восстанавливать отдельно» — это не новая проблема DFSR, а исторически известное ограничение всей модели виртуализации DC, которое просто продолжает действовать и в Windows Server 2025.

Как выглядит USN rollback на стороне AD, если защита всё же не сработала

Если VM-Generation ID недоступен (старый гипервизор, отключённая функция генерации ID на ВМ) или сравнение по какой-то причине не отработало, откат снимка приводит к классическому USN rollback — партнёр по репликации получает от контроллера USN, который уже был подтверждён ранее, без изменения invocationID. Это фиксируется событием в журнале Directory Service, и последствия наступают быстро: служба Netlogon на пострадавшем контроллере приостанавливается, входящая и исходящая репликация AD отключаются, чтобы не расползлись рассинхронизированные объекты и не возникли lingering objects.

В нашем разобранном случае VM-Generation ID сработал штатно — событие 2095 в логе не появилось, invocationID сбросился тихо, репликация AD поднялась сама. Проблема лежала полностью на стороне DFSR, и там события были совсем другие.

Если бы в нашем случае VM-Generation ID не сработал, дополнительным индикатором в repadmin /showrepl стали бы коды ошибок 8606 (недостаточно атрибутов для репликации, часто сопутствует USN rollback), 8614 (исходный USN уже обработан) или 2042 (партнёр слишком долго не реплицировался — превышен tombstone lifetime). Ни одного из них в нашем логе не было — ещё одно подтверждение, что защита базы AD отработала штатно, а сломалась именно файловая часть.

Практический вывод для дежурной диагностики: увидев расхождение SYSVOL при чистом repadmin /showrepl, не тратьте время на поиск проблем в самой Active Directory — сразу переключайтесь на журнал «DFS Replication» и команды dfsrdiag, потому что причина гарантированно лежит в файловой репликации, а не в базе каталога.

Что видно в логе DFS Replication: события 4012, 4114, 4602, 4614

После отката снимка на обоих DC одновременно у DFSR не осталось ни одного члена группы репликации, который бы однозначно считал себя «источником истины» — оба участника видят один и тот же реплицируемый набор файлов, но с расходящимися версиями, и без явной команды администратора движок не берёт на себя решение, чья копия правильная. В журнале «DFS Replication» на пострадавшем контроллере мы увидели такую последовательность.

Обратите внимание: в Windows Server 2025, как и во всех поддерживаемых версиях начиная с 2008 R2, легаси-служба FRS для SYSVOL отсутствует физически — весь SYSVOL живёт исключительно на DFSR, поэтому альтернативного пути через ntfrsutl или D2/D4 в терминах старого FRS просто не существует. Восстановление делается только через атрибуты DFSR.

Полезно также свериться с состоянием миграции DFSR для SYSVOL — командой dfsrmig /getglobalstate проверяем, что домен действительно находится в финальном состоянии Eliminated (легаси FRS полностью отключён и удалён), а не завис в промежуточном состоянии миграции: в редких случаях у доменов, поднятых очень давно и апгрейженных через несколько версий Windows Server, миграция с FRS на DFSR формально не была завершена, и тогда откат снимка даёт ещё более запутанную картину с параллельно живущими механизмами.

Диагностика за 15 минут: команды, которые мы гоняем первыми

Прежде чем трогать атрибуты в AD, мы всегда снимаем полную картину — репликацию AD отдельно от репликации SYSVOL, потому что как раз в этом разрезе кроется диагноз.

# Репликация самой Active Directory — база должна быть чистой
repadmin /showrepl * /csv > showrepl.csv
repadmin /replsummary

# Состояние DFS Replication конкретно
dfsrdiag replicationstate
Get-DfsrState -ComputerName DC01
Get-DfsrState -ComputerName DC02

# Принудительный опрос AD службой DFSR (вместо ожидания дефолтного интервала polling)
dfsrdiag pollad

# Здоровье SYSVOL и репликации на уровне dcdiag
dcdiag /test:dfsrevent /test:sysvolcheck /test:advertising /v

# Последние 50 событий журнала DFS Replication
Get-WinEvent -LogName "DFS Replication" -MaxEvents 50 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message

Если repadmin /showrepl чистый, а dfsrdiag replicationstate показывает зависший backlog или ошибки в бэклоге между членами, — это ровно наш сценарий: AD здорова, SYSVOL — нет. Дополнительно стоит вручную сравнить содержимое C:\Windows\SYSVOL\domain\Policies на обоих DC и версии gpt.ini внутри каждой папки GPO — расхождение номера Version в файле с номером в атрибуте versionNumber объекта GroupPolicyContainer в AD прямо указывает, какая копия отстала.

Как читать результат: Get-DfsrState для здорового члена группы репликации покажет пустой список активных операций (Idle) — если вместо этого висит операция инициализации или backlog не нулевой уже несколько часов после отката, это подтверждает диагноз «файловая репликация не может согласовать версии сама». Отдельно смотрим на dcdiag /test:sysvolcheck — он проверяет именно доступность и регистрацию share SYSVOL/NETLOGON в реестре и в AD, что отличается от проверки самого содержимого файлов.

Восстановление SYSVOL: authoritative и non-authoritative через ADSI

Логика та же, что у старого D4/D2 для FRS, но выполняется через атрибуты объекта подписки DFSR в Active Directory, а не через реестр. Объект подписки лежит по пути CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<ИмяDC>,OU=Domain Controllers,DC=.... Порядок действий такой.

Шаг 1. Выбираем авторитетный DC. Сравниваем даты изменения GPO, версии gpt.ini и, если есть сомнения, содержимое скриптов входа — выбираем контроллер с самой полной и свежей копией SYSVOL на момент до инцидента.

# На АВТОРИТЕТНОМ контроллере (например DC01)
$dn = "CN=DC01,OU=Domain Controllers,DC=corp,DC=example,DC=ru," +
      "CN=DFSR-LocalSettings,CN=Domain System Volume,CN=SYSVOL Subscription"

Set-ADObject -Identity $dn -Replace @{ 'msDFSR-Enabled' = 'FALSE' }
dfsrdiag pollad
# дождаться Event ID 4114 в журнале DFS Replication на DC01

Set-ADObject -Identity $dn -Replace @{ 'msDFSR-Options' = '1' }
Set-ADObject -Identity $dn -Replace @{ 'msDFSR-Enabled'  = 'TRUE' }
dfsrdiag pollad
# дождаться Event ID 4602 (SYSVOL has been initialized) на DC01

Шаг 2. На всех остальных DC делаем нессимметричное восстановление — их локальная копия SYSVOL будет полностью затёрта копией с авторитетного источника.

# На НЕ-авторитетном контроллере (например DC02)
$dn = "CN=DC02,OU=Domain Controllers,DC=corp,DC=example,DC=ru," +
      "CN=DFSR-LocalSettings,CN=Domain System Volume,CN=SYSVOL Subscription"

Set-ADObject -Identity $dn -Replace @{ 'msDFSR-Enabled' = 'FALSE' }
dfsrdiag pollad
# дождаться Event ID 4114 на DC02

Set-ADObject -Identity $dn -Replace @{ 'msDFSR-Enabled' = 'TRUE' }
dfsrdiag pollad
# дождаться Event ID 4614 / 4604 — начальная синхронизация от DC01 завершена

После этого шага проверяем результат тем же dfsrdiag replicationstate и убеждаемся, что папка NETLOGON и SYSVOL снова расшарены на всех DC (net share), а GPO применяются на тестовой рабочей станции через gpupdate /force и gpresult /h report.html.

Перед тем как запускать процедуру, обязательно снимаем резервную копию текущего состояния SYSVOL на обоих DC (простое robocopy C:\Windows\SYSVOL\domain D:\sysvol_backup_precheck /MIR /B) — операция необратимая, не-авторитетные участники теряют свою локальную версию файлов безвозвратно. Если после отката снимка есть сомнение, что даже «авторитетная» копия могла потерять пару последних изменений GPO, эта резервная копия — единственный способ потом руками долить недостающее.

Ещё один нюанс, который мы всегда проговариваем с клиентом до начала: пока идёт процедура (между установкой msDFSR-Enabled=FALSE и появлением финальных событий 4602/4614), групповые политики на затронутых DC временно недоступны для авторизации новых изменений через GPMC — редактировать GPO в этом окне не стоит, чтобы не создать ещё один конфликт версий поверх уже идущего восстановления.

Как мы предотвращаем это заранее — методология ITfresh

Для клиентов с виртуализированными контроллерами мы закладываем три правила ещё на этапе проектирования домена, до первого инцидента, а не после.

Первое правило — снимок ВМ контроллера домена мы рассматриваем как операцию того же класса риска, что клонирование или P2V, и никогда не делаем снимки двух DC одного сайта в одно окно без выделенного «золотого» контроллера, который остаётся нетронутым. Второе — регулярный wbadmin start systemstatebackup по расписанию на каждый DC как основной инструмент восстановления, снимок гипервизора — только вспомогательная страховка перед рискованным изменением, и никогда не единственная копия. Третье — мониторинг: у клиентов на нашей площадке Zabbix мы заводим отдельные триггеры на события 2095, 4012 и 2213 в соответствующих журналах, чтобы увидеть расхождение SYSVOL в течение часа, а не когда сотрудники пожалуются, что новая политика паролей не долетела до половины парка.

Чек-лист, который мы прикладываем к каждому клиенту с виртуализированными DC перед любым плановым обслуживанием: (1) определить «золотой» контроллер, который не трогаем снимками ни при каких обстоятельствах в рамках одного окна работ; (2) убедиться, что wbadmin start systemstatebackup в расписании отработал не позднее последних суток на каждом DC; (3) если снимок всё же необходим — снимать по одному DC за раз, с проверкой репликации AD и SYSVOL после возврата каждого, прежде чем трогать следующий; (4) после любого отката снимка контроллера в принципе — первым делом смотреть именно журнал «DFS Replication», а не только состояние AD, потому что чистая репликация каталога усыпляет бдительность и мешает вовремя заметить остановку SYSVOL.

Частые вопросы

Если repadmin /showrepl полностью чистый, значит ли это, что с SYSVOL тоже всё в порядке?

Нет. repadmin проверяет только репликацию базы Active Directory (NTDS.dit) через её собственный механизм USN/invocationID. SYSVOL реплицируется отдельной службой DFS Replication со своим движком версионирования на уровне файловой системы, и её состояние нужно проверять отдельно — командами dfsrdiag replicationstate, Get-DfsrState и журналом событий «DFS Replication».

Можно ли просто скопировать файлы SYSVOL вручную с рабочего DC на проблемный вместо authoritative restore?

Технически скопировать можно, но DFSR не узнает об этом — вектор версий реплицируемой папки останется старым, и при следующем цикле репликации служба либо попробует откатить файлы обратно, либо создаст конфликтные копии с суффиксом. Ручное копирование не заменяет процедуру через msDFSR-Enabled/msDFSR-Options, оно лишь маскирует симптом до следующего цикла polling.

Сколько времени займёт восстановление SYSVOL после authoritative restore?

Сама операция быстрая — события 4114 и 4602 обычно появляются в течение нескольких минут после dfsrdiag pollad, поскольку эта команда принудительно опрашивает AD вместо ожидания штатного интервала polling службы DFSR. Дольше всего занимает первичная синхронизация на не-авторитетных DC — зависит от объёма GPO и скриптов, на практике от нескольких минут до 1–2 часов на канале среднего офиса.

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

DFSR сам это не разрешит — оба члена группы репликации будут просто ждать вмешательства администратора, генерируя события 4012. Решение принимает администратор вручную: сравниваем версии GPO в gpt.ini с атрибутом versionNumber объекта GroupPolicyContainer в AD, смотрим фактические даты последних осознанных изменений политик и выбираем как авторитетный тот DC, чья копия ближе к последнему согласованному состоянию до инцидента.

Как избежать повторения такой ситуации в будущем?

Мы закладываем три меры: снимки гипервизора двух DC одного сайта никогда не делаются в одно окно без выделенного нетронутого «золотого» контроллера; системный бэкап wbadmin start systemstatebackup по расписанию остаётся основным инструментом восстановления, а не снимок; и мониторинг событий 2095 (USN rollback), 4012 и 2213 (DFSR) в Zabbix или аналогичной системе, чтобы поймать расхождение в течение часа, а не по жалобам пользователей на неприменённые политики.