Как я восстанавливал Active Directory и DFS после 19 месяцев без репликации

от

Иногда инцидент начинается не с одной поломки, а с открытия, что ломалось всё это время - просто никто не смотрел. Этот кейс именно такой: обычная заявка «не открываются сетевые папки» превратилась в разбор Active Directory, где один контроллер домена держал на себе все пять FSMO-ролей, был фактически недоступен, а его напарник почти два года не реплицировался и никто этого не заметил.

Ниже - как это диагностировалось и чинилось, по шагам, с реальными командами и находками. Имена и домен компании изменены, техническая часть - без купюр.

С чего всё началось

Заявка простая: в компании перестали открываться сетевые папки на общих ресурсах - бухгалтерия, кадры, юротдел, архив и ещё десяток шар с документами. Инфраструктура на первый взгляд обычная: два контроллера домена, DC01 и DC02, оба числятся в основном сайте Active Directory. На тех же серверах развёрнут DFS-namespace, через который и раздаются все сетевые папки.

Первая же проверка показала: DC01 жив и обслуживает клиентов - он Global Catalog, отвечает на LDAP/Kerberos/DNS. DC02 отвечает на пинг и даже на некоторые порты (389, 88), но по факту Active Directory на нём не работает.

Диагностика: реплика не реплицируется два года

repadmin /showrepl DC01

Результат неприятный: репликация с DC02 не работала с 30 декабря 2024 года - больше 14 000 подряд неудачных попыток, ошибка -2146893022 (0x80090322) - «Главное конечное имя неверно». Для разделов DomainDnsZones и ForestDnsZones - отдельная ошибка 1256, «удалённая система недоступна».

На проде это выражалось не только в недоступности файлов: Exchange-сервер в той же подсети периодически терял связь со службой AD Topology и не мог стартовать (события 2070 и 12009 - «directory is unavailable»). То есть мёртвый DC02 тянул за собой и почту.

Дальше - dcdiag и netdom на обоих контроллерах, и тут открылась ключевая проблема: все пять FSMO-ролей (схема, именование доменов, PDC, RID, инфраструктура) висели на мёртвом DC02. Рабочий DC01 не имел ни одной. Это многое объясняло:

  • SYSVOL DFSR на DC01 была остановлена - партнёр по репликации не отвечал 589 дней подряд, что больше MaxOfflineTimeInDays (60 по умолчанию). Требовался authoritative restore (сценарий D4).
  • RID-пул на DC01 подходил к концу (оставалось ~489 объектов), а получить новый блок было не у кого - RID Master сидел на мёртвом DC02.
  • Get-DfsnFolderTarget падал с ошибкой 8341 - метаданные доменного DFS-namespace живут на PDC, а PDC недоступен. Отсюда и «не открываются папки»: не файлы потерялись, а сломался механизм, который говорит клиентам, где эти файлы искать.

Отдельно всплыло, что сам DFS-namespace был в старом формате Windows 2000 Server mode (V1, а не V2) - легаси, оставшееся с давних времён и требующее специфического подхода к диагностике (штатные PowerShell-командлеты для V2 на нём просто не работают так, как ожидается).

План: сначала не потерять файлы, потом чинить AD

Прежде чем трогать роли и репликацию, нужно было убедиться, что сами файлы не пропали - это было прописано первым пунктом в целях работ. Проверка таргетов DFS (через атрибут pKT, потому что штатные командлеты не отрабатывали) показала: реальные файлы лежат не на контроллерах домена, а на отдельных файловых серверах. Один из них на момент диагностики был выключен - после его включения доступ к части шар восстановился сам, без всяких манипуляций с AD.

Это разделило работу на два независимых трека: включить файловые сервера (быстро, низкий риск) и чинить Active Directory (долго, высокий риск). Раздельно - это важно: смешивать восстановление контроллера домена с «а давайте заодно проверим файлы» - верный способ упустить момент, когда что-то пошло не так.

Захват FSMO-ролей и первая ошибка

Move-ADDirectoryServerOperationMasterRole -Identity DC01 -OperationMasterRole SchemaMaster,DomainNamingMaster,PDCEmulator,RIDMaster,InfrastructureMaster -Force

Первая попытка захвата ролей упала с «отказано в доступе» - учётная запись не входила в группы «Администраторы схемы» и «Администраторы предприятия» (в англоязычной локализации это SID, оканчивающиеся на -518 и -519; в русской версии консоли группы называются иначе, но SID те же - на это стоит ориентироваться, если что-то не совпадает по названию). После добавления в нужные группы захват прошёл успешно.

Сразу после этого DFS ожил: Get-DfsnRoot начал отвечать, \\domain\shares\... открылся, dcdiag перестал жаловаться на RidManager. Причина и следствие подтвердились: без PDC-эмулятора доменный DFS-namespace не может отдавать клиентам актуальный список таргетов.

Чистка хвостов: metadata cleanup

Мёртвый контроллер нельзя просто выключить - в Active Directory и DNS останутся ссылки на него, которые будут мешать годами. Порядок действий:

  1. Metadata cleanup через ntdsutil - удаление объекта DC02 из конфигурации леса:

    ntdsutil
metadata cleanup
connections
connect to server DC01
quit
select operation target
list domains
select domain 0
list sites
select site 0
list servers in site
select server <номер DC02 в списке>
quit
remove selected server
quit
quit
  2. Удаление объекта CN=DC02,CN=Servers,CN=Default-First-Site-Name в Sites and Services.
  3. Проверка DNS: у зон DomainDnsZones и ForestDnsZones было по пять A-записей вместо ожидаемых двух - то есть, кроме DC02, там годами копились адреса ещё нескольких контроллеров, давно выведенных из эксплуатации. Почистил всё, кроме актуального.

  4. Контроль, что в лесу остался только один контроллер, и защита от «фантомных» реплик в будущем:

    Get-ADDomainController -Filter *
repadmin /viewlist *
repadmin /regkey DC01 +strict

Отдельно нашёл и поправил забавную, но болезненную деталь: у рабочего DC01 первым DNS-сервером в настройках сетевой карты был прописан мёртвый DC02. Каждый DNS-запрос сначала уходил в таймаут на несуществующий сервер и только потом - на живой. Это не ломало работу критично, но заметно тормозило вообще всё, что обращалось к AD.

SYSVOL: authoritative restore и подводный камень

Восстановление SYSVOL через сценарий D4 - стандартная, хорошо задокументированная процедура: на живом DC атрибут msDFSR-Enabled группы репликации Domain System Volume выставляется $true (авторитетное восстановление), на остальных - $false (неавторитетное, они просто примут копию с авторитетного):

Set-ADObject "CN=Domain System Volume,CN=DFSR-GlobalSettings,CN=System,DC=corp,DC=local" -Replace @{'msDFSR-Enabled'=$true}

Но с одним нюансом, на котором легко ошибиться: между шагами нужно дожидаться событие 4114 в журнале DFS Replication, прежде чем выставлять этот флаг. Если поторопиться и выполнить команды подряд без ожидания - реплика не поднимется, и придётся повторять процедуру заново.

Именно это и произошло с первого раза. Со второго - с паузой и контролем событий 4114 → 4602 - SYSVOL и NETLOGON поднялись штатно, dcdiag вместо шести проваленных проверок стал показывать три (и те - исторические записи в логе от неудачной первой попытки, не актуальная проблема). Финальную проверку состояния миграции сделал так:

dfsrmig /getglobalstate

Ввод нового второго контроллера

Финальный шаг - поднять новый DC02 с нуля, а не пытаться реанимировать старый:

  • Развёрнут новый сервер, статический IP, синхронизация времени с DC01, ввод в домен как member server.
  • Проверка совместимости версии схемы леса с версией ОС - важно сверитьcя заранее, чтобы не спровоцировать требование расширения схемы в неподходящий момент.

  • Повышение до контроллера домена с ролями Global Catalog и DNS:

    Install-ADDSDomainController -DomainName corp.local -InstallDns -Credential (Get-Credential) -SiteName "Default-First-Site-Name"

  • Контроль репликации в обе стороны и статуса SYSVOL (событие 4604, State=4):

    repadmin /showrepl

На новый DC02 автоматически ушёл свежий блок RID (домен-пул к этому моменту уже сдвинулся далеко за пределы старого исчерпанного диапазона) - больше эта проблема не всплывёт в ближайшие годы.

Что в итоге

  • Все сетевые папки (19 ссылок DFS) снова онлайн, таргеты - на живых файловых серверах, ни один файл не потерян.
  • Почта перестала «отваливаться» вместе с AD Topology.
  • В домене остался один надёжный DC + новый второй, оба с полной репликацией.
  • Хвосты от списанных контроллеров (минимум трёх, судя по мёртвым DNS-записям) вычищены.

Выводы, которые стоят отдельного поста

  1. Мониторинг репликации AD - не опция. repadmin /showrepl два года показывал бы одну и ту же ошибку при любой проверке - просто её никто не запускал. Простой scheduled task с алертом на непроходящую репликацию стоит копейки по сравнению с последствиями.
  2. Все FSMO-роли на одном контроллере - риск, который не виден, пока не грянет. Если этот контроллер выходит из строя, ломается не только он: PDC-эмулятор нужен DFS-namespace, RID Master - созданию новых объектов, и так далее по цепочке.
  3. DFS работает поверх AD, а не параллельно с ним. «Не открываются папки» почти никогда не означает «потерялись файлы» - чаще это означает, что сломался механизм, который говорит клиентам, где их искать. Разделять эти два трека при диагностике - экономия часов.
  4. Списанные серверы нужно выводить из инфраструктуры полностью, а не просто выключать: без metadata cleanup и чистки DNS вы получаете мину замедленного действия, которая взрывается через месяцы или годы, когда все успели забыть контекст.

Если у вас похожая ситуация - DFS «сломался сам собой», реплика AD не проходит месяцами, или просто хочется, чтобы кто-то посмотрел на инфраструктуру со стороны до того, как она развалится - пишите, разберёмся.

Оставьте комментарий