Этот вопрос в основном предназначен для того, чтобы другие люди учились у меня и чтобы удовлетворить мое любопытство, если кто-то знает, почему он делает следующее.
У нас была проблема с нашим DC не вовремя из-за его виртуализации, которая с тех пор исправлена. Но некоторым из наших клиентов и серверов требовалось время обновления. Поэтому я попытался запустить следующие команды от имени администратора w32tm / query / source, чтобы убедиться, что он получает время от нашего контроллера домена, а затем w32tm / resync для синхронизации времени, обе команды не имели ошибок, но время не изменилось.
Я вижу что-то похожее на следующую строку в журналах событий. Системное время изменилось на 2014-09-08T21: 31: 33.328000000Z с 2014-09-08T21: 31: 33.342455400Z.
Поэтому я пробую команду еще несколько раз без изменений и немного поищу в Google, только чтобы вернуться и обнаружить, что у клиента сейчас подходящее время, но ничего нового в журналах событий.
Я попробовал второй клиент с тем же результатом, но я не оставил клиента, а немного покопался в журналах и, по чистой случайности, посмотрел на часы и заметил, что время приближается к реальному времени. Он медленно возвращался в нужное время. Время от времени часы поднимались на 2 секунды, или секунда переходила на следующую цифру, прежде чем прошла целая секунда. Он будет делать это, пока часы не покажут нужное время.
У меня вопрос, почему он это делает? почему бы просто не изменить время на правильное мгновенно, как это делает мой персональный компьютер, когда я синхронизирую время с сервером NTP?
Видимо это намеренно:
Если локальное время клиента меньше, чем на три минуты опережает время на сервере, W32Time будет четверть или половину тактовой частоты на достаточно долгое время, чтобы синхронизировать часы. Если клиент опережает менее чем на 15 секунд, частота сокращается вдвое; в противном случае частота будет равна четверти. Время, в течение которого часы работают с необычной частотой, зависит от размера корректируемого смещения.
http://blogs.msmvps.com/acefekay/2009/09/18/configuring-the-windows-time-service-for-windows-server/
Я не могу найти ссылку, которая явно объясняет, ПОЧЕМУ это так устроено, но я предполагаю, что цель состоит в том, чтобы избежать внезапных скачков в случае, если другие приложения используют внутренние часы для синхронизации операций. Таким образом, если смещение невелико, то используется метод «конвергенции» путем регулировки локальной тактовой частоты. Если разница составляет 3 минуты или больше, то риск сбоя аутентификации Kerberos (разница часов> 5 минут) считается более серьезным, чем риски, связанные с «скачком» локальных часов, поэтому часы просто сбрасываются, а не сходятся.