w32tm /resync 無法立即工作
這個問題主要是為了讓其他人學習並滿足我自己的好奇心，如果有人知道它為什麼會這樣做。
我們的 DC 由於被虛擬化而沒有正確的時間，因此我們遇到了問題，該問題已得到解決。但是我們的一些客戶端和伺服器需要更新時間。所以我嘗試以管理員 w32tm /query /source 的身份執行以下命令，以確保它從我們的域控制器獲取時間，然後 w32tm /resync 同步時間，這兩個命令都沒有錯誤，但時間沒有改變。
我在事件日誌中看到類似於以下行的內容。系統時間已從 2014-09-08T21:31:33.342455400Z 更改為 2014-09-08T21:31:33.328000000Z。
所以我在沒有任何變化的情況下再嘗試了幾次該命令，然後在 Google 上搜尋了一下，只是回來發現客戶端現在有正確的時間，但事件日誌中沒有任何新內容。
我在第二個客戶端上嘗試了相同的結果，但我沒有離開客戶端，而是在日誌周圍看了一會兒，出於純粹的運氣，我低頭看了看時鐘，發現時間越來越接近實時。它正在慢慢回到正確的時間。時鐘時不時地會上升 2 秒，或者在整整一秒過去之前，一秒會變為下一個數字。它會一直這樣做，直到時鐘到達正確的時間。
我的問題是它為什麼這樣做？當我將時間同步到 NTP 伺服器時，為什麼不像我的個人電腦那樣立即將時間更改為正確的時間？
顯然這是設計使然：
如果客戶端的本地時鐘時間比伺服器上的時間提前不到三分鐘，W32Time 將時鐘頻率四分之一或減半，足夠長的時間以使時鐘同步。如果客戶端提前不到 15 秒，則將頻率減半；否則，它將四分之一頻率。時鐘以異常頻率執行所花費的時間取決於正在糾正的偏移量的大小
http://blogs.msmvps.com/acefekay/2009/09/18/configuring-the-windows-time-service-for-windows-server/
我找不到明確解釋為什麼要這樣設計的參考資料，但我猜這樣做的目的是避免突然跳轉，以防其他應用程序使用內部時鐘來計時操作。因此，如果偏移量較低，則通過調整本地時鐘速率使用“收斂”方法。如果差異為 3 分鐘或更大，則 Kerberos 身份驗證失敗的風險（> 5 分鐘時鐘差異）被認為比“跳躍”本地時鐘所涉及的風險更嚴重，因此時鐘只是重置而不是收斂