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

Снимите владельцев: netdom query fsmo и Get-ADDomain | Format-List *Master*, Get-ADForest. Если узел-владелец жив по LDAP — чините его или делайте transfer. Seize — только когда диск с ролью гарантированно не вернётся в сеть. Два живых владельца одной роли хуже, чем несколько часов без PDC.

Не все симптомы «AD сломан» требуют FSMO. Создание пользователей упирается в RID; логон — чаще DNS/KDC.

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

СимптомРоль, которую проверитьНе путать с
Не создаются учётки, 16650/16651RID masterдиск NTDS, квоты
Пароли меняются странно, время плывётPDC emulatorNTP клиента
Не добавляется DC / домен в лесDomain NamingDNS
Проблемы с кросс-доменными группамиInfrastructureGC
Не расширяется схемаSchemaправа Enterprise/Schema Admins

Если пользователи просто не входят — начните с DC и DNS, не с seize.

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

  1. Владелец выключен, но объект DC ещё в AD.
  2. Владелец отвечает ICMP, не отвечает LDAP.
  3. Роли «висят» на DC, который давно demote некорректно.
  4. Кто-то уже сделал seize, старый узел включили обратно.
  5. Репликация не доносит информацию о transfer.

Диагностика

netdom query fsmo
Get-ADDomain | Select-Object PDCEmulator, RIDMaster, InfrastructureMaster
Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster
Get-ADDomainController -Filter * | Select-Object Name, HostName, OperationMasterRoles

Проверка живости владельца:

$pdc = (Get-ADDomain).PDCEmulator
Test-NetConnection $pdc -Port 389
Get-ADDomainController -Identity $pdc

RID:

dcdiag /test:RidManager /v /s:DC01

Смотрите пул RID и доступность RID master, не только «passed».

Проверьте, нет ли старого DC с теми же ролями в DNS/AD после прошлого инцидента.

Решение

Transfer (владелец жив)

Делайте в окне работ, с учётки Schema/Enterprise по роли:

Move-ADDirectoryServerOperationMasterRole -Identity DC02 -OperationMasterRole PDCEmulator, RIDMaster, InfrastructureMaster

Для Schema/Naming — соответствующие роли и DC целевого леса. Дождитесь репликации:

repadmin /syncall DC02 /AdeP
netdom query fsmo

/AdeP здесь — после успешного transfer, не вместо починки RPC.

Владелец временно недоступен, но вернётся

Не seize. Для RID подождите или чините узел. Создание массовых учёток можно отложить. PDC: время и смена паролей пострадают, но лес жив, если есть другие DC.

Seize (владелец уничтожен)

  1. Докажите: диск уничтожен, VM удалена, возврата не будет.
  2. Metadata cleanup, если объект DC ещё есть, по процедуре Microsoft.
  3. Seize нужных ролей на здоровый DC:
Move-ADDirectoryServerOperationMasterRole -Identity DC02 -OperationMasterRole PDCEmulator -Force

-Force = seize. После этого не включайте старый DC в ту же сеть без подготовки: он будет считать себя владельцем.

Infrastructure и GC

Не держите Infrastructure master на GC в многодоменном лесу — это старое правило Microsoft для мультидомена. В однодоменном лесу с GC на всех DC влияние меньше, но не меняйте роли «для красоты» в инциденте.

Проверка

netdom query fsmo
dcdiag /test:RidManager /s:DC02
w32tm /query /source

Создание тестовой учётки в OU лаборатории. Смена пароля тестового пользователя и вход. Назначение ролей совпадает на всех DC после репликации (Get-ADDomainController на каждом).

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

  • Transfer висит: репликация/RPC к источнику. Вернитесь к статье про репликацию.
  • RID кончился на домене: это уже ёмкость RID, не «недоступен FSMO». Нужна процедура Microsoft по RID pool, не seize повторно.
  • Schema не идёт: права и schema.ini/ldf, не роль «занята ping».

Практические решения по ролям

PDC emulator недоступен несколько часов. Пользователи обычно продолжают входить на других DC. Страдают: смена пароля (задержка), синхронизация времени, некоторые доверительные отношения и старые приложения, которые сами ищут PDC. Seize PDC имеет смысл, если узел уничтожен или простой измеряется сутками. Если «висит обновление» — чините узел.

RID master недоступен. Существующие учётки работают. Кончатся локальные пулы RID на DC — создание новых объектов остановится. Не жгите пул тестовыми учётками в инциденте. Transfer, когда источник оживёт; seize — если диск RID-узла не вернётся.

Schema master. Нужен редко. Seize из-за того, что «не пингуется час», почти никогда не оправдан. Дождитесь или восстановите узел.

После seize. Обновите документацию, мониторинг и DNS. Старый сервер, если всплывёт из архива, изолируйте до очистки метаданных. Не «просто выключите ping».

Не перемещайте роли ради «красоты» в том же окне, что и патч. Transfer — отдельный пункт плана с проверкой netdom query fsmo на двух DC.

Запишите в паспорт домена: текущий владелец каждой роли и запасной узел. В 3 часа ночи это экономит seize «на всякий случай». Проверьте, что запасной DC — не тот же хост и не то же хранилище, что владелец.

После transfer RID подождите репликацию, прежде чем массово создавать объекты: пулы на DC обновляются не мгновенно. Если 16650 остаётся — смотрите доступность нового RID master, не повторяйте seize.

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

  • Документируйте владельцев FSMO и запасной DC.
  • Не ставьте все роли на единственную VM без backup restore-теста.
  • Мониторинг доступности PDC (LDAP + w32tm).
  • Запрет snapshot DC.

FAQ

Нужно ли seize все пять ролей сразу?

Нет. Захватывайте те, чей владелец мёртв. Живой Schema master не трогайте.

Можно ли держать все FSMO на одном DC?

Да, это обычная схема малого домена. Тогда недоступность этого DC больнее — поэтому нужен второй DC и план transfer.

Seize PDC чинит вход пользователей?

Не обязательно. Вход обслуживают все DC с KDC. Seize PDC помогает времени, паролям и некоторым приложениям, завязанным на PDC.

Как понять, что уже был seize?

Журнал Directory Service на целевом DC, несовпадение netdom query fsmo с таблицей в документации, и внезапно «воскресший» старый DC.

Стоит ли seize через ntdsutil вместо PowerShell?

Оба поддерживаются. Важно одно и то же условие: старый владелец не вернётся. Не смешивайте два инструмента в одной сессии без фиксации результата.