这太奇怪了，我不得不寻求建议。
我有几个工作站从 GPS 时钟接收时间。PDC 的默认域策略设置为使用 GPS 时钟作为 NTP 时间源。所有工作站都与时钟同步，精度范围从 50 毫秒到 1.5 毫秒，因此我的增量值大致在 Kerebos 票证的范围内。
几乎所有工作站都可以毫无问题地访问我的文件服务器，但是有一个工作站开始向我提示消息This server's clock is not synchronized with the primary domain controller's clock，除非w32tm /stripchart /computer:PDC是在撒谎，否则 20 毫秒已经足够接近同步了。
我可能遗漏了什么吗？
答案1
既然我确信问题已经解决，我将回答我自己的问题。
要验证的事项：
从时间源验证调制如果 IRIG 信号经过调制，请确保您的配置正在寻找经过调制的时间信号。如果 IRIG 信号未经调制，请确保您的硬件已配置为未经调制的信号。
验证时间是否正确如果“大师时钟”没有从时钟接收到正确的时间值，那么一切都将不正确。请确保您有正确年份的正确偏移周期。闰秒（截至本文撰写时）应偏移 34 秒。
验证没有强制值，或调试如果有人使用频率发生器来“伪造”时间调试某个过程，那么如果它覆盖了 Stratum 时间，那么什么都不会正确。
验证时间服务如果您的时钟收音机有单独的软件来将系统时间与时间源同步，请确保已禁用 Windows 时间服务。如果您不关闭 Windows 时间服务，则时钟将由两个服务进行校正。
验证时区时间服务器和客户端上的时区设置必须正确。我强烈建议将所有内容设置为 GMT，不带任何夏令时偏差或 UTC，并创建第二个时间显示，显示具有夏令时优先权的本地时区。
验证 DST 是否已修补如果您没有正确实施 DST 运行，您将遇到“幻影”问题。
验证增量是否足够小以进行初始同步如果时间差过大，客户端将无法与时间源同步。您可能需要将时钟设置为大约 10 分钟以内，以便时间服务能够同步。
故障排除：
- 用于
w32tm /tz验证时区。 - 用于
w32tm /stripchart /computer:[host to compare with]测量两台计算机之间的差异和时间漂移。
答案2
我猜是该工作站的 DST 修补问题。上次我遇到这个问题时，我从映像加载了一个工作站，然后应用了 XP SP3。那时我发现我的映像陷入了一种边缘情况，即以这种方式修补时 DST 修补没有发生。如果这是问题所在，希望MS DST 页面将会提供帮助。
答案3
2019 年从夏令时改为标准时间后，我们网络上的多个工作站开始出现此错误。为了修复此问题，我重新启动了两个域控制器中的一个，网络共享又开始正常工作。