Короткий ответ

Зелёная репликация NTDS не гарантирует живой SYSVOL. Сначала проверьте шары SYSVOL и NETLOGON, службу DFSR, dfsrmig /getglobalstate и события DFS Replication (2213 — ожидание authoritative). Не запускайте D4/D2 «как в старой статье FRS», пока не знаете, какой DC — источник правды и что FRS у вас уже не используется.

GPO живут в SYSVOL + объекты в AD. Чинить только AD или только файлы недостаточно.

Симптомы и отличия

  • \\contoso.example\sysvol не открывается или пустой на одном DC.
  • gpupdate /force на клиенте: нельзя найти шаблон.
  • Разные GUID папок политик на DC01 и DC02.

NTDS при этом может быть зелёным — это отдельная репликация. Недоступный DC целиком — сначала узел.

На современных доменах SYSVOL почти всегда DFSR, не FRS. Проверка:

dfsrmig /getglobalstate
dfsrmig /getmigrationstate

Eliminated = FRS нет. Если вдруг не Eliminated — не смешивайте процедуры FRS и DFSR.

Возможные причины

  1. DFSR не стартовал, диск заполнен, журнал DFSR повреждён.
  2. Event 2213 после нештатного shutdown: DFSR ждёт явного решения.
  3. Нет RPC до партнёра SYSVOL (тот же класс, что 1722).
  4. Кто-то удалил содержимое C:\Windows\SYSVOL «для места».
  5. Незавершённый migrate FRS→DFSR.
  6. После seize/restore DC папка SYSVOL не объявилась.

Диагностика

На каждом DC:

Get-SmbShare | Where-Object { $_.Name -in 'SYSVOL','NETLOGON' }
Get-Service DFSR, Netlogon | Format-Table Name, Status
Get-WinEvent -LogName 'DFS Replication' -MaxEvents 30 | Format-Table TimeCreated, Id, Message -Wrap

Backlog (подставьте RG и партнёра из вывода DFSR):

dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" /smem:DC01 /rmem:DC02

Сравнение набора GPO:

Get-GPO -All | Select-Object DisplayName, Id, ModificationTime

и наличие папки {GUID} в \\DC01\SYSVOL\contoso.example\Policies.

Смотрите 2213: служба поднялась, но не реплицирует, пока не скажут, это authoritative или нет. Это не повод сразу делать D4.

Решение

Нет шары, диск жив

Проверьте путь C:\Windows\SYSVOL\sysvol. Если каталог на месте, а шары нет — Netlogon не зарегистрировал. Часто лечится стартом DFSR+Netlogon после освобождения диска. Не создавайте шару вручную с произвольным путём.

Event 2213

Прочитайте статью Microsoft по 2213 для вашей версии: есть ветка «продолжить неauthoritative» и редкая authoritative. Если остальные DC имеют полный SYSVOL, проблемный узел должен подтянуть данные, а не стать источником.

Перед любым authoritative:

  1. Backup GPO: Backup-GPO -All -Path C:\Temp\gpo-backup.
  2. Сверьте, на каком DC набор {GUID} полный.
  3. Зафиксируйте в заявке, кто источник.

Сеть DFSR

Как с AD RPC: 135 и динамический RPC между DC. Почините транспорт, затем backlog должен падать, не расти.

Случайное удаление файлов

Restore из backup SYSVOL/GPO на один DC, затем дайте DFSR разойтись. Не восстанавливайте конфликтующие копии на все DC сразу.

Проверка

Get-SmbShare SYSVOL, NETLOGON
nltest /dcname:contoso.example
gpresult /r

Создайте тестовую GPO в тестовой OU, дождитесь появления GUID-папки на втором DC, примените к тестовой машине, удалите GPO. dfsrdiag backlog около нуля.

Клиент должен читать Sysvol того DC, который выбрал locator.

Если не помогло

  • NTDS красный — сначала каталог.
  • Migrate FRS застрял между Prepared/Redirected — не импровизируйте; это отдельная процедура миграции.
  • Политика есть в AD, папки нет: либо SYSVOL, либо GPO создали с ошибкой. Не удаляйте объект GPO без backup.

Как не уничтожить GPO при «починке»

Перед любым флажком authoritative соберите с каждого DC список GUID:

Get-ChildItem C:\Windows\SYSVOL\sysvol\contoso.example\Policies | Select-Object Name

Сверьте с Get-GPO -All. Объект в AD без папки — политика уже повреждена. Папка без объекта — мусор после неудачного удаления. Не выравнивайте это копированием.

Если 2213 на всех DC сразу, это не «выберите любой источником». Ищите общую причину: диск, массовый reboot, сеть между сайтами. Authoritative с пустым набором размажет пустоту.

Для филиала с одним DC: SYSVOL всё равно должен сходиться с хабом. Большой backlog после выходных — нормален, если падает. Растущий backlog в рабочий день — транспорт или диск.

Не ставьте антивирус на C:\Windows\SYSVOL без исключений по рекомендации Microsoft: блокировка файлов GPT.ini даёт «GPO не применяется» при живой репликации NTDS.

Тестовая GPO в отдельной OU — ваш канареечный файл. Если GUID не появился на партнёре за интервал сайта, не начинайте массовые правки политик.

События DFSR 5002/5014 читайте вместе с сетью, не как «переустановите роль». Массовый reboot обоих DC в одну минуту даёт всплеск 2213: дождитесь, сравните содержимое, и только если один SYSVOL пустой — думайте про authoritative.

Журнал DFSR пишите в baseline перед патчем DC: иначе не отличите регресс обновления от старого backlog. Сохраняйте Event ID и время, не скриншот «красное».

Профилактика

  • Мониторинг шары SYSVOL и 2213.
  • Не заполнять диск DC логами.
  • Изменения GPO — с одного админского контекста, не с двух DC одновременно одни и те же файлы.
  • Snapshot DC не является backup SYSVOL.

FAQ

Можно ли восстановить одну GPT.ini руками?

Точечно — риск рассинхрона. Лучше Backup-GPO/Restore-GPO.

D2/D4 из статей 2008 года ещё живы?

Для FRS. Если dfsrmig = Eliminated, следуйте процедуре DFSR для вашей версии, не копируйте burflags FRS.

Почему NETLOGON пустой, а SYSVOL есть?

NETLOGON — junction на scripts. Проверьте junction и службу Netlogon.

Нужно ли останавливать NTDS, чтобы починить SYSVOL?

Обычно нет. DFSR независим. Останавливайте только если процедура restore это требует.

gpupdate работает, но настройки старые?

Кеш клиента, фильтрация, WMI, или другая GPO с более высоким приоритетом. Снимите RSOP, не только шару.