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

Сначала отделите «узел не отвечает» от «каталог жив, но клиенты не находят DC». Проверьте ICMP и RDP/консоль, затем DNS-записи _ldap._tcp, порт LDAP 389, службу NTDS/Netlogon и свободное место на томе NTDS. Не захватывайте FSMO и не делайте metadata cleanup, пока не доказано, что контроллер не вернётся.

Если есть второй здоровый DC, вход в домен часто сохраняется. Чините недоступный узел как отдельный сервер: железо, гипервизор, диск, затем роли AD.

Симптомы и как отличить похожую проблему

Типичная картина:

  • пользователи получают «недоступен контроллер домена» или долго висят на логоне;
  • nltest /dsgetdc:<домен> с клиента не находит DC;
  • на самом сервере нет RDP, либо RDP есть, но Get-Service NTDS не Running;
  • в журнале Netlogon на клиентах Event ID 5719.

Отличия:

Что видноСкорее не «DC лёг»Куда смотреть
Один ПК не входит, остальные работаютпрофиль, DNS клиента, secure channelКлиент не входит в домен
Все клиенты, ping до DC естьDNS/LDAP/KerberosDNS не разрешает имена домена
Репликация отстаёт, но LDAP локально отвечаетпартнёр/сеть между DCОшибки репликации Active Directory
Нет ни ping, ни консоли гипервизорахост, диск VM, сеть гипервизораэтот материал

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

От более частых к редким:

  1. Сеть до узла: VLAN, firewall, изолированный порт, «заснувший» NIC после обновления.
  2. Сервер запущен, но диск C: или том NTDS заполнен — NTDS и SYSVOL останавливаются.
  3. Службы NTDS, Netlogon, DNS или KDC не стартовали после патча.
  4. DNS-зона не содержит SRV, клиенты ходят на мёртвый IP.
  5. Время убежало — клиенты отбрасывают билеты, это выглядит как «нет DC».
  6. База NTDS повреждена после жёсткого выключения. Это уже не «просто перезапустить службу».

Диагностика по шагам

Работайте с рабочей станции администратора или с живого DC. Подставьте свои имена вместо плейсхолдеров.

1. Доступность узла

$dc = 'DC01.contoso.example'
Test-NetConnection $dc -Port 389
Test-NetConnection $dc -Port 53
Test-NetConnection $dc -Port 135
Get-ADDomainController -Identity $dc -ErrorAction SilentlyContinue

TcpTestSucceeded : False на 389 при живом ping — это фильтрация RPC/LDAP или мёртвый NTDS, не «кабель».

2. SRV и LDAP с клиента

Resolve-DnsName _ldap._tcp.dc._msdcs.contoso.example -Type SRV
nltest /dsgetdc:contoso.example /force

Если SRV указывает на IP выключенного DC, клиенты будут стучаться туда, пока запись жива. Не удаляйте SRV вручную до понимания, почему динамическая регистрация не обновилась.

3. Службы и диск на самом DC

Если консоль доступна:

Get-Service NTDS, Netlogon, DNS, Kdc | Format-Table Name, Status, StartType
Get-Volume | Format-Table DriveLetter, FileSystemLabel, SizeRemaining, Size
repadmin /showrepl localhost /errorsonly

4. Журналы

Смотрите System и Directory Service на DC, Netlogon на клиентах. Фиксируйте Event ID 5783 (нет DC), 1311 (KCC не построил дерево) — они направляют к репликации и сайтам, а не к «перезагрузи все DC».

Сохраняйте вывод в каталог заявки:

New-Item -ItemType Directory -Force C:\Temp\dc-diag | Out-Null
dcdiag /s:$dc /v /f:C:\Temp\dc-diag\dcdiag.txt

Решение по сценариям

Сценарий A. Узел пингуется, LDAP мёртв, диск заполнен

Освободите том без удаления C:\Windows\NTDS и SYSVOL. Кандидаты: IIS-логи, дампы, старые CBS, профили. После появления нескольких гигабайт:

Start-Service NTDS, Netlogon
dcdiag /test:Replications

Подробнее про диск: тема «Переполнен системный диск Windows Server» в плане раздела.

Сценарий B. VM не загружается

  1. Снимок состояния гипервизора и путь к VHDX/qcow до любых repair.
  2. Проверьте, что диск не в read-only и не кончился thin pool.
  3. Загрузите DC. Если AD DS не поднимается — DSRM, не seize.

Сценарий C. Сеть отрезала DC

С консоли: IP, шлюз, DNS на NIC должны указывать на внутренний DNS (обычно сам DC или партнёр), не на публичный 8.8.8.8 как единственный. Публичный резолвер не отдаёт _msdcs.

Сценарий D. Нужен ввод в работу второго DC, пока первый чинят

Это нормальный обходной путь для пользователей. Не удаляйте объект компьютера мёртвого DC из AD, пока не пройдёте процедуру удаления следов. Иначе получите lingering objects и 8606 при возврате.

Как проверить, что проблема устранена

С клиента, который раньше не входил:

nltest /dsgetdc:contoso.example /force
nltest /sc_query:contoso.example
nltest /sc_verify:contoso.example

С DC:

dcdiag /test:Advertising /s:DC01
repadmin /replsummary

Advertising должен показывать DC как DC, GC (если роль есть), KDC, Timeserv — в соответствии с фактическими ролями. Пользовательский логон с машины, ранее падавшей, — обязательный функциональный тест, не только зелёный dcdiag.

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

  • Есть LDAP, нет Kerberos: проверьте время (w32tm /query /status) и DNS SPN.
  • LDAP есть только локально: firewall профиля Domain vs Public.
  • База не монтируется: остановитесь и переходите к процедуре restore NTDS из проверенной копии. Не «чините» ntds.dit утилитами с форумов.
  • Один сайт без DC: клиенты ходят в другой сайт, если есть site link. Это медленно, но не равно «леса нет».

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

  • Минимум два DC на домен, DNS на обоих, GC по требованиям Exchange/поиска.
  • Мониторинг LDAP 389/636, свободного места NTDS, repadmin /replsummary.
  • Консоль гипервизора и iLO/iDRAC, не только RDP.
  • Перед патчем — проверка состояния AD.

FAQ

Можно ли просто выключить мёртвый DC и забыть?

Нет. Объект DC, NTDS Settings и SRV останутся. Клиенты будут периодически выбирать мёртвый узел. Нужна либо починка, либо документированное удаление.

Стоит ли сразу seize PDC?

Только если эмулятор PDC точно уничтожен и вход/время развалились. Для рядового DC без FSMO seize не нужен.

Почему RDP к DC есть, а вход в домен с рабочих мест нет?

RDP использует уже установленный сеанс или кэш. Логон рабочей станции требует LDAP+Kerberos+DNS. Это разные пути.

Нужно ли перезапускать все DC разом?

Нет. Катящийся рестарт по одному с проверкой репликации между ними.

Как понять, что это не массовый сбой DHCP?

При DHCP без аренды клиенты получают APIPA 169.254.x.x. Тогда нет маршрута до DC. Проверьте ipconfig /all до копания в NTDS.