Час Windows постійно відхиляється: забуте виправлення NTP

Що таке дрейф часу насправді (і чому Windows особливий)

Дрейф часу — це відхилення системного годинника від «істинного» часу. Звучить філософськи, поки ви не спробуєте перевірити сертифікат, який «ще не дійсний» або «прострочений», бо машина вважає, що зараз минулий вівторок. Дрейф — нормальне явище; кварцові генератори неточні, змінюється температура, а віртуальні машини залежать від джитеру планувальника та пауз vCPU.

Ненормальний — це невпинний дрейф. NTP існує, щоб машини могли постійно коригуватися. Але Windows не є типовим NTP-клієнтом так, як багато хто очікує. Служба часу Windows (w32time) спроектована першочергово для узгодженості домену Windows, а не для змагання в точності.

В середовищі Active Directory «правильний» дизайн — це ієрархія: робочі станції та члени домену синхронізуються з контролерами домену, контролери домену синхронізуються вгору по ланцюгу, а емультор PDC кореня лісу — це джерело, яке ви вважаєте авторитетним (з зовнішніми NTP-джерелами). Якщо ви протиставите цій моделі, направивши випадкові учасники домену на випадкові зовнішні NTP-сервери, ви можете створити «розкол у думці» годинника і провести день, пояснюючи, чому Kerberos сердиться.

Також: Windows має власні уподобання щодо стрибків проти плавного регулювання (швидке зсування часу vs поступове коригування), інтервалів опитування і утримання часу, коли джерело ненадійне. До того ж гіпервайзери та інструменти гостьової ОС часто «виправляють» час самостійно — іноді грубо. Двоє «хранителів часу» в одній машині — це не резервування; це судова суперечка за опіку.

Жарт №1: Дрейф часу — як технічний борг: він тихо накопичується до наступного простою, а тоді всі раптом мають дуже сильні почуття з цього приводу.

Факти та історія, які стануть у пригоді в постмортемі

Це не тривіальність заради тривіальності. Це маленькі фрагменти контексту, які допоможуть обрати правильне рішення і захистити його під час розгляду змін.

1. NTP старий (1980-ті) і перевірений на практиці. Він передує більшості систем, які зараз підтримує. Протокол еволюціонував, щоб терпіти джиттер мережі і недосконалі годинники.
2. Windows Time (w32time) зосереджувався на коректності домену. Microsoft створив його, щоб підтримувати Kerberos та AD, а не конкурувати з високоточними NTP-демонами лабораторного рівня.
3. Kerberos має сувору толерантність до зсуву годинника. Якщо клієнт і DC розходяться більше ніж у невеликому вікні, автентифікація падає і виглядає як «випадкові проблеми з входом».
4. Віртуалізація зробила дрейф частішим. ВМ можуть призупинятися, мігруватися, відключатися з планувальника або відновлюватися зі знімків; усе це може збивати наївний годинник.
5. Заблукання між SNTP і NTP триває. Багато систем відповідають у спрощеному стилі NTP, але не реалізують дисциплінарні алгоритми NTP повністю. w32time історично у деяких сценаріях поводився ближче до SNTP.
6. Космічні секунди — реальна операційна загроза. Різні платформи обробляли їх по-різному (стрибком, «smear» або ігнорували). Непослідовна обробка створює дрібні, але різкі розбіжності.
7. Синхронізація часу — і надійність, і безпека. Аудит, судова експертиза, терміни токенів і перевірка сертифікатів усі припускають, що годинники не брешуть.
8. Деякі середовища забороняють вихідний NTP. Підприємства часто обмежують UDP/123. Це змушує використовувати внутрішні джерела часу — і робить ієрархію незаперечною.
9. Аппаратні годинники сильно відрізняються. Дешеві осцилятори дрейфують; температура впливає на частоту; ноутбуки при сні/пробудженні роблять час «творчим».

Швидкий план діагностики (перший/другий/третій)

Якщо час дрейфує, не починайте зі зміни налаштувань. Почніть з визначення, якому джерелу годинник дійсно підкоряється і чи не борються кілька авторитетів. Ось найшвидший шлях до вузького місця.

Перший: підтвердьте симптом і масштаби

• Один хост, один OU, один сайт або «весь домен»?
• Дрейф постійний, чи відбувається стрибок після відновлення/міграції?
• Який вплив: автентифікація (Kerberos), TLS, планувальник завдань або логи?

Другий: визначте активне джерело часу і останню синхронізацію

• На ураженій машині: що показує w32tm /query /status для Source і Last Successful Sync Time?
• На членах домену: чи синхронізуються вони з доменом (очікувано), чи з зовнішнім піаром (зазвичай неправильно)?
• На DC: чи PDC емулатор синхронізується зовні, і чи інші DC синхронізуються від нього?

Третій: шукайте конкурентів серед постачальників часу

• Hyper-V: увімкнена служба синхронізації часу інтеграції?
• VMware: увімкнена синхронізація часу VMware Tools?
• Veeam/інструменти резервного копіювання: відновлення/знімки спричиняють стрибки часу?
• GPO/безпечний базовий набір: чи політика не змінила налаштування NTP або не відключила постачальників?

Якщо згадати лише одне: дрейф часу зазвичай проблема контрольної площини, а не фізики. Виправте ланцюг авторитетів і боротьба припиниться. Потім фізичні причини стануть керованими.

Ієрархія часу у Windows: хто має синхронізуватися з ким

У домені Windows перестаньте мислити «налаштування NTP-сервера» як щось, що застосовується до кожної машини. Такий підхід дає домен, де кожен вузол вважає різний годинник за істину, і тоді Kerberos починає відкидати квитки, бо флот не може домовитися, яка зараз хвилина.

Члени домену (робочі станції, сервери-члени)

Вони повинні синхронізуватися від домену. Це зазвичай означає режим NT5DS, що підказує Windows слідувати ієрархії домену автоматично. Їхній «NTP-сервер» — не публічний пул; це DC, з яким вони спілкуються.

Контролери домену

Некритичні PDC DC повинні синхронізуватися з ієрархією домену (зрештою від PDC емулатора). Вони не повинні всі бути спрямовані в інтернет. Це створює флапінг джерела часу і ускладнює розуміння коректності.

Емулятор PDC лісу (головний)

Це той, що має мати явні, надійні верхні джерела часу. Якщо ви конфігуруєте зовнішній NTP, робіть це тут. Якщо ви в регульованому середовищі, використовуйте внутрішні пристрої stratum-1/2 або джерела з GPS. Якщо ні — оберіть пару стабільних внутрішніх NTP-серверів і дайте їм доступ вгору — потім спрямовуйте PDC на них.

Самостійні машини (не приєднані до домену)

Це Дикий Захід. Тут налаштування пір напряму — нормальна практика, але слід стежити за втручанням гіпервайзера і за розумністю інтервалів опитування.

Забуте виправлення NTP: змагальні джерела часу

Більшість інцидентів «дрейф часу у Windows», які я бачив, не вирішувалися додаванням ще більше NTP-серверів. Їх вирішували шляхом видалення другого (і третього) джерела часу, яке потай підривало дисципліну w32time.

Класична боротьба: w32time проти гіпервайзера

Гіпервайзери часто надають «корисний» механізм синхронізації часу. Він може бути чудовим для недоменних Linux-утилітних ВМ і жахливим для серверів Windows, приєднаних до домену. Чому? Тому що зазвичай він стрибком коригує час (зриває), особливо після паузи/відновлення, відновлення зі знімка або живої міграції. Тим часом w32time намагається поступово коригуватися за зразками NTP. Результат:

• Періодичні раптові стрибки часу (коригує інструмент VM)
• Потім повільне виправлення дрейфу (w32time намагається стабілізувати)
• Потім ще один стрибок (інструмент знову коригує)

Ззовні це виглядає як «NTP не працює». Всередині — його просто підривають.

Інша боротьба: GPO встановлює NTP-піри на членів домену

Хтось пише добре намірену політику: «Усі Windows-машини повинні синхронізуватися з time.company.local». Її застосовують до всіх OU. Вітаю: ви щойно перевизначили ієрархію домену і створили залежність від одного сервера (або ще гірше — від IP, який недоступний у кожному сайті). Члени домену не повинні мати явних піров. Вони потребують функціонального ланцюга часу домену.

Непомітна боротьба: «оптимізація» шляхом зміни інтервалів опитування

Люди бачать дрейф і крутять опитування на агресивніші налаштування, думаючи, що більше зразків означає кращий час. Іноді так. Частіше це збільшує навантаження, провокує лімітування зверху і змушує w32time вважати джерело нестабільним. Або це підтримує осциляцію годинника, бо ви фактично перетягуєте корекцію.

Що робити: оберіть по одному авторитету на шар. Вимкніть або обмежте решту. Тримайте ієрархію чистою. Якщо потрібна синхронізація гіпервайзера, використовуйте її свідомо (зазвичай для PDC емулатора ви не хочете, щоб гіпервайзер стрибком коригував час; для деяких ізольованих навантажень може бути прийнятно).

Ідея надійності перефразована: Перефразована ідея: John Allspaw стверджує, що надійність виникає з розуміння того, як системи падають в реальних умовах, а не з віри у схеми щасливого шляху.

Практичні завдання з командами: перевірити, вирішити, виправити

Дрейф не виправляють за відчуттями. Його виправляють, читаючи, що система вважає за своє, потім змінюючи по одному елементу та валідувавши. Нижче — практичні завдання. Кожне містить (1) команду, (2) приклад виводу, (3) що це означає, і (4) рішення, яке слід прийняти.

Завдання 1: Перевірити активне джерело часу на машині Windows

cr0x@server:~$ w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 3 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0312500s
Root Dispersion: 0.1015625s
ReferenceId: 0xC0A8010A (source IP:  192.168.1.10)
Last Successful Sync Time: 2/5/2026 9:42:11 AM
Source: DC01.corp.local
Poll Interval: 10 (1024s)

Значення: Машина синхронізується з DC01. Для члена домену це зазвичай правильно. Poll Interval показує, як часто вона опитує.

Рішення: Якщо це член домену і джерело — DC, добре. Якщо вказано зовнішній NTP-сервер або «Local CMOS Clock», маєте проблему конфігурації/авторитету.

Завдання 2: Визначити, чи машина в режимі ієрархії домену або має ручні піри

cr0x@server:~$ w32tm /query /configuration
[TimeProviders]
NtpClient (Local)
DllName: C:\Windows\system32\w32time.dll
Enabled: 1
InputProvider: 1

[Parameters]
NtpServer: time.company.local,0x9
Type: NTP

Значення: Type: NTP означає, що налаштовані ручні піри. У членів домену це часто перевизначає задуману ієрархію домену.

Рішення: Для членів домену: змініть Type назад на NT5DS (ієрархія домену). Для PDC емулатора: ручні піри — доречні.

Завдання 3: Примусити повторну синхронізацію і подивитися, чи вдасться

cr0x@server:~$ w32tm /resync /force
Sending resync command to local computer...
The command completed successfully.

Значення: Клієнт звернувся до свого джерела і оновив час (або принаймні вважає, що зробив).

Рішення: Якщо resync не вдається — йдіть прямо до перевірки доступності, брандмауера та журналів подій. Якщо вдається, але дрейф продовжується — підозрюйте конкуренцію джерел або погане верхнє джерело.

Завдання 4: Виміряти зсув відносно конкретного піра

cr0x@server:~$ w32tm /stripchart /computer:DC01.corp.local /samples:5 /dataonly
09:45:01, +00.0123456s
09:45:03, +00.0119023s
09:45:05, +00.0121011s
09:45:07, +00.0124420s
09:45:09, +00.0122104s

Значення: Клієнт приблизно на ~12ms випереджає DC01. Для більшості корпоративних потреб це нормально.

Рішення: Якщо бачите зсуви в секундах — ви в зоні ризику для Kerberos. Якщо зразки сильно змінюються між опитуваннями — підозрюйте джиттер мережі, нестабільне верхнє джерело або ефекти пауз/відновлення ВМ.

Завдання 5: Підтвердити, що служба Windows Time запущена

cr0x@server:~$ sc query w32time
SERVICE_NAME: w32time
        TYPE               : 20  WIN32_SHARE_PROCESS
        STATE              : 4  RUNNING
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

Значення: Служба працює.

Рішення: Якщо вона STOPPED або нестійка — виправте це спочатку (політика, залежності або корупція). Немає служби — немає синхронізації.

Завдання 6: Переглянути події служби часу (швидкий фільтр)

cr0x@server:~$ wevtutil qe System /q:"*[System[Provider[@Name='Microsoft-Windows-Time-Service']]]" /c:5 /rd:true /f:text
Event[0]:
  Provider Name: Microsoft-Windows-Time-Service
  Event ID: 35
  Level: Error
  Description: The time service has not synchronized the system time for 86400 seconds because no time data was available.

Значення: w32time не отримує придатних зразків. Може бути заблокований NTP, неправильне джерело, проблеми з DNS або верхнє джерело померло.

Рішення: Перевірте мережевий шлях до джерела, потім саме джерело. Не налаштовуйте інтервали опитування, поки верхнє джерело не стане здоровим.

Завдання 7: Перевірити роль контролера домену (PDC емулатор)

cr0x@server:~$ netdom query fsmo
Schema master               DC01.corp.local
Domain naming master        DC01.corp.local
PDC                         DC02.corp.local
RID pool manager            DC01.corp.local
Infrastructure master       DC01.corp.local
The command completed successfully.

Значення: DC02 — PDC емулатор для домену (фактично корінь авторитету часу для доменної ієрархії).

Рішення: Зосередьте зовнішню NTP-конфігурацію й моніторинг на DC02. Якщо ви налаштували піри на неправильному DC, отримаєте непослідовний авторитет часу.

Завдання 8: Перевірити, який DC використовує клієнт (і чи це нормально)

cr0x@server:~$ nltest /dsgetdc:corp.local
           DC: \\DC03.corp.local
      Address: \\192.168.50.23
     Dom Guid: 9e2b7a9d-1a5b-4c42-9f1a-0d1c7e6c1a11
     Dom Name: corp.local
  Forest Name: corp.local
 Dc Site Name: BRANCH-01
Our Site Name: BRANCH-01
The command completed successfully.

Значення: Клієнт використовує локальний DC сайту (добре). Якщо він обирає віддалений DC, латентність/джиттер і брандмауер можуть погіршити стабільність часу.

Рішення: Якщо обрано віддалений DC — перевірте конфігурацію AD Sites/Subnets. Проблеми з часом іноді починаються як «топологія сайту бреше».

Завдання 9: Перевірити підключення UDP/123 до NTP-сервера (базовий тест)

cr0x@server:~$ w32tm /stripchart /computer:time.company.local /samples:3 /dataonly
09:47:01, +00.0000000s
09:47:03, +00.0000000s
09:47:05, +00.0000000s

Значення: Отримано відповіді. Якщо команда зависає або викидає помилку — UDP/123 може бути заблокований або розв’язування імен зламане.

Рішення: Якщо заблоковано — виправте правила брандмауера між правильними шарами ієрархії, а не з кожної кінцевої точки в інтернет.

Завдання 10: Налаштувати PDC емулатор використовувати ручні піри (правильне місце)

cr0x@server:~$ w32tm /config /manualpeerlist:"time1.company.local,0x8 time2.company.local,0x8" /syncfromflags:manual /reliable:yes /update
The command completed successfully.

Значення: Ви задали явні піри, сказали Windows використовувати їх і позначили хост як надійний для інших.

Рішення: Робіть це на PDC емулаторі (зазвичай корінь лісу). Не робіть цього на випадкових DC і тим більше не на клієнтах.

Завдання 11: Повернути членів домену в режим ієрархії домену

cr0x@server:~$ w32tm /config /syncfromflags:domhier /update
The command completed successfully.

Значення: Клієнт буде слідувати ієрархії часу AD.

Рішення: Якщо ваше середовище приєднане до домену, це стандарт, який ви хочете, якщо немає чіткої виправданої виняткової причини.

Завдання 12: Перезапустити службу часу і примусити повторне виявлення (коли змінено конфіг)

cr0x@server:~$ net stop w32time
The Windows Time service was stopped successfully.
cr0x@server:~$ net start w32time
The Windows Time service was started successfully.
cr0x@server:~$ w32tm /resync /rediscover
Sending resync command to local computer...
The command completed successfully.

Значення: Ви застосували зміни конфігурації і примусили повторне виявлення джерел.

Рішення: Використовуйте це після зміни Type, пір або налаштувань GPO. Якщо все одно не синхронізується — проблема вгорі або в мережевій доступності.

Завдання 13: Підтвердити, що служба часу знає про свої піри

cr0x@server:~$ w32tm /query /peers
#Peers: 2

Peer: time1.company.local,0x8
State: Active
Time Remaining: 734s
Mode: 3 (Client)
Stratum: 2

Peer: time2.company.local,0x8
State: Active
Time Remaining: 734s
Mode: 3 (Client)
Stratum: 2

Значення: PDC бачить два піри і вони активні. Добре.

Рішення: Якщо піри в стані «Pending» або «Unknown» — вирішіть питання DNS, брандмауера або здоров’я верхнього NTP-сервісу.

Завдання 14: Перевірити функції синхронізації часу віртуалізації, що можуть стрибати годинник (приклад Hyper-V)

cr0x@server:~$ powershell -NoProfile -Command "Get-VMIntegrationService -VMName 'APP01' | Where-Object {$_.Name -eq 'Time Synchronization'} | Format-List Name,Enabled"
Name    : Time Synchronization
Enabled : True

Значення: Синхронізація часу Hyper-V увімкнена для ВМ APP01. Це може бути нормально або прихованою причиною стрибків годинника.

Рішення: Для доменно приєднаних серверів Windows розгляньте вимкнення цієї інтеграційної служби і дозвольте w32time робити свою роботу — особливо на DC. Робіть це свідомо, через зміну і перевіряйте поведінку після робіт на хості.

Завдання 15: Виявити великі стрибки часу через журнали подій (полювання на симптоми)

cr0x@server:~$ wevtutil qe System /q:"*[System[(EventID=1 or EventID=37) and Provider[@Name='Microsoft-Windows-Time-Service']]]" /c:10 /rd:true /f:text
Event[0]:
  Provider Name: Microsoft-Windows-Time-Service
  Event ID: 37
  Level: Warning
  Description: The time provider NtpClient is configured to acquire time from one or more time sources, however none of the sources are currently accessible.

Значення: Це часто корелює з початком дрейфу: клієнт не може дістатися своїх джерел і починає працювати у вільному режимі.

Рішення: Якщо бачите це в час початку інциденту — спочатку виправте доступність. Якщо це збігається з вікнами техпідтримки хостів — підозрівайте зміни брандмауера або маршрутизації.

Три корпоративні міні-історії з практики

1) Інцидент через неправильне припущення: «NTP як DNS; вкажіть всім один сервер»

Велике підприємство розгорнуло GPO «закріплення часу». Намір був хороший: уніфікувати час, полегшити аудити, зменшити дрейф. Припущення теж було поширеним: «Якщо кожна кінцева точка вказує на центральний NTP-хост, у нас буде одне джерело істини».

Політику застосували широко: до клієнтів, серверів-членів і навіть деяких контролерів домену. Вночі служба підтримки почала бачити помилки автентифікації. Не всі одразу. Гірше було у філіях, і проблеми з’являлися хвилями. Користувачі VPN постраждали найбільше, бо їхній маршрут до обраного NTP-хоста був… складним.

Помилки Kerberos виглядали як проблеми з паролем користувача. Команди додатків ганялися за простроченими сертифікатами. Команда логування звинувачувала SIEM, що «втратив події», бо часові мітки були непослідовні. Кожен звинувачував когось іншого — показник справжнього інциденту.

Справжній режим відмови: члени домену більше не слідували ієрархії домену. Дехто міг дістатися центрального NTP-сервера, інші не могли. Коли не могли — вони працювали у вільному режимі. Тим часом вони все одно автентифікувалися проти DC із часом, походження якого відрізнялося. Розділення часу, в масштабі.

Виправлення було нудним: повернути клієнтів і сервери-члени до NT5DS, конфігурувати зовнішні піри лише на PDC емулаторі і забезпечити чисту доступність у філіях до верхнього рівня в домені. Інцидент закінчився не героїчною командою, а тихим відкатом і уроком: ієрархія домену — не опціональна архітектура; це частина моделі безпеки.

2) Оптимізація, що повернулась бумерангом: «Опитувати кожні 64 секунди, щоб дрейф не відбувався»

Команда, що дбала про продуктивність, помітила, що деякі Windows-сервери дрейфують на кількасот мілісекунд протягом тривалого часу. Їм це не сподобалося. Хтось знайшов реєстрові налаштування інтервалу опитування, витлумачив їх як «швидше — краще» і жорстко застосував агресивне опитування до флоту серверів додатків через CM.

Спочатку панелі виглядали чудово: частіші оновлення, менші короткострокові зсуви. Потім верхні часоисточники почали вести себе «ненадійно». Клієнти почали логувати попередження про недоступні джерела або ненадійні дані. Деякі верхні пристрої почали лімітувати відповіді NTP. Внутрішні брандмауери помітили трафік як підозрілий, бо він нагадував низькоякісний UDP-шум.

Тепер середовище отримало нову проблему: під час незначного мережевого турбуленту клієнти швидко вирішували, що джерела погані, і переходили у вільний режим або перемикалися між джерелами занадто часто. Замість стабільного повільного дрейфу вони отримали осциляцію. Деякі сервери в кінці-кінців стрибали час при остаточній синхронізації — саме те, чого не хочуть у транзакційних системах.

Виправлення — не «збільшити опитування ще більше». Повернули розумні значення за замовчуванням, додали надійні внутрішні джерела і моніторинг зсуву замість намагання «прибити» час ідеально. Урок: якщо ви гнатися за точністю без розуміння зворотного зв’язку, можна створити технічно «активніший», але операційно гірший годинник.

3) Нудна, але правильна практика, що врятувала день: «Працюйте з PDC емулатором як з критичною інфраструктурою»

Інша організація мала звичку, яка не отримувала оплесків: вони моніторили ланцюг часу домену так само, як DNS. PDC емулатор мав явні піри, резервні верхні джерела і алерти на «час з останньої синхронізації» і пороги зсуву. Також у них було правило: DC не отримують час від гіпервайзера стрибком.

Під час обслуговування дата-центру вони мігрували кластер ВМ між хостами. Декілька серверів додатків побачили попередження про стрибки часу. Операційна команда помітила це відразу, бо події служби часу вже були на їхній радарній панелі. Більший ризик — DC; якщо час DC пішов би вбік, все б пішло під укіс.

Вони перевірили PDC емулатор першим. Він був стабільний і синхронізований. Перевірили кілька не-PDC DC; теж стабільні. Це означало, що хребет доменного часу був цілий. Далі перевірили кілька уражених додатків ВМ і виявили, що інтеграційна синхронізація часу гіпервайзера була знову увімкнена оновленням шаблону.

Відновлення було точковим: вимкнути інтеграційну синхронізацію часу на доменно приєднаних Windows-серверах, виконати resync і продовжити. Ніякої масової реконфігурації, ніякої паніки GPO, ніякого «всі вказати pool.ntp.org». Обслуговування завершилося акуратно, з приміткою у тікеті, і інцидент, який не стався, лишився таким.

Жарт №2: Нічого так не робить раду змін більш духовною, як виявлення, що «сам час» не відповідає вимогам.

Типові помилки: симптом → корінна причина → виправлення

1) Симптом: помилки Kerberos, переривчасті входи, «KRB_AP_ERR_SKEW»

Корінна причина: Час клієнта відрізняється від DC більше, ніж допускається; часто через те, що клієнти використовують ручні NTP-піри, а DC слідують ієрархії домену.

Виправлення: На клієнтах/сервер-учасниках встановіть /syncfromflags:domhier і видаліть ручні піри; перевірте ланцюг часу DC і верхні джерела PDC.

2) Симптом: час нормальний після перезавантаження, але дрейфує через години/дні

Корінна причина: w32time не синхронізується (UDP/123 заблоковано для вибраного джерела або джерело недоступне), тому годинник працює у вільному режимі, поки дрейф не стане помітним.

Виправлення: Використовуйте w32tm /query /status і журнали Time-Service, щоб підтвердити останню синхронізацію; виправте доступність і DNS; потім resync.

3) Симптом: раптові стрибки часу, особливо після міграції ВМ або відновлення зі знімка

Корінна причина: Гіпервайзер або інструменти гостьової ОС коригують час стрибком, тоді як w32time також працює.

Виправлення: Вимкніть гостьову синхронізацію часу для доменно приєднаних Windows-серверів (особливо DC), або налаштуйте її так, щоб уникати стрибків; потім перевірте за допомогою stripchart і журналів подій.

4) Симптом: тільки один сайт/філія має проблеми з дрейфом

Корінна причина: Топологія сайту або правила брандмауера змушують клієнтів синхронізуватися з віддаленими DC; або локальний DC не може дістатися PDC/верхніх джерел.

Виправлення: Підтвердьте вибір DC за допомогою nltest; виправте AD Sites/Subnets; переконайтеся, що DC сайту можуть синхронізуватися вгору; уникайте прямого інтернет-NTP з філій.

5) Симптом: «The time provider NtpClient is configured… none of the sources are accessible»

Корінна причина: Визначені ручні піри недоступні; іноді через виведений з експлуатації NTP-хост або застарілий DNS.

Виправлення: Видаліть мертві піри; використовуйте принаймні два надійні джерела на PDC; перевірте розв’язування і маршрут UDP/123.

6) Симптом: зсув часу осцилює (надто агресивне коригування)

Корінна причина: Надто агресивне опитування/налаштування або нестабільний upstream; іноді обидва разом.

Виправлення: Поверніть розумні інтервали опитування; стабілізуйте верхні джерела; вимірюйте зсув і джиттер замість намагання «забити» час ідеально.

7) Симптом: контролери домену не погоджуються щодо часу

Корінна причина: Більше ніж один DC позначено як «надійне джерело часу» або кілька DC вручну вказані на різні зовнішні піри.

Виправлення: Зробіть PDC емулатор надійним джерелом; налаштуйте зовнішні піри лише там; інші DC нехай слідують ієрархії домену.

8) Симптом: автономний сервер не тримає синхронізацію навіть з ручними пірами

Корінна причина: Нестабільність апаратного годинника, особливості енергозбереження або поведінка ВМ при паузі/сні; NTP не може дисциплінувати годинник, який постійно стрибками змінюють.

Виправлення: Вимкніть конкуренцію синхронізації часу, уникайте відновлення зі знімків без стратегії корекції часу і моніторьте стрибки; розгляньте конфігурацію на рівні хоста, якщо це ВМ.

Контрольні списки / покроковий план

Контрольний список A: Виправити дрейф на одному члені домену без шкоди домену

1. Запустіть w32tm /query /status і зафіксуйте Source, Last Successful Sync Time і Poll Interval.
2. Запустіть w32tm /query /configuration і підтвердьте, що Type — NT5DS (переважно для членів домену).
3. Якщо Type: NTP на члені домену, поверніть його:

   cr0x@server:~$ w32tm /config /syncfromflags:domhier /update
   The command completed successfully.
   

4. Перезапустіть службу часу і примусьте повторне виявлення:

   cr0x@server:~$ net stop w32time
   The Windows Time service was stopped successfully.
   cr0x@server:~$ net start w32time
   The Windows Time service was started successfully.
   cr0x@server:~$ w32tm /resync /rediscover
   Sending resync command to local computer...
   The command completed successfully.
   

5. Перевірте зсув щодо вибраного DC за допомогою stripchart. Якщо зсув у секундах — ескалюйте до перевірки ланцюга DC.
6. Перевірте, чи увімкнена синхронізація часу віртуалізації. Якщо машина приєднана до домену і бачить стрибки після операцій хоста — вимкніть цю опцію (відповідно до стандартів платформи).
7. Спостерігайте журнали Time-Service протягом наступної години. Шукайте попередження «джерело недоступне» і повторні корекції.

Контрольний список B: Виправити скелет часу домену (правильний корпоративний підхід)

1. Визначте PDC емулатор:

   cr0x@server:~$ netdom query fsmo
   Schema master               DC01.corp.local
   Domain naming master        DC01.corp.local
   PDC                         DC02.corp.local
   RID pool manager            DC01.corp.local
   Infrastructure master       DC01.corp.local
   The command completed successfully.
   

2. На PDC емулаторі перевірте поточне джерело і піри за допомогою w32tm /query /status та /query /peers.
3. Налаштуйте принаймні два ручні піри на PDC і позначте його як надійний:

   cr0x@server:~$ w32tm /config /manualpeerlist:"time1.company.local,0x8 time2.company.local,0x8" /syncfromflags:manual /reliable:yes /update
   The command completed successfully.
   

4. Перезапустіть w32time і виконайте resync/rediscover на PDC.
5. На інших DC переконайтеся, що вони не встановлені як надійні і використовують ієрархію домену.
6. На клієнтах/сервер-учасниках приберіть будь-які GPO, що примусово встановлюють ручні піри (якщо машина не є навмисно автономною).
7. Перевірте в кожному сайті, що клієнти обирають локальні DC (nltest) і що ці DC можуть синхронізуватися вгору.
8. Моніторьте: сповіщення за «час з останньої успішної синхронізації» і пороги зсуву для PDC та представницьких DC по сайтах.

Контрольний список C: Правила для віртуалізації (щоб зупинити стрибки часу)

1. Для контролерів домену: вимкніть стрибкоподібну синхронізацію часу з гіпервайзера. DC повинні дисциплінуватися ланцюгом домену, а не хостом, який може бути не точним по секундах під час обслуговування.
2. Для доменно приєднаних серверів: серйозно розгляньте вимкнення синхронізації часу гіпервайзера, якщо немає документо-виправданої причини її залишати увімкненою.
3. Для автономних пристроїв і ізольованих ВМ: синхронізація часу гіпервайзера може бути прийнятна, але оберіть один метод і дотримуйтеся його.
4. Після будь-якої зміни шаблону перевіряйте, що налаштування не відкотилися (це поширене джерело регресій).

Питання та відповіді

1) Чому час Windows дрейфує навіть при налаштованому NTP?

Бо «налаштовано» ≠ «ефективно». Машина може не мати доступу до джерела, використовувати неправильне джерело або гіпервайзер/інструмент може стрибкоподібно коригувати час за спиною w32time.

2) Чи повинна кожна Windows-машина вказувати на той самий NTP-сервер?

Ні, не в домені. Члени домену повинні слідувати ієрархії домену. Зовнішні піри налаштовуйте на PDC емулаторі (і тільки там як стандартну практику).

3) Яка одна річ, яку люди забувають і що приносить найбільше болю?

Конкурентні джерела часу. Гостьова синхронізація ВМ, що робить стрибки, плюс w32time, що намагається дисциплінувати — рецепт хаосу дрейфу та стрибків.

4) Чи можна просто вимкнути w32time і покластися на гіпервайзер?

Для доменно приєднаних Windows-систем зазвичай це погана ідея. Бажано, щоб служба ОС узгоджувалася з моделлю безпеки домену. Синхронізація гіпервайзера може бути доповненням у деяких випадках, але не заміною.

5) Як зрозуміти, чи проблема в PDC емулаторі?

Якщо багато машин у різних сайтах дрейфують у одному напрямку або DC не погоджуються — перевірте w32tm /query /status і журнали PDC. Якщо PDC не синхронізується надійно, весь домен успадковує невизначеність часу.

6) Який зсув — «занадто великий»?

Для загальних корпоративних операцій десятки мілісекунд — нормальні. Як тільки доходите до секунд — ризикуєте автентифікацією та перевіркою сертифікатів. Для трейдингу/телеметрії/промконтролю вимоги можуть бути набагато жорсткішими.

7) Чому проблеми з часом виглядають як помилки сертифікатів?

TLS-сертифікати мають вік дійсності. Якщо ваш годинник неправильний, дійсний сертифікат може виглядати простроченим або ще не дійсним. Тоді всі звинувачують PKI, а годинник тихо сміється.

8) Чи потрібен доступ до «інтернет-NTP» з кожного сервера?

Зазвичай ні. Чистіше мати кілька внутрішніх джерел часу з контрольованим доступом вгору, а далі розповсюджувати час через ієрархію домену.

9) Якщо я виконую w32tm /resync і воно вдається, чи це означає, що я зробив?

Не обов’язково. Одноразова синхронізація не доводить стабільність. Перевірте Last Successful Sync Time протягом кількох годин, слідкуйте за подіями «джерело недоступне» і за стрибками після подій життєвого циклу ВМ.

10) А що з космічними секундами — вони ще важливі?

Так, бо різні платформи та верхні джерела обробляють їх по-різному. Мета — послідовність в усьому середовищі. Якщо ви «smear», робіть це скрізь; якщо робите стрибок — теж послідовно. Змішана поведінка породжує дивності.

Наступні кроки, які варто зробити цього тижня

• Аудит ієрархії. Визначте PDC емулатор і підтвердьте, що він має стабільні, резервні верхні піри. Усі інші повинні переважно слідувати ієрархії домену.
• Пошук конкурентів синхронізації часу. На платформі віртуалізації перевірте, щоб налаштування гостьових стрибків часу не були увімкнені шаблонами або «корисними» дефолтами. Особлива увага — контролерам домену.
• Приберіть загальні GPO з пірами для членів домену. Якщо ви мусите використовувати GPO, точково сфокусуйте її: налаштування PDC для PDC, а не універсальний список пір.
• Інструментуйте банальні сигнали. Алертуйте за «час з останньої успішної синхронізації» і за значущі пороги зсуву для PDC і кількох представницьких DC по сайтах.
• Відпрацюйте вправу з resync. Переконайтеся, що ваша відповідальна команда знає ключові команди, як їх інтерпретувати і коли ескалувати до мережевої або віртуалізаційної команд.

Якщо зробите ці п’ять речей, більшість звернень «дрейф часу Windows» зникнуть. Не тому, що час перестане бути складним, а тому, що ви перестанете дозволяти трьом різним системам сперечатися, котра година.