我觉得这个消息很有趣，起初我以为这是一个来自MS团队过度活跃的程序员的笑话，或者是一个骗局。 然而，这个信息一天又一次出现，每天几次：
NtpClient无法将手动对等设置为时间源，原因是“”上的DNSparsing错误。 NtpClient将在3473457分钟内再次尝试，然后再重新尝试一次。 错误是：请求的名称是有效的，但没有find请求types的数据。 （0x80072AFC）
来源：时间服务
事件ID：134
级别：警告
我怀疑我的时间服务器configuration不正确。 这是真的，我该如何解决？ 但为什么这么奇怪的消息呢？
注意： 我在Technet上报道过 ，在这里你可以find一个解释为什么这个数字太奇怪了（因此，有两个答案也发现这个链接，并在答案中使用它））。
我知道这是一个古老的问题，但我自己的研究在technet上遇到这个post 。
它说长时间延迟的原因是由于事件查看器中的输出错误。 事件查看器将registry中string值“15”的原始数据误解为数字。
您可以findregistryNtpClient \ ResolvePeerBackoffMinutes的值是15，事件日志中的输出是3473457 = 0x00350031，这是Unicodestring“15”的little-endian格式。
– Alex Zhaozx – MSFT CSG
只要添加一些更多的信息，以防其他人在search中遇到这种情况。 有关此事件查看器消息的一些令人不安的事情：
在我的几个工作站上，我也得到了同样的信息（Windows 7，join到了2003年的域名）。
关于项目1-2，我注意到这些消息只有在工作站入睡时才显示出来。 它们在内核电源消息显示1秒后显示计算机由于系统空闲而正在入睡。 同时，一些networking服务也在暂停。 我的理论是，时间服务只是要弄清楚networking已经消失了。 DNS可能在那个时候停止了，因此这个名字。
在此之前，我会在约15分钟前看到Time-Service的事件查看器消息，表示它已成功同步。 所以，这不太可能是一个configuration问题。
在事件查看器中查看消息的上下文。 如果您在电脑关机或关机时看到此消息，则不会出现问题。 如果您在正常运行时看到此消息，则说明您有问题。 在这种情况下做一个w32tm /resync /rediscover并从那里去。
至于项目＃3，事实certificate这是如何打印string的错误。 这是在unicode barfing。 应该打印15分钟。 看这里：
请求的名称是有效的，但没有find请求types的数据。 （0x80072AFC）
按照＃2
关于项目1-2，我注意到这些消息只有在工作站入睡时才显示出来。 它们在内核电源消息显示1秒后显示计算机由于系统空闲而正在入睡。 同时，一些networking服务也在暂停。 我的理论是，时间服务只是要弄清楚networking已经消失了。 DNS可能在那个时候停止了，因此这个名字。
是的，你的时间服务器是错误的configuration。 要么没有上游服务器同步，要么阻塞防火墙中的端口（端口123 UDP）。
为什么这么大的数字？ 该错误消息中已经提供了该解决scheme：“并在此之后再重新尝试两次。” 所以它开始了几秒钟，然后翻倍，翻了一翻…
这些都是有关Microsoft时间服务的文档中描述的。