АйТи Фреш
Главная / Статьи / Windows и рабочие места
Windows и рабочие места

Перенёс PDC Emulator на Windows Server 2025, а источник времени — Local CMOS Clock

Автор: Семёнов Евгений Сергеевич, директор ООО «АйТи-Фреш» · · ~25 мин чтения
Перенёс PDC Emulator на Windows Server 2025, а источник времени — Local CMOS Clock
Иллюстрация к статье «Перенёс PDC Emulator на Windows Server 2025, а источник времени — Local CMOS Clock».

Роли FSMO переехали на новый контроллер на Windows Server 2025, всё вроде бы работает, а `w32tm /query /source` на новом PDC выдаёт Local CMOS Clock. Это не баг переноса и не «домен сломался» — это ровно то, что и должно было произойти, потому что служба времени про FSMO ничего не знает. Ниже — почему так, как за четыре команды понять реальную картину, что настраивать на новом держателе роли, что обязательно откатить на старом, и почему на виртуалке гипервизор может тихо переиграть весь ваш NTP-конфиг.

Роль переехала — конфиг времени остался

Ситуация узнаваемая до боли. Подняли новый контроллер домена на Windows Server 2025, прогнали Move-ADDirectoryServerOperationMasterRole, проверили Get-ADDomain | Select PDCEmulator — роль там, где надо. Закрыли задачу. Через неделю кто-то от нечего делать запускает на новом PDC w32tm /query /source и видит Local CMOS Clock. Дальше обычно начинается нервотрёпка в чате: «домен без времени, всё пропало». Паниковать не нужно, а чинить нужно в тот же день — и вместе со старым контроллером, а не только с новым.

Перенос FSMO меняет атрибут в каталоге. Он не меняет ни одного значения в ветке HKLM\SYSTEM\CurrentControlSet\Services\W32Time. Служба времени Windows живёт своей жизнью и смотрит на параметр Type в подключе Parameters. У члена домена и у обычного контроллера там стоит NT5DS — «синхронизируйся по доменной иерархии». Ваш новый сервер до переезда роли был обычным контроллером, значит у него NT5DS и остался. Роль приехала, конфигурация — нет.

Иерархия времени в AD строится так: клиенты и рядовые серверы берут время у аутентифицировавшего их контроллера, контроллеры домена — у держателя роли PDC Emulator своего домена, а PDC каждого домена поднимается по иерархии доменов до PDC корневого домена леса. Плюс есть контроллеры с флагом GTIMESERV — «хороший источник времени для домена». Наверху этой цепочки спрашивать время уже не у кого. Корневой PDC, оставленный в режиме NT5DS, честно ищет вышестоящего партнёра, не находит и пишет в системный журнал событие с источником W32Time и ID 12. После этого он опирается на единственное, что у него есть, — часы материнской платы. Отсюда и Local CMOS Clock в выводе.

И тут же вторая половина проблемы, про которую забывают почти всегда. На старом PDC в реестре по-прежнему Type=NTP, прописан ручной список пиров и когда-то выставлен /reliable:yes. Он продолжает объявлять себя надёжным источником времени в домене, хотя роли у него уже нет. Получается два «главных»: один тянет корректное время из интернета, другой раздаёт время с CMOS. Пока оба живы, расхождение растёт медленно и незаметно. Как только старый сервер выключат — а его выключат, ради этого всё и затевалось, — домен останется на часах BIOS.

Событие W32Time ID 12 на корневом PDC — это не сетевая ошибка и не «не видит NTP». Это прямое сообщение: «я на вершине иерархии, а настроен брать время из иерархии». Пока вы не переведёте сервер в `Type=NTP` с внешним источником, оно будет повторяться вечно.

Диагностика: четыре команды и что в них реально смотреть

Не лезьте сразу в реестр. Сначала снимите картину — на новом PDC, на старом и на любом рядовом контроллере. Четыре команды дают 90 % ответа:

w32tm /query /source
w32tm /query /configuration
w32tm /query /status /verbose
w32tm /query /peers

/query /source — самое честное. Это фактический источник прямо сейчас, а не то, что вы когда-то настраивали. Плохих вариантов три: Local CMOS Clock (часы материнки, синхронизации нет вообще), Free-running System Clock (часы гостевой ОС в свободном ходе) и VM IC Time Synchronization Provider (сервер берёт время у гипервизора Hyper-V, а не по NTP). На корневом PDC любой из трёх — повод для работы.

/query /configuration показывает не только значения, но и откуда они взялись: рядом с каждым параметром стоит пометка вроде (Local) или (Policy). Это самый быстрый способ понять, что вы правите реестр, а групповая политика через час всё вернёт обратно. Смотрите там Type, NtpServer, AnnounceFlags, MaxPosPhaseCorrection, MaxNegPhaseCorrection, SpecialPollInterval.

/query /status /verbose даёт стратум, Root Delay, Root Dispersion, Phase Offset, интервал опроса и Last Successful Sync Time. Именно тут видно, что сервер «синхронизирован» (State Machine: 2 Sync), но с самим собой. Кстати, полезная деталь: W32Time принимает время только от источников со стратумом 15 и ниже — источник со стратумом 16 будет молча отброшен. А w32tm /stripchart /computer:<адрес> /dataonly /samples:10 покажет реальное смещение в секундах до конкретного NTP-сервера, не меняя при этом ничего. Эту команду можно и нужно запускать даже на боевом PDC — она использует эфемерный исходящий порт и не конфликтует со службой.

Если в `/query /configuration` параметры помечены как (Policy) — правка реестра или `w32tm /config` бесполезна: ближайший `gpupdate` затрёт всё обратно. Ищите GPO в разделе «Конфигурация компьютера → Административные шаблоны → Система → Служба времени Windows».
Перенёс PDC Emulator на Windows Server 2025, а источник времени — Local CMOS Clock — схема
Схема к статье. Открыть схему в полном размере

Разбор из практики: рекламное агентство «Точка контакта», 20 рабочих мест

Рекламное агентство «Точка контакта»: 20 рабочих мест — дизайнеры, аккаунт-менеджеры, бухгалтерия, один лес и один домен, два контроллера. DC01 — старый физический сервер на Windows Server 2016, держал все пять ролей FSMO и был настроен как источник времени ещё прежним подрядчиком, лет пять назад. DC02 — новая виртуальная машина на единственном хосте Hyper-V под Windows Server 2025 Standard, 2 vCPU и 8 ГБ памяти. Задача была простая: перенести роли на DC02, поднять рядом второй виртуальный контроллер для отказоустойчивости, а железку DC01 списать. Роли перенесли, дали домену три недели «отстояться», DC01 корректно понизили и выключили.

Через полтора месяца после выключения DC01 пришла жалоба: дизайнеры периодически получают отказ при подключении к файловому хранилищу с макетами, у бухгалтерии в журнале обмена документы помечаются временем, которое не совпадает с часами на ПК, а я при разборе инцидента не смог сопоставить журналы сервера и рабочих станций — метки не сходились. w32tm /query /source на DC02 — Local CMOS Clock. w32tm /stripchart до внешнего NTP показал смещение минус 3 минуты 41 секунда. Порог Kerberos по умолчанию — 5 минут. Дрейф часов конкретно этой виртуалки был около 5 секунд в сутки, то есть до массового отказа доменной аутентификации оставалось около двух недель. Домен ехал в стену на скорости пешехода, и никто этого не видел, потому что мониторинг смотрел на доступность службы времени, а не на её источник.

Разбор дал пять находок, и ни одна из них не была уникальной — я вижу этот набор из раза в раз. Первое: DC02 остался в Type=NT5DS, событие W32Time ID 12 писалось в журнал с самого дня переноса ролей — 47 раз за полтора месяца, и все 47 никто не прочитал. Второе: пока DC01 был жив, он продолжал раздавать время с /reliable:yes, и проблема не проявлялась — она включилась ровно в момент выключения старого сервера, то есть спустя три недели после «завершённой» миграции. Третье: настройки NTP на DC01 приезжали групповой политикой, у которой в фильтрации безопасности был прописан объект компьютера DC01$. Политика была привязана к машине, а не к роли, — и с переносом FSMO не поехала никуда. Четвёртое: на DC02 был активен провайдер синхронизации с гипервизором, а сам хост Hyper-V стоял в домене и брал время… с контроллера домена. Кольцо. Пятое, чисто про 2025: параметр UtilizeSslTimeData (это Secure Time Seeding, механизм грубой подстройки часов по SSL-меткам) в Windows Server 2025 по умолчанию равен нулю, тогда как во всех предыдущих версиях он был единицей. То есть страховки, которая раньше не давала часам уехать совсем далеко, на новом сервере просто нет по умолчанию.

Чинили полчаса. На DC02 — перевод в NTP с тремя внешними источниками, /reliable:yes, отключение службы интеграции «Синхронизация времени» для этой ВМ на хосте, MaxPosPhaseCorrection и MaxNegPhaseCorrection по 3600 вместо дефолтных для контроллера 172 800. На хосте Hyper-V — явный внешний NTP вместо доменной иерархии. GPO переписали: вместо фильтрации по объекту компьютера сделали группу безопасности AD-PDC-TimeSource, в которую входит текущий держатель роли; при следующем переносе FSMO достаточно поменять членство в группе. Источник сменился сразу после w32tm /resync /rediscover. Прыжка часов не было: смещение в 221 секунду меньше MaxAllowedPhaseOffset (у членов домена по умолчанию 300 секунд), а в этом случае служба по документации подводит часы изменением скорости хода, а не переставляет их ступенькой. Через час w32tm /stripchart до внешнего источника показывал десятки миллисекунд, w32tm /monitor /domain — разброс между контроллерами в тех же пределах. За четыре месяца после — ни одного события 36, 47 или 50.

Самое опасное в этой истории — отложенный эффект. Пока старый PDC не выключен, он продолжает раздавать корректное время и полностью маскирует проблему. Проверять источник времени надо не после переноса ролей, а после вывода старого сервера из эксплуатации. Лучше — и там, и там.
Цифры и версии: Разбор из практики: рекламное агентство «Точка контакта», 20 рабочих мест — схема
Цифры и версии: Разбор из практики: рекламное агентство «Точка контакта», 20 рабочих мест. Открыть схему в полном размере

Как я настраиваю корневой PDC: команды и осмысленные значения

Настройка занимает одну команду и один рестарт службы. В официальном примере Microsoft для корневого PDC один источник с флагом 0x8; я делаю то же самое, только с тремя источниками вместо одного:

w32tm /config /syncfromflags:manual /manualpeerlist:"ntp1.vniiftri.ru,0x8 ntp2.vniiftri.ru,0x8 ru.pool.ntp.org,0x8" /reliable:yes /update
net stop w32time && net start w32time
w32tm /resync /rediscover
w32tm /query /source

Разберу по частям, потому что половина ошибок именно здесь. /syncfromflags:manual — брать время только из ручного списка (альтернатива domhier — из доменной иерархии, именно её надо вернуть на старом PDC). /manualpeerlist — список через пробел, обязательно в кавычках, если серверов больше одного. Суффикс после запятой — это флаги: 0x1 SpecialInterval (опрашивать с интервалом SpecialPollInterval), 0x2 UseAsFallbackOnly (резервный источник), 0x4 SymmetricActive, 0x8 Client — обычный клиентский режим. Значение 0x9 — это 0x8|0x1, клиент с фиксированным интервалом опроса; именно оно стоит в дефолте групповой политики для time.windows.com. Я ставлю 0x8 и не трогаю интервал: с Windows Server 2016 алгоритмы опроса стали ближе к RFC, и жёсткий SpecialPollInterval чаще мешает, чем помогает. /reliable:yes помечает контроллер как надёжный источник — на PDC это обязательно, иначе остальные DC не будут ему доверять как следует.

Про количество источников. Microsoft прямо рекомендует после Windows Server 2016 указывать три и более NTP-сервера. С двумя алгоритм отбора работает плохо: нет большинства, некому «проголосовать» против сбойного. Если у вас всё же ровно два, поставьте второму флаг 0x2 (UseAsFallbackOnly), чтобы он был явным резервом, а не равноправным источником: "ntp1.example.ru,0x8 ntp2.example.ru,0x2". И проверьте, что UDP/123 открыт наружу в обе стороны — встроенный NTP-клиент Windows умеет использовать в качестве исходящего порта только 123, эфемерные порты не подойдут, и NAT/файрвол с ограничением по портам это ломает.

Дальше — два параметра, которые я правлю всегда. MaxPosPhaseCorrection и MaxNegPhaseCorrection по умолчанию на контроллере домена равны 172 800 секунд, то есть 48 часов. Это значит, что сервер молча примет и применит поправку в двое суток, если ему подсунуть кривой источник. Я ставлю час, а на площадках со стабильной связью — полчаса. Если реальное расхождение окажется больше порога, служба не переведёт часы, а запишет событие в журнал — что мне и нужно: пусть лучше время не сойдётся и я об этом узнаю, чем сервер прыгнет на двое суток и утащит за собой весь домен.

reg add "HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config" /v MaxPosPhaseCorrection /t REG_DWORD /d 3600 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config" /v MaxNegPhaseCorrection /t REG_DWORD /d 3600 /f
net stop w32time && net start w32time

Отдельно про AnnounceFlags, вокруг которого до сих пор нет единого мнения — и я скажу честно, что спор не закрыт. Классическая статья Microsoft KB816042 велит выставлять 5 (0x1 «всегда сервер времени» + 0x4 «всегда надёжный»), а в реестровой процедуре той же статьи к каждому пиру в NtpServer дописывается ,0x1. При этом дефолтное значение в самой системе и в групповой политике — 10 (0xA = 0x2 «автоматический сервер времени» + 0x8 «автоматический надёжный сервер времени»), и та же статья Microsoft оговаривает: если связь с вышестоящим NTP нестабильна или вы используете фиксированный SpecialPollInterval, ставьте 0xA, а не 0x5. Моя позиция: на офисном домене с интернет-источником AnnounceFlags вообще не трогать — дефолтная десятка работает правильно и сама снимает объявление надёжности, когда PDC потерял внешний источник. Жёсткая пятёрка нужна там, где источником служит локальный GPS/PTP-приёмник, который заведомо всегда доступен.

Microsoft отдельно предупреждает: при синхронизации с интернет-источником аутентификации NTP нет вообще. Если у вас требования по ИБ выше среднего — источник времени должен быть свой: GPS/ГЛОНАСС-приёмник или NTP-сервер внутри периметра, а публичные пулы оставьте резервом.

Что обязательно откатить на старом PDC — это забывают чаще всего

Половина инцидентов, которые я разбираю по этой теме, — не про новый сервер, а про старый. Он остаётся настроенным как источник времени: Type=NTP, ручной пирлист, /reliable:yes. В домене появляются два авторитета, и какой из них выиграет у конкретного клиента — вопрос везения и топологии сайтов. Верните бывший PDC в общую иерархию, это одна команда:

w32tm /config /syncfromflags:domhier /reliable:no /update
net stop w32time && net start w32time
w32tm /resync /rediscover
w32tm /query /source

После рестарта /query /source на старом контроллере должен показать имя нового PDC. Если показывает по-прежнему внешний NTP или Local CMOS Clock, значит в реестре остался хлам от прошлых настроек или мешает политика. В запущенных случаях — а «запущенный случай» это обычно сервер, который настраивали трижды разные люди за десять лет, — я не разбираю конфиг по кирпичику, а сбрасываю службу в заводское состояние и настраиваю заново:

net stop w32time
w32tm /unregister
w32tm /register
net start w32time
w32tm /config /syncfromflags:domhier /update
w32tm /resync /rediscover

И третье, что нужно проверить обязательно, — групповые политики. Если настройки NTP раздавались через GPO (раздел «Конфигурация компьютера → Административные шаблоны → Система → Служба времени Windows → Поставщики времени → Настроить клиент NTP Windows»), то с большой вероятностью область применения этой политики была ограничена фильтрацией безопасности на объект компьютера старого PDC. Роль уехала — политика осталась. Мой рабочий приём: завести в домене группу безопасности вида AD-PDC-TimeSource, положить в фильтрацию безопасности GPO её, а в саму группу — учётную запись компьютера текущего держателя роли. Тогда перенос FSMO сводится к правке членства в группе и одному gpupdate /force, а не к археологии в GPMC через полгода. И помните про важную оговорку Microsoft: если NtpServer задан политикой «Настроить клиент NTP Windows» на члене домена, служба не использует одноимённое значение из обычной ветки реестра — смотреть надо только через w32tm /query /configuration.

Пока старый PDC жив и раздаёт время, проблема невидима. Проверяйте источник времени на всех контроллерах домена сразу после понижения и выключения старого сервера — это тот момент, когда всё и ломается.
Порядок действий: Что обязательно откатить на старом PDC — это забывают чаще всего — схема
Порядок действий: Что обязательно откатить на старом PDC — это забывают чаще всего. Открыть схему в полном размере

Гипервизор против NTP: кто победит на виртуальном контроллере

Отдельная засада, если новый PDC — виртуальная машина. У службы времени Windows плагинная модель, и провайдеров может быть несколько одновременно: NTP-клиент и провайдер синхронизации с гипервизором. Когда провайдеров больше одного, Windows выбирает лучший по формальным признакам — сначала по стратуму, затем по root delay, затем по root dispersion и в последнюю очередь по смещению. Провайдер гипервизора обычно объявляет очень низкий стратум, потому что «часы прямо тут, на хосте, задержки нет». В результате он честно выигрывает у любого сетевого NTP-источника — и ваш аккуратный manualpeerlist оказывается неиспользованным украшением реестра.

Дальше начинается самое интересное. Если хост Hyper-V сам введён в домен и берёт время по доменной иерархии — то есть в конечном счёте у PDC, который на нём же и крутится, — получается замкнутое кольцо. Формально всё синхронизировано, фактически весь домен живёт на часах материнской платы хоста и вместе с ними дрейфует. Именно это я и нашёл в разобранном выше случае. Позиция Microsoft здесь однозначная: для виртуальных машин, которые работают контроллерами домена, синхронизацию времени между хостом и гостевой ОС рекомендуется отключать — тогда гость берёт время по доменной иерархии, а корневой PDC — у внешнего NTP. Штатный способ в Hyper-V: выключить ВМ, открыть её параметры, раздел «Службы интеграции», и снять флажок «Синхронизация времени». То же самое делается из PowerShell на хосте, а на стороне гостя провайдер можно дополнительно погасить в реестре:

# на хосте Hyper-V; на русскоязычном хосте имя службы интеграции — «Синхронизация времени»
Get-VMIntegrationService -VMName DC02
Disable-VMIntegrationService -VMName DC02 -Name "Time Synchronization"
rem внутри гостя - дополнительная страховка
reg add "HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider" /v Enabled /t REG_DWORD /d 0 /f
net stop w32time && net start w32time
w32tm /query /source

На VMware логика та же, но есть важная оговорка из базы знаний VMware (KB 1318, Timekeeping best practices for Windows). Снятие флажка синхронизации в VMware Tools, параметр tools.syncTime = "0" в .vmx или команда VMwareToolboxCmd.exe timesync disable в госте отключают только периодическую синхронизацию с хостом. Разовые подводки часов при старте VMware Tools, создании снапшота и возврате к нему остаются. Отсюда практическое правило: периодическую синхронизацию с хостом выключаем, а начальную оставляем и делаем её безопасной — у самого ESXi должен быть настроен корректный NTP, иначе при каждом старте ВМ контроллер получит кривое время от хоста. Снапшоты — отдельная тема: Microsoft прямо не рекомендует снимать и использовать снимки виртуальных контроллеров, и откат на снимок двухнедельной давности — это не только риск USN rollback, но и прыжок часов назад. Ещё одна причина, по которой я ставлю MaxNegPhaseCorrection в час: такой прыжок не будет молча применён.

По рядовым виртуальным контроллерам я иду за рекомендацией Microsoft и тоже отключаю синхронизацию с хостом: доменная иерархия даёт им время от PDC, а после старта ВМ хватает разовой подводки. Ключевое правило при этом другое: хост виртуализации не должен брать время у гостей, которых он же и обслуживает. Настройте хосты Hyper-V и ESXi на тот же внешний NTP, что и PDC, — и кольцо не возникнет ни при какой комбинации настроек, а разовые подводки при старте ВМ будут приносить правильное время.

Классическое кольцо: PDC — виртуалка, гипервизор берёт время из домена, домен берёт время у PDC. Формально всё зелёное, фактически весь лес синхронизирован с часами BIOS одного физического сервера.

Проверка, мониторинг и чек-лист на следующий перенос FSMO

После настройки не ограничивайтесь w32tm /query /source на одном сервере. Пройдите по всему домену одной командой — она обходит контроллеры и показывает смещение каждого относительно того, с которого вы её запустили. Асимметричные каналы и загруженные линки дают лишние миллисекунды, но десятки секунд разброса — это уже диагноз:

w32tm /monitor /domain:corp.example.ru
w32tm /stripchart /computer:dc03.corp.example.ru /dataonly /samples:10

Мониторинг я строю не на «служба W32Time запущена» — она запущена всегда, даже когда время берётся с CMOS. Полезных сигналов три. Первый: выход w32tm /query /source — если на PDC там строка Local CMOS Clock, Free-running System Clock или VM IC Time Synchronization Provider, это авария, а не предупреждение. Второй: смещение из w32tm /query /status в секундах — порог тревоги я ставлю на 30 секунд, задолго до пятиминутного порога Kerberos. Третий: события источника W32Time в системном журнале — ID 12 (корневой PDC настроен на доменную иерархию, а спрашивать время ему не у кого), 29 (ни один из источников недоступен), 36 (служба давно не синхронизировала системное время — по умолчанию сутки), 47 (нет ответа от заданного вручную пира), 50 (обнаружено расхождение времени). В Zabbix это два-три айтема на контроллер, делается за вечер и снимает целый класс отложенных аварий.

И последнее — процедура. Перенос FSMO у меня в чек-листе идёт не одним пунктом, а пятью, и время там отдельным блоком. Если бы этот чек-лист был у «Точки контакта», разговор про Kerberos через полтора месяца просто не состоялся бы. Про запас по точности: Kerberos терпит 5 минут по умолчанию, но это самый мягкий из потребителей времени. Кластеры, SQL, репликация AD, сопоставление журналов при расследовании, проверка сроков действия сертификатов, платёжные требования PCI (там речь про секунду) — все они ломаются гораздо раньше пятиминутного порога, и ломаются некрасиво, потому что диагностируются не как проблема времени.

Практический вывод в одну строку: перенос FSMO — это операция в каталоге, а настройка времени — операция в реестре и GPO. Они не связаны между собой ничем, кроме вашего чек-листа.
Порядок действий: Проверка, мониторинг и чек-лист на следующий перенос FSMO — схема
Порядок действий: Проверка, мониторинг и чек-лист на следующий перенос FSMO. Открыть схему в полном размере

Частые вопросы

Обязательно ли настраивать NTP именно на держателе роли PDC Emulator?

В стандартной схеме — да: корневой PDC леса находится на вершине иерархии времени, и спрашивать время ему не у кого. Альтернатива есть: контроллер с флагом GTIMESERV («хороший источник времени для домена»), которому можно отдать эту функцию, чтобы она не ездила вместе с ролью FSMO. Для домена до полусотни рабочих мест я эту конструкцию считаю избыточной — проще настроить PDC и внести проверку времени в чек-лист переноса ролей.

Почему `w32tm /query /source` показывает Local CMOS Clock, хотя NtpServer в реестре прописан?

Три частые причины. Первая: `Type` остался `NT5DS`, и список пиров просто не используется — нужен `/syncfromflags:manual`. Вторая: параметры пришли групповой политикой и перекрывают реестр, проверяйте через `w32tm /query /configuration` пометки (Policy). Третья: источники прописаны, но недоступны — UDP/123 закрыт наружу либо DNS не резолвит имена; проверяется командой `w32tm /stripchart /computer:<адрес>`.

Сколько NTP-серверов указывать и какие флаги ставить?

Microsoft после Windows Server 2016 рекомендует три и более. Каждому источнику дописывайте `,0x8` (клиентский режим). Если серверов ровно два, второму ставьте `,0x2` — UseAsFallbackOnly, чтобы он был явным резервом. Список из нескольких адресов в `w32tm /config /manualpeerlist` обязательно берите в кавычки, разделитель — пробел.

Нужно ли выключать синхронизацию времени с гипервизором на виртуальном контроллере домена?

Да, и Microsoft рекомендует это для любых виртуальных контроллеров, а не только для PDC: гость-DC должен брать время по доменной иерархии, корневой PDC — у внешнего NTP. В Hyper-V снимается флажок «Синхронизация времени» в службах интеграции ВМ. В VMware выключается периодическая синхронизация Tools, но разовые подводки при старте и снапшотах остаются, поэтому у ESXi должен быть корректный NTP. И главное правило: хост виртуализации настраивайте на тот же внешний NTP, что и PDC, а не на домен.

Насколько это срочно, если расхождение всего несколько секунд?

Не паникуйте, но и не откладывайте. Kerberos по умолчанию терпит 5 минут, до этого порога от секунд идти долго. Но раньше Kerberos ломаются другие вещи: сопоставление журналов при расследовании инцидентов, кластеры и SQL, репликация AD, проверки сроков сертификатов. И главное — источником секунд обычно является нескорректированный CMOS, который дрейфует линейно: то, что сегодня три секунды, через два месяца станет тремя минутами.

Что изменилось в службе времени именно в Windows Server 2025?

Ключевое отличие в дефолтах: параметр `UtilizeSslTimeData` (Secure Time Seeding — грубая подстройка часов по меткам из SSL-соединений) в Windows Server 2025 по умолчанию равен 0, тогда как во всех предыдущих версиях с этой функцией он равен 1. Практический вывод: страховки от «часы уехали совсем далеко» на новом сервере по умолчанию нет, корректный NTP становится не пожеланием, а обязательным условием.

Столкнулись с похожей задачей? Обращайтесь — решим

Если у вас происходит что-то из описанного в этой статье — или любая другая проблема с ИТ-инфраструктурой, — обращайтесь в любое время. Мои специалисты и я лично разберём ситуацию, найдём настоящую причину и доведём до решения.

Возьмёмся и за разовую задачу, и за постоянное обслуживание. Первичная консультация — бесплатно и без обязательств.

📞 +7 903 729-62-41 💬 MAX: +7 903 729-62-41 ✈ Telegram @ITfresh_Boss

С уважением, Семёнов Евгений Сергеевич, директор «АйТи Фреш» — IT-аутсорсинг для компаний до 50 рабочих мест, 15+ лет практики

Источники

© ООО «АйТи-Фреш» · Москва · Все статьи