这个问题主要是为了让其他人学习，并满足我自己的好奇心，看看是否有人知道它为什么会发生以下情况。
由于 DC 被虚拟化，我们遇到了时间不正确的问题，这个问题已经解决了。但我们的一些客户端和服务器需要更新时间。因此，我尝试以管理员身份运行以下命令 w32tm /query /source，以确保它从我们的域控制器获取时间，然后运行 w32tm /resync 同步时间，这两个命令都没有错误，但时间没有改变。
我在事件日志中看到类似以下行的内容。系统时间已从 2014-09-08T21:31:33.342455400Z 更改为 2014-09-08T21:31:33.328000000Z。
因此，我又尝试了几次该命令，但没有任何变化，并在 Google 上搜索了一下，结果回来发现客户端现在有正确的时间，但事件日志中没有任何新内容。
我尝试了第二个客户端，结果相同，但我没有离开客户端，而是在日志中搜索了一下，出于纯粹的运气，我低头看了看时钟，发现时间越来越接近真实时间。它正在慢慢回到正确的时间。时钟时不时地会快 2 秒，或者在一秒过去之前，一秒就会变为下一个数字。它会一直这样做，直到时钟到达正确的时间。
我的问题是它为什么会这样做？为什么不像我的个人电脑在将时间同步到 NTP 服务器时那样立即将时间更改为正确的时间？
答案1
显然这是设计使然：
如果客户端的本地时钟时间比服务器上的时间早不到三分钟，W32Time 会将时钟频率减半或四分之一，直到时钟同步。如果客户端的本地时钟时间早不到 15 秒，它会将频率减半；否则，它会将频率减半。时钟以异常频率运行的时间取决于正在校正的偏移量的大小
http://blogs.msmvps.com/acefekay/2009/09/18/configuring-the-windows-time-service-for-windows-server/
我找不到明确解释为何如此设计的参考资料，但我猜想其目的是避免在其他应用程序使用内部时钟计时操作时出现突然跳跃。因此，如果偏移量较低，则通过调整本地时钟速率使用“收敛”方法。如果差异为 3 分钟或更大，则 Kerberos 身份验证失败的风险（>5 分钟时钟差异）被认为比“跳跃”本地时钟所涉及的风险更严重，因此时钟只是重置而不是收敛