域控制器 – w32tm / resync无法立即工作

前端之家收集整理的这篇文章主要介绍了域控制器 – w32tm / resync无法立即工作前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
如果有人知道为什么会这样做,这个问题主要是供其他人学习并满足自己的好奇心.

我们的DC因为虚拟化没有合适的时间而出现问题,此后已经修复.但是我们的一些客户和服务器需要更新的时间.所以我尝试运行以下命令作为admin w32tm / query / source以确保它从我们的域控制器获得时间然后w32tm / resync来同步时间,两个命令都没有错误但时间没有改变.

我在事件日志中看到类似于以下行的内容.
系统时间从2014-09-08T21:31:33.342455400Z更改为2014-09-08T21:31:33.328000000Z.

所以我尝试了几次没有任何变化的命令,并在谷歌搜索了一下,只是回来找到客户现在正确的时间,但事件日志中没有新的东西.

我尝试了第二个客户端,结果相同,但我没有离开客户端,但是稍微戳了一下日志并且运气不好,我低头看着时钟,注意到时间越来越接近实时.它正在缓慢地漂移到正确的时间.每隔一段时间,时钟会上升2秒,或者一秒钟会在整整一秒钟之前变为下一个数字.它会在时钟到达正确的时间之前执行此操作.

我的问题是为什么这样做?为什么不把我的个人计算机在将时间同步到NTP服务器时立即将时间更改为正确的时间?

解决方法

显然这是设计的:

If the local clock time of the client is less than three minutes ahead
of the time on the server,W32Time will quarter or halve the clock
frequency for long enough to bring the clocks into sync. If the client
is less that 15 seconds ahead,it will halve the frequency; otherwise,
it will quarter the frequency. The amount of time the clock spends
running at an unusual frequency depends on the size of the offset that
is being corrected

http://blogs.msmvps.com/acefekay/2009/09/18/configuring-the-windows-time-service-for-windows-server/

我找不到一个明确解释为什么设计的参考,但我猜这个目的是为了避免突然跳转,以防其他应用程序使用内部时钟进行时间操作.因此,如果偏移量较低,则通过调整本地时钟速率来使用“收敛”方法.如果差异为3分钟或更长,那么Kerberos身份验证失败的风险(> 5分钟时钟差异)被认为比“跳跃”本地时钟所涉及的风险更严重,因此时钟只是重置而不是收敛

猜你在找的HTML相关文章