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

В домене источник времени — эмулятор PDC. Клиенты и остальные DC синхронизируются по доменной иерархии (NT5DS), не каждый сам с pool.ntp.org. Снимите w32tm /query /source на PDC, на DC01 (если это не PDC) и на WS-042. Если skew больше примерно пяти минут, Kerberos начинает отказывать, и это выглядит как «нет DC».

Не переводите часы вручную на всех серверах и не указывайте внешний NTP сразу всем. Сначала живой PDC, внешний NTP только на нём (и опционально на запасном, когда он станет PDC).

Симптомы и как отличить

  • Логон: «нет доступных серверов» при живом LDAP.
  • klist / события Kerberos: разница часов.
  • repadmin ругается на время партнёра.
  • Журнал System на клиенте: W32Time 35/37/50.
КартинаНе «время»Куда
Один ПК, остальные входятканал, DNS, профильвход
PDC не отвечаетFSMO / DC downFSMO, DC
Secure channelпароль компьютерадоверие

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

  1. PDC указал сам на себя, сломан внешний NTP, или VM-интеграция Hyper-V/VMware перетягивает часы гостя.
  2. Рядовой DC/клиент с NTP вместо NT5DS (кто-то прописал w32tm /config /manualpeerlist на все).
  3. VM с интеграцией time sync + доменная иерархия = скачки.
  4. Сеть режет UDP 123 до внешнего источника с PDC; PDC уходит в Free-running.
  5. После seize PDC новый владелец не настроен как NTP-клиент к внешнему источнику.
  6. Большой шаг времени после восстановления из снимка DC (это уже рядом с USN rollback — остановитесь).

Диагностика

1. Кто PDC и что у него за источник

netdom query fsmo
w32tm /query /status /verbose
w32tm /query /configuration
w32tm /query /source

На эмуляторе PDC Source должен быть внешний NTP или аппаратные часы хоста осознанно, не VM IC Time Synchronization Provider, если вы не приняли эту модель. На рядовом DC и на WS-042 источник — DC иерархии (часто PDC сайта).

2. Сравнение узлов

w32tm /stripchart /computer:DC01.contoso.example /samples:5 /dataonly
w32tm /monitor /domain:contoso.example

Смотрите смещение (NTP offset), не только «синхронизировано: да».

3. Клиент

На WS-042:

w32tm /query /status
w32tm /query /source
Get-WinEvent -FilterHashtable @{ LogName = 'System'; ProviderName = 'Microsoft-Windows-Time-Service' } -MaxEvents 20 |
  Format-Table TimeCreated, Id, Message -Wrap

4. Гипервизор

В интеграции Hyper-V: Time synchronization для DC лучше выключить, если гость берёт домен/NTP. На VMware — tools time sync для DC обычно выкл. Сверьте фактический провайдер в w32tm /query /source.

Решение

Сценарий A. Иерархия сломана на членах домена

На рядовом DC и рабочих станциях верните доменную иерархию:

w32tm /config /syncfromflags:domhier /update
Restart-Service W32Time
w32tm /resync /rediscover

Не оставляйте manualpeerlist на файловых серверах «для точности».

Сценарий B. PDC без внешнего источника

На только PDC (подставьте свой NTP, который вам разрешён политикой):

w32tm /config /manualpeerlist:"ntp.contoso.example" /syncfromflags:manual /reliable:yes /update
Restart-Service W32Time
w32tm /resync /force
w32tm /query /source

Сценарий C. Гость-DC прыгает из-за интеграции

Отключите time sync интеграции для VM контроллера, оставьте W32Time. Снимок/восстановление DC — отдельный риск для AD, не только для часов.

Сценарий D. Часы убежали на часы

Если skew гигантский, сначала почините источник, затем w32tm /resync. Ручной Set-Date на DC — крайняя мера: резкий шаг ломает Kerberos и журналы. Лучше ступенчато дать W32Time самого подтянуть, если шаг в пределах MaxAllowedPhaseOffset; иначе планируйте короткое окно логона.

Сценарий E. GPO переопределяет W32Time на клиентах

Частая ловушка: на PDC иерархия верная, а на WS-042 w32tm /query /configuration показывает Type NTP и чужой NtpServer. Ищите GPO Computer Configuration → Administrative Templates → System → Windows Time Service. Пока политика жива, ручной w32tm /config /syncfromflags:domhier откатится на следующем computer-цикле.

gpresult /h C:\Temp\gpo-time-WS-042.html /scope:computer

В HTML ищите Windows Time / Configure Windows NTP Client. Если политика должна быть только на PDC — фильтруйте её на OU контроллеров, не на Workstations.

Смещение внутри виртуального хоста: если все гости «прыгают» одинаково, смотрите часы гипервизора, не каждый DC по отдельности. Тогда сначала NTP на хосте, потом доменная иерархия.

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

w32tm /monitor /domain:contoso.example
w32tm /stripchart /computer:DC01.contoso.example /samples:5 /dataonly

Смещение между PDC, DC01 и WS-042 — секунды, не минуты. Логон пользователя с машины, которая не входила. nltest /dsgetdc:contoso.example. Репликация: repadmin /replsummary без ошибок времени.

Kerberos: новый логон, klist показывает билеты с разумным Start/End относительно текущего времени узла.

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

  • Источник Local CMOS Clock на членах домена — служба не дошла до DC: firewall UDP 123 внутри площадки, W32Time Stopped, виртуальный NIC.
  • PDC синхронизируется, клиенты нет: GPO, которая переопределяет W32Time на клиентах.
  • Только Linux/Java-приложения падают: их допуск skew жёстче; всё равно чините иерархию Windows, не «отключайте проверку времени» в приложении насовсем.
  • PDC недоступен: сначала роль и узел, не NTP.

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

  • Мониторинг смещения PDC к эталону и клиентов к PDC (порог сильно меньше пяти минут).
  • Документированный NTP для PDC, доступен из VLAN управления.
  • Time sync интеграции выкл на DC-гости.
  • После передачи FSMO — сразу настройка W32Time на новом PDC и снятие /reliable:yes со старого, если он жив как рядовой DC.
  • Не держать DC на снапшотах.

FAQ

Можно ли на всех серверах прописать pool.ntp.org?

Не в домене. Потеряете иерархию, получите два источника правды и случайный skew между сайтами.

Почему Hyper-V «уже синхронизирует» и W32Time всё равно нужен?

Интеграция не знает про Kerberos-иерархию леса и про PDC. Для DC это конкурирующий источник скачков.

Скев 2 минуты — надо срочно чинить?

Да, как деградацию: до пяти минут Kerberos ещё терпит, но NTP уже болен. Не ждите логон-шторма.

w32tm /resync пишет «компьютер не синхронизировался». Что дальше?

Смотрите /query /source и UDP 123 до источника. Resync не чинит неверный Type (NTP vs NT5DS) и мёртвый peer.

Нужно ли совпадать часовому поясу?

Для Kerberos важны UTC-часы. Пояс может отличаться; «у нас +3, у DC +0 в трее» при одинаковом UTC — не эта авария.

Смена PDC без настройки времени что ломает?

Новый PDC может остаться клиентом старой иерархии и одновременно объявиться источником для домена. Клиенты расходятся. Передача FSMO всегда включает шаг W32Time.