Из практики админа 04. Обслуживание AD: SYSVOL/DFSR и сироты в каталоге

Note

Материал сверен с официальной документацией (Microsoft Learn и др.; ссылки — в конце статьи). Статья основана на реальном случае, описанном обезличенно: названия, адреса и значения изменены. Примеры вывода — иллюстрации. Перед работой на боевых системах проверьте шаги на тестовой машине.

В домене с двумя контроллерами всё вроде бы работает: пользователи входят, политики применяются. Но при внимательном взгляде находятся два «тихих» дефекта, которые сегодня не мешают, но могут помешать в неподходящий момент. Первый — папка SYSVOL, репликация которой между контроллерами так и не завершила начальную инициализацию. Второй — «сирота» в каталоге: запись о центре сертификации (ЦС), сервера которого давно нет, а клиенты исправно пытаются к нему обратиться.

Разберём оба случая так, как они выглядели в работе: что увидели, что проверили, чем рисковали и как исправили. Их объединяет принцип «уборки» в Active Directory: сначала копия, потом удаление минимально необходимого, проверка, и только затем всё остальное. В примерах домен lab.example, контроллеры DC1 и DC2.

Что нужно знать заранее

SYSVOL — папка на каждом контроллере домена (DC), через которую реплицируются файлы групповых политик и сценарии входа. Раньше её реплицировала служба FRS, в современных версиях Windows Server — DFS Replication (DFSR). Переход односторонний: до состояния Eliminated откат возможен, после него вернуться к FRS нельзя.
Состояния миграции задаёт dfsrmig: Start, Prepared, Redirected, Eliminated (значения 0–3). Глобальное состояние смотрят на эмуляторе PDC (это роль мастера операций; правки политик обычно делают именно на нём, у нас это DC1). В нашем случае состояние Eliminated, служба FRS (NtFrs) отключена — это норма.
Начальная синхронизация (initial sync) — состояние нового участника репликации: он ждёт данные от партнёра, уже прошедшего инициализацию. Состояние папки SYSVOL читается из WMI: 0 — Uninitialized, 1 — Initialized, 2 — Initial Sync, 3 — Auto Recovery, 4 — Normal, 5 — In Error.
Авторитативная синхронизация назначает один контроллер «эталоном» для SYSVOL, неавторитативная заставляет контроллер взять данные у партнёров. Для SYSVOL это делают правкой атрибутов в каталоге: средства DFS Management её намеренно не позволяют. Файлы, не совпавшие с партнёрами, DFSR при начальной синхронизации откладывает в служебные папки PreExisting и Conflict and Deleted.
Корпоративный ЦС (Enterprise CA) при установке создаёт в разделе конфигурации AD объект Enrollment Services (класс pKIEnrollmentService): по нему клиенты находят ЦС для автозапроса сертификатов (autoenrollment). Другие объекты ЦС в AD: AIA (Authority Information Access — где клиент берёт сертификат ЦС), CDP (CRL Distribution Point — где берёт список отозванных сертификатов, CRL), контейнер Certification Authorities и объект NTAuthCertificates (в них публикуются сертификаты ЦС).
DCOM — вызов компонентов на другом компьютере поверх RPC (удалённых вызовов процедур); CertEnroll — компонент клиента, записывающий события автозапроса.
Права: администратор домена; для раздела конфигурации — членство в Enterprise Admins на время работы (Windows Server с нуля 03). Перед всем нужна копия состояния системы контроллеров (Windows Server с нуля 11); для контроллеров откат контрольной точкой ВМ в боевой сети не применяется и копию не заменяет.

Симптомы

SYSVOL. Миграция на DFSR завершена, но в WMI у обоих контроллеров папка SYSVOL в состоянии 2: начальная синхронизация. Первый контроллер очень давно ждал начальной синхронизации от второго (событие 4614), а второй с момента ввода в домен ждал её от первого: взаимное ожидание. На втором контроллере каталог SYSVOL был пуст, параметр SysvolReady равен нулю, а общих ресурсов SYSVOL и NETLOGON не было.

Сирота. В журналах повторялись ошибки DCOM с кодом 10028 (английский текст события: «DCOM was unable to communicate with the computer … using any of the configured protocols», то есть DCOM не смог связаться с компьютером; формулировка из архивной записи блога Microsoft, справочной страницы про это событие нет) и ошибка автозапроса CertEnroll 0x800706BA («RPC-сервер недоступен»). Они возникали три раза в сутки: по такому расписанию клиентские задачи автозапроса обращались к ЦС. Сервера ЦС не было: ни самого сервера, ни его компьютерной учётной записи, ни имени в DNS.

Как искали причину

SYSVOL

На эмуляторе PDC смотрим, закончилась ли миграция, и убеждаемся, что остальные контроллеры дошли до того же состояния:

dfsrmig /getglobalstate
dfsrmig /getmigrationstate

У нас глобальное состояние — Eliminated, все контроллеры в нём: это нормальный итог миграции. Дальше читаем состояние самой папки SYSVOL на каждом контроллере (запускайте локально):

Get-CimInstance -Namespace root\microsoftdfs `
  -ClassName DfsrReplicatedFolderInfo |
  Select-Object MemberName, ReplicatedFolderName, State

Пример вывода (иллюстрация; строки собраны с обоих контроллеров, локальный запрос показывает только свою папку):

MemberName ReplicatedFolderName State
---------- -------------------- -----
DC1        SYSVOL Share             2
DC2        SYSVOL Share             2

Состояние 2 вместо 4 — сигнал. Теперь события журнала DFS Replication: 4614 означает ожидание начальной репликации, 4604 — её завершение, так что 4614 без последующего 4604 — застрявший контроллер.

Get-WinEvent -MaxEvents 30 -ErrorAction SilentlyContinue -FilterHashtable @{
  LogName = 'DFS Replication'
  Id      = 2213, 4012, 4114, 4602, 4604, 4614 } |
  Select-Object TimeCreated, Id | Format-Table -AutoSize

Остальные номера нужны для исключения других причин: 2213 — репликация на паузе после «грязного» выключения, 4012 — сработала защита по давности содержимого. Затем проверяем сам контроллер, по одному тесту за раз:

dcdiag /test:sysvolcheck
dcdiag /test:netlogons

SysVolCheck читает значение SysvolReady службы Netlogon и проходит, только если оно равно 1; NetLogons проверяет доступ к ресурсам SYSVOL и NETLOGON. При SysvolReady = 0 первый тест не пройдёт; после починки повторите оба.

Почему не «само»? Начальная синхронизация идёт от партнёра, уже получившего данные; если не инициализирован ни один из двух, источника нет (наше предположение; по смыслу статьи о пропавших ресурсах). При включённой защите по давности (на современных контроллерах она включена по умолчанию) для двух контроллеров рекомендуется сделать авторитативным первый. Если же защита не сработала, а первый стоит на паузе (2213), путь другой: метод ResumeReplication, как указано в самом событии.

Сирота

Ошибки DCOM 10028 и CertEnroll 0x800706BA лишь говорят, что кто-то не смог дозвониться до удалённого сервера. Ту же 0x800706BA дают и живые ЦС: например, из-за прав доступа на уровне DCOM или политики «Доступ к компьютеру из сети». Поэтому сначала нужно понять, куда стучатся клиенты. Мы судим о нём по тексту сообщения. Корпоративные ЦС — это объекты в разделе конфигурации:

$cfg  = (Get-ADRootDSE -Server DC1).configurationNamingContext
$base = "CN=Enrollment Services,CN=Public Key Services,CN=Services,$cfg"
Get-ADObject -Server DC1 -SearchBase $base `
  -LDAPFilter '(objectClass=pKIEnrollmentService)' `
  -Properties dNSHostName, whenCreated |
  Select-Object Name, dNSHostName, whenCreated

Атрибут dNSHostName хранит имя сервера ЦС. Проверяем, существует ли такой сервер: резолвится ли имя в DNS (Windows Server с нуля 04), есть ли компьютерная учётная запись и отвечает ли ЦС (certutil -ping обращается к интерфейсу запросов ЦС).

Resolve-DnsName <имя из dNSHostName> -ErrorAction SilentlyContinue
Get-ADComputer -Server DC1 -Filter "DNSHostName -eq '<имя из dNSHostName>'"
certutil -config "<имя из dNSHostName>\<имя ЦС>" -ping

У нас сервера, учётной записи и DNS-имени не оказалось: объект Enrollment Services остался от сервера, которого нет. Результат certutil -ping в нашем описании не фиксировался; ожидать от него стоит ошибки подключения (допустим). Нормальное выведение ЦС из эксплуатации удаляет этот объект само: при удалении роли убирается только pKIEnrollmentService, чтобы клиенты не обращались к выведенному ЦС, а остальные объекты остаются. Здесь сервер исчез без процедуры, и объект остался.

Что не помогло и от чего отказались

Удалённый запуск диагностики. Команды repadmin и dfsrmig, запущенные удалённо, могут давать ошибки (например, код 110). Похоже на «двойной переход» (double-hop): учётные данные не передаются дальше второго узла; в документации он описан для удалённого PowerShell, но природа у него общая. Это не сбой репликации. Запускайте команды на самом контроллере (консоль или RDP), а в командлетах AD указывайте контроллер явно: -Server DC1.

Уборка «всё сразу». Удалить из AD весь след старого ЦС мы не стали. Документация прямо называет AIA, CDP и контейнер Certification Authorities: их не удаляют, если ещё придётся обрабатывать сертификаты, выданные этим ЦС. Остальное (корневой сертификат, NTAuthCertificates) мы тоже оставили по осторожности (практика автора): полную чистку, включая NTAuthCertificates, KB 889250 описывает отдельными шагами, и мы её отложили.

Что сработало

SYSVOL: принудительная авторитативная синхронизация

Warning

Это опасная операция. Она переинициализирует репликацию SYSVOL, а файлы на неавторитативных контроллерах, не совпадающие с партнёрами, перемещаются в PreExisting и Conflict and Deleted. По документации, в большинстве случаев такая процедура не нужна и при ошибке может привести к потере данных. Делайте её, только проверив причину, в окно работ (вне рабочего времени), после копии и по официальной статье (KB 2218556), а не по памяти. Не повторяйте начальную синхронизацию подряд: при многократной начальной синхронизации содержимое этих папок стирается.

Когда нужна авторитативная. Если чинится один контроллер, достаточно сделать его неавторитативным, не трогая остальные. Авторитативный назначают, когда принудительно синхронизируют все: тогда остальные обязаны пройти неавторитативную синхронизацию, иначе возникают конфликты. У нас оба контроллера застряли в начальной синхронизации, а у второго каталог SYSVOL был пуст, поэтому авторитативным выбран первый, эмулятор PDC: в KB его содержимое названо обычно самым актуальным.

Подготовка (практика автора).

Проверьте события 2213 и 4012. Если первый контроллер стоит на паузе после «грязного» выключения (2213), а защита по давности не срабатывала, у Microsoft для этого отдельный путь, ResumeReplication, и авторитативная синхронизация не нужна.
Сделайте копию состояния системы обоих контроллеров и отдельно скопируйте файлы SYSVOL, включая PreExisting и Conflict and Deleted, если они есть, а также резервные копии GPO (Backup-GPO -All -Path C:\Backup\GPO, см. Windows Server с нуля 06).
Снимите контрольные суммы файлов политик и сценариев на обоих контроллерах (каталог C:\Backup\AD создайте заранее). Путь C:\Windows\SYSVOL\domain — расположение по умолчанию; если SYSVOL переносили, укажите свой. Перед работами $tag равен before:

$tag  = 'before'
$root = 'C:\Windows\SYSVOL\domain'
Get-ChildItem -Path "$root\Policies", "$root\scripts" -Recurse -File `
  -ErrorAction SilentlyContinue |
  Get-FileHash -Algorithm SHA256 |
  Select-Object @{n='Path'; e={$_.Path.Substring($root.Length)}}, Hash |
  Export-Csv -Path "C:\Backup\AD\sysvol-$tag-$env:COMPUTERNAME.csv" `
    -NoTypeInformation -Encoding UTF8

Процедура (порядок KB 2218556 с проверкой событий). Все правки атрибутов делайте в adsiedit.msc, подключённом к одному контроллеру, DC1 (контекст имён по умолчанию): тогда репликацию в шаге 3 удобно запускать с него же.

На всех контроллерах установите тип запуска службы DFS Replication «Вручную» и остановите её.
Откройте объект CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=DC1,OU=Domain Controllers,DC=lab,DC=example и задайте msDFSR-Enabled = FALSE и msDFSR-Options = 1. В таком же объекте с именем DC2 задайте только msDFSR-Enabled = FALSE.
Принудительно реплицируйте AD по всему домену: repadmin /syncall DC1 /A /e /P. Команда — практика автора: в KB сказано просто «реплицируйте AD», а /P лишь отправляет изменения с DC1 наружу. Убедитесь, что значения дошли: прочитайте атрибуты объекта DC2 с -Server DC2.
Запустите службу DFSR на DC1: в журнале DFS Replication должно появиться событие 4114 (репликация SYSVOL отключена).
Верните msDFSR-Enabled = TRUE на DC1, снова реплицируйте AD и проверьте результат. На DC1 выполните опрос AD (ниже): появится событие 4602 (SYSVOL инициализирован как авторитативный).
Запустите службу DFSR на DC2: появится событие 4114. Задайте на DC2 msDFSR-Enabled = TRUE, реплицируйте AD и выполните там опрос AD. Ожидаем события 4614 и 4604: начальная синхронизация завершена.
На обоих контроллерах верните тип запуска службы «Автоматически».

Чтение атрибутов для проверки (по одному контроллеру за раз):

$dom = (Get-ADDomain).DistinguishedName
$dn  = 'CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,'
$dn += "CN=DC2,OU=Domain Controllers,$dom"
Get-ADObject -Server DC2 -Identity $dn `
  -Properties msDFSR-Enabled, msDFSR-Options

Шаги для DC2. Мы выполнили их полностью по той же процедуре: на реплике msDFSR-Enabled = FALSE, затем TRUE. KB 2958414 для случая «второй контроллер уже ждёт начальной синхронизации» допускает не делать его неавторитативным отдельно. Сверяйтесь с обеими статьями и не смешивайте шаги.

Опрос AD. Он заставляет службу перечитать настройки из каталога. В KB это dfsrdiag pollad; у нас утилиты на контроллере не оказалось, и опрос сделали через WMI: метод PollDsNow класса DfsrConfig. Тот же опрос выполняет командлет модуля DFSR. Вызов Invoke-CimMethod собран по описанию класса, проверьте его на тестовом контроллере.

# Вариант 1: командлет модуля DFSR
Update-DfsrConfigurationFromAD
# Вариант 2: WMI-метод
Invoke-CimMethod -Namespace root\microsoftdfs `
  -ClassName DfsrConfig -MethodName PollDsNow

Проверка после работ (практика автора). Состояние папки — 4 на обоих контроллерах, dcdiag /test:sysvolcheck и dcdiag /test:netlogons проходят, на DC2 появились ресурсы SYSVOL и NETLOGON. Контрольные суммы должны совпасть: повторите скрипт подготовки на обоих контроллерах с $tag = 'after', соберите файлы в одном месте и сравните:

Compare-Object (Import-Csv C:\Backup\AD\sysvol-after-DC1.csv) `
  (Import-Csv C:\Backup\AD\sysvol-after-DC2.csv) -Property Path, Hash

Пустой вывод означает, что файлы идентичны; у нас все файлы политик и сценариев совпали. Затем проверьте живую репликацию: создайте маленький файл в scripts на DC1, дождитесь его на DC2, удалите и убедитесь, что удаление тоже реплицировалось. Значение msDFSR-Options = 1 на DC1 у нас осталось: KB не описывает его возврат, а документации по поведению этого значения после процедуры мы не нашли, в обсуждениях сообщества сведения противоречивы. Проблем мы не наблюдали, но проверьте значение на своём контроллере и решите, оставлять ли его.

Откат. Обратной процедуры нет. Страховка — подготовка: пропавшие файлы возвращают из копии (в том числе из PreExisting и Conflict and Deleted) в SYSVOL на авторитативном контроллере, репликация разнесёт их остальным. Файлы политик связаны с версией GPO в каталоге, поэтому для политик надёжнее Restore-GPO из копии GPO (Windows Server с нуля 06). При серьёзном повреждении каталога — восстановление из копии состояния системы.

Сирота: удаление одного объекта

По принципу «копия, минимум, проверка»:

Доказать, что это сирота — проверки выше: имя не резолвится, учётной записи нет, ЦС не отвечает. Если сервер жив под другим именем или временно недоступен, удалять нельзя.
Сохранить атрибуты в двух форматах. Параметр -m исключает атрибуты, применимые только к объектам AD (ObjectGUID, objectSID и подобные), так что файл остаётся записью значений.

$dn = '<DistinguishedName объекта Enrollment Services из вывода выше>'
Get-ADObject -Server DC1 -Identity $dn -Properties * |
  Export-Clixml -Path C:\Backup\AD\enrollment-oldca.xml
ldifde -s DC1 -d $dn -p Base -m -f C:\Backup\AD\enrollment-oldca.ldf

Удалить только этот объект. Откройте «Active Directory Sites and Services», в меню View включите Show Services Node, затем Services → Public Key Services → Enrollment Services, найдите объект старого ЦС и удалите его. Microsoft допускает такое ручное удаление, если объект не исчез при удалении роли ЦС. AIA, CDP, Certification Authorities, NTAuthCertificates и остальное мы оставили.
Проверить репликацию. Запустите repadmin /syncall DC1 /A /e /P и убедитесь, что запрос выше с -Server DC2 объект не возвращает.
Проверить эффект. На клиенте выполните certutil -pulse: команда запускает событие автозапроса, не дожидаясь расписания. Новых ошибок CertEnroll и DCOM 10028 в журналах быть не должно.

Откат. Документированного пути «импорт из экспорта» нет: файл .ldf и XML — запись значений атрибутов, а импорт (ldifde -i) мы не проверяли. Документирован другой путь: пока объект можно найти среди удалённых (Get-ADObject -IncludeDeletedObjects), его возвращает Restore-ADObject; на странице командлета есть примеры для объектов раздела Configuration. Для нас откат был теоретическим: он вернул бы запись о несуществующем сервере.

Прочие «сироты» устроены так же: например, в контейнере NetServices остались устаревшие авторизации DHCP-серверов со старыми адресами. Они безвредны, и мы их не трогали; случись уборка, порядок тот же.

Выводы и чек-лист

«Миграция завершена» не значит «репликация работает»: смотрите состояние папки SYSVOL (4 = Normal) на каждом контроллере.
Событие 4614 без 4604 — признак застрявшей начальной синхронизации; два контроллера, ждущие друг друга, сами не справятся.
Авторитативная синхронизация: по процедуре Microsoft, в окно работ, после копии состояния системы и контрольных сумм, с проверкой событий 4114, 4602, 4604 и состояния 4.
Диагностику репликации запускайте на самом контроллере: «двойной переход» даёт ложные ошибки.
«Сироту» сначала доказывают, потом сохраняют, удаляют минимум, проверяют, и только после этого думают об остальном.
Остатки ЦС (AIA, CDP, корневой сертификат, NTAuthCertificates) убирают лишь после проверки, что выданные им сертификаты нигде не нужны.
Раз в квартал запускайте dcdiag и просматривайте журнал DFS Replication (практика автора).

Состояние на ноябрь 2026 года (проверьте актуальность). Процедура KB 2218556 и статья о пропавших ресурсах (KB 2958414) опубликованы на Microsoft Learn с датой обновления февраль 2026 года. Страницы repadmin, ldifde и классов WMI DFSR помечены как архивные (Windows Server 2012 R2 и старше): сверьте синтаксис с /?. Утилиты dfsrdiag на нашем контроллере не оказалось, а наличие модуля DFSR на контроллере мы не проверяли: уточните до начала работ.

Типичные ошибки и недоразумения

Принять dfsrmig Eliminated за здоровую репликацию. Он говорит о завершённой миграции, а не о состоянии папки SYSVOL.
Назначить авторитативным контроллер без актуальных данных. Содержимое остальных заменится, лишние файлы уйдут в PreExisting и Conflict and Deleted. Берут тот, у кого самый свежий SYSVOL, обычно эмулятор PDC.
Сделать авторитативным один контроллер и не тронуть остальные. Остальные, не прошедшие неавторитативную синхронизацию, дадут конфликты.
Править атрибуты по памяти и без копии. Следуйте порядку шагов из KB, с проверкой событий на каждом этапе.
Удалять базу DFSR «для верности». KB 2958414 называет это ненужным и нежелательным: все локальные данные станут неавторитативными.
Считать 0x800706BA признаком сироты. Она бывает и у живых ЦС: сначала найдите, куда идёт обращение.
Чистить AD «под ноль». Остатки ЦС нужны, пока выданные им сертификаты где-то проверяются.

Проверьте себя

У обоих контроллеров состояние SYSVOL равно 2, а на втором нет ресурсов SYSVOL и NETLOGON. Что это значит и что делать в первую очередь? Начальная синхронизация застряла: источника данных нет ни у кого. Сначала проверьте события 2213 и 4012, сделайте копию и снимите контрольные суммы, затем действуйте по процедуре Microsoft.
Какие события отмечают ключевые точки процедуры? 4114 — репликация SYSVOL отключена; 4602 — SYSVOL инициализирован на авторитативном контроллере; 4614 — ожидание начальной репликации; 4604 — начальная синхронизация завершена.
Почему нельзя ограничиться опросом AD (dfsrdiag pollad)? Он лишь заставляет службу перечитать настройки из AD. Если ни один контроллер не инициализирован, источника начальных данных нет.
Как убедиться, что запись о ЦС в каталоге действительно сирота? Прочитать dNSHostName объекта Enrollment Services и проверить, что имя не резолвится и учётной записи компьютера нет; ответ ЦС на certutil -ping ожидаем ошибочным.
Что удаляют при чистке следов выведенного из строя ЦС и что оставляют? Только объект Enrollment Services, чтобы клиенты не обращались к несуществующему серверу. Остальные объекты (AIA, CDP и прочие) остаются, пока нужна проверка выданных сертификатов.

Что дальше

Windows Server с нуля 03 — контроллеры, репликация и SYSVOL с самого начала.
Windows Server с нуля 04 — DNS в домене: чем проверять имя сервера.
Windows Server с нуля 11 — копия состояния системы и восстановление AD.
Из практики админа 02 — ещё один разбор в Active Directory: ключи BitLocker.

Источники

How to force authoritative and non-authoritative synchronization for DFSR-replicated sysvol replication (KB 2218556) — последовательность шагов, атрибуты msDFSR-Enabled и msDFSR-Options, события 4114 и 4602, предупреждения
How to troubleshoot missing SYSVOL and Netlogon shares (KB 2958414) — состояния 0–5, события 4614 и 4604, случай двух контроллеров, копия и PreExisting
dfsrmig — состояния миграции, необратимость Eliminated, проверка на эмуляторе PDC
Migrate SYSVOL replication from FRS to DFSR — назначение SYSVOL, односторонность миграции
DfsrConfig class — метод PollDsNow (архив)
Update-DfsrConfigurationFromAD — немедленный опрос AD службой DFSR
dcdiag — тесты SysVolCheck, NetLogons, DFSREvent
Repadmin -syncall — принудительная репликация и флаги (архив, WS 2012 R2)
How to decommission a Windows enterprise certification authority and remove all related objects (KB 889250) — объекты ЦС в AD, что удаляется при удалении роли, что нельзя удалять, ручное удаление Enrollment Services
PKI-Enrollment-Service class — класс pKIEnrollmentService и его атрибуты, включая DNS-имя
certutil — -pulse и -ping
Error 0x800706ba "The RPC Server is unavailable" when you enroll a certificate — ошибка бывает и у живого ЦС
Ldifde (архив, WS 2012 R2) — параметры -i, -d, -p, -m, -f
Restore-ADObject — восстановление удалённых объектов, примеры для раздела Configuration
Making the second hop in PowerShell Remoting — проблема двойного перехода