w32tm / resyncがすぐに動作しない
この質問は、誰かが以下の理由を知っている場合、他の人々が私から学び、自分の好奇心を満たすためのものです。
DC仮想化されているため、適切な時間がありませんでしたが、それ以降は修正されました。しかし、一部のクライアントとサーバーは更新された時間を必要としました。そのため、次のコマンドをadmin w32tm/query/sourceとして実行し、ドメインコントローラーから時刻を取得してからw32tm/resyncで時刻を同期していることを確認します。どちらのコマンドにもエラーはありませんでしたが、時刻は変更されませんでした。
イベントログに次のような行が表示されます。システム時刻が2014-09-08T21：31：33.342455400Zから2014-09-08T21：31：33.328000000Zに変更されました。
そのため、変更を加えずにコマンドをさらに数回試して、Googleで少し検索します。戻ってクライアントに適切なタイミングがあることを確認するだけで、イベントログには何も新しいものはありません。
同じ結果で別のクライアントを試してみましたが、クライアントを離れることはありませんでしたが、ログを少しつついてみましたが、運が悪かったため、時計を見下ろしてみると、時間がリアルタイムに近づいていることに気付きました。それは、適切なタイミングに戻るのが遅くなっていた。時々、時計が2秒ずつ上がるか、1秒が経過する前に1秒が次の桁に変わります。時計が正しい時間に達するまでこれを行います。
私の質問は、なぜこれを行うのですか？ NTPサーバーに時刻を同期するときに、パーソナルコンピュータが行うように、時刻を即座に正しい時刻に変更しないのはなぜですか？
どうやらこれは仕様によるものです。
クライアントのローカルクロック時刻がサーバーの時刻より3分未満早い場合、W32Timeは、クロックを同期させるのに十分な時間、クロック周波数を4分の1または半分にします。クライアントが15秒未満進んでいる場合、頻度は半分になります。それ以外の場合は、周波数を4分の1にします。クロックが異常な周波数で実行に費やす時間は、修正されるオフセットのサイズによって異なります
http://blogs.msmvps.com/acefekay/2009/09/18/configuring-the-windows-time-service-for-windows-server/
なぜそのように設計されているのかを明確に説明するリファレンスは見つかりませんが、他のアプリケーションが内部クロックを使用して時間操作を行っている場合に突然ジャンプするのを避けることが目的であると思います。したがって、オフセットが低い場合は、ローカルクロックレートを調整して「収束」方法を使用します。差が3分以上の場合、Kerberos認証が失敗するリスク（> 5分のクロック差分）は、ローカルクロックの「ジャンプ」に伴うリスクよりも深刻であると見なされるため、クロックは収束するのではなく、リセットされるだけです。