NtpClient 將等待 3473457 分鐘（超過 6 年！），然後它才會重新嘗試 DNS 解析，eventid 134
我覺得這條消息很有趣，起初我認為這是 MS 團隊中一個過度活躍的程序員的玩笑，或者是一個惡作劇。但是，該消息一次又一次地出現，一天幾次：
由於“”上的 DNS 解析錯誤，NtpClient 無法設置手動對等方以用作時間源。NtpClient 將在 3473457 分鐘後重試，然後將重試間隔加倍。錯誤是：請求的名稱有效，但未找到請求類型的數據。(0x80072AFC)
來源：時間服務
事件 ID：134
級別：警告
我懷疑我的時間伺服器配置不正確。這是真的嗎？我該如何解決？但為什麼會有這麼奇怪的資訊？
注意：我在 Technet 上報告了這一點，您可以在其中找到為什麼這個數字如此奇怪的解釋（因此，兩個答案也找到了該連結並在答案中使用了它；））。
我知道這是一個老問題，但我自己的研究在 technet 上發現了這篇文章。
它說長時間延遲的原因是由於事件查看器中的輸出錯誤。事件查看器將系統資料庫中字元串值“15”的原始數據誤解為數字。
您可以發現系統資料庫 NtpClient\ResolvePeerBackoffMinutes 的值為 15，事件日誌中的輸出為 3473457 = 0x00350031，這是 Unicode 字元串“15”的小端格式。
- Alex Zhaozx - MSFT CSG
只需添加更多資訊，以防其他人在搜尋中遇到此問題。此事件查看器消息有一些令人不安的事情：
- 您的客戶端無法進行 NTP 同步的事實。
- DNS 解析錯誤出現在 ’’ 上的事實，而不是實際的主機名。
- 重試間隔非常長的事實。
我在幾個工作站上也收到了完全相同的消息（Windows 7，加入了 2003 級域）。
關於項目 1-2，我注意到這些消息僅在工作站入睡時出現。它們在核心電源消息指示電腦由於系統空閒而進入睡眠狀態後 1 秒出現。與此同時，大量的網路服務也在暫停。我的理論是時間服務只是發現網路已經消失了。DNS 可能在此時停止，因此是 ’’ 名稱。
在此之前，我在大約 15 分鐘之前看到來自 Time-Service 的事件查看器消息，表明它已成功同步。因此，這不太可能是配置問題。
在事件查看器中查看消息的上下文。如果您在電腦跌倒或關閉時看到此消息，沒什麼大不了的。如果您在正常執行時看到此消息，則說明您有問題。 在這種情況下，做一個
w32tm /resync /rediscover並從那裡去。至於第 3 項，事實證明這是字元串列印方式的錯誤。它在 unicode 上大喊大叫。它應該列印 15 分鐘。看這裡：