7

I find the message hilarious and at first I thought it was some joke from an over-active programmer of the MS team, or a hoax. However, the message appears again and again, a couple of times a day:

NtpClient was unable to set a manual peer to use as a time source because of DNS resolution error on ''. NtpClient will try again in 3473457 minutes and double the reattempt interval thereafter. The error was: The requested name is valid, but no data of the requested type was found. (0x80072AFC)

Source: Time Service
Event ID: 134
Level: Warning

I suspect that my time servers are not configured correctly. Is that true and how can I fix it? But why such an odd message?

Note: I reported this on Technet, where you can find an explanation why the number is so odd (and consequently, two answers found that link too and used it in the answers ;) ).

Abel
  • 1,037
  • 8
  • 20
  • 32

4 Answers4

7

I know it's an old question but my own research came across this post on technet.

It says that the reason for the long delay is due to an output bug in the event viewer. Event viewer is misinterpreting the raw data of the string value "15" in the registry as a number.

You could find the value of registry NtpClient\ResolvePeerBackoffMinutes is 15, the output in the event log is 3473457 = 0x00350031, which is little-endian format of the Unicode string "15".

- Alex Zhaozx - MSFT CSG

Community
  • 1
danseagrave
  • 186
  • 1
  • 4
4

Just adding some more info in case someone else comes across this in a search. There are a few disturbing things about this Event Viewer message:

  1. The fact that your client could not do an NTP sync.
  2. The fact that the DNS resolution error was on '', not an actual host name.
  3. The fact that the retry interval is crazy long.

I get the exact same message on several of my workstations as well (Windows 7, joined to a 2003-level Domain).

Regarding items 1-2, what I noticed is those messages only show up as the workstation is falling asleep. They show up 1 second after the Kernel-Power message indicating the computer is falling asleep due to system idle. At the same time, a bunch of network services are pausing as well. My theory is that the time service is just figuring out that the network has gone away. DNS is probably stopped at that point, hence the '' name.

Prior to that I see Event Viewer messages from Time-Service about ~15min before, indicating that it synced successfully. So, it is unlikely to be a configuration issue.

Look at the context of the messages in Event Viewer. If you are seeing this message as the computer falls alseep or shuts down, no biggie. If you are seeing this message during normal runtime, you have a problem. In that case do a w32tm /resync /rediscover and go from there.

As for item #3, it turns out this is a bug in how the string gets printed. It is barfing on the unicode. It should be printing 15 minutes. See here:

http://social.technet.microsoft.com/Forums/windows/en-US/34987a99-3bc6-4a73-b859-6eab6a53cafe/why-is-the-ntpclient-waiting-3473457-minutes-6-years-for-a-new-timesync-and-what-is-so-special?forum=w7itpronetworking

myron-semack
  • 2,593
  • 19
  • 17
0

The requested name is valid, but no data of the requested type was found. (0x80072AFC)

As per #2

Regarding items 1-2, what I noticed is those messages only show up as the workstation is falling asleep. They show up 1 second after the Kernel-Power message indicating the computer is falling asleep due to system idle. At the same time, a bunch of network services are pausing as well. My theory is that the time service is just figuring out that the network has gone away. DNS is probably stopped at that point, hence the '' name.

sysadmin1138
  • 133,124
  • 18
  • 176
  • 300
Murray
  • 9
  • 1
-1

Yes your time server is mis-configured. Either it has no upstream server to synchronize with or you block the port in your firewall (port 123 UDP).

Why such a big number? The solution is already presented in the error message: "and double the reattempt interval thereafter." So it started with a few seconds and then doubled and doubled and doubled...

That's all described in the documentation about Microsoft Time Service.

Abel
  • 1,037
  • 8
  • 20
  • 32
mailq
  • 17,023
  • 2
  • 37
  • 69
  • Someone likely set `ResolvePeerBackoffMaxTimes` to a very high value. – David Schwartz Nov 21 '11 at 20:48
  • The "then doubled and doubled and..."-thought occurred to me too, except that: the frequency of this message is more than daily, the number is not a double of an integer, the last message should have been 1736728.5 minutes ago, which is 3.3 years, which is long before I installed my system...... it just doesn't make sense. – Abel Nov 22 '11 at 08:16