%20before%20it%20will%20do%20a%20new%20attempt%20of%20DNS%20resolution%2C%20eventid%20134.png)
Я нахожу это сообщение забавным и сначала я подумал, что это какая-то шутка от слишком активного программиста из команды MS или розыгрыш. Однако сообщение появляется снова и снова, пару раз в день:
NtpClient не смог установить ручной одноранговый узел для использования в качестве источника времени из-за ошибки разрешения DNS на ''. NtpClient повторит попытку через 3473457 минут и удвоит интервал повторных попыток после этого. Ошибка: Запрошенное имя действительно, но данные запрошенного типа не найдены. (0x80072AFC)
Источник: Служба времени
Идентификатор события: 134
Уровень: Предупреждение
Я подозреваю, что мои серверы времени настроены неправильно. Так ли это и как это исправить? Но почему такое странное сообщение?
Примечание:Я сообщил об этом на 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 ;) ).
решение1
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
решение2
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:
- The fact that your client could not do an NTP sync.
- The fact that the DNS resolution error was on '', not an actual host name.
- 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:
решение3
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.
решение4
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.