It’s about time… 4 Tips for using NTP

Ever wondered why your Windows server does not sync its time to a time server? Or other devices will not synchronize to a Windows server? Let me explain how to avoid some pitfalls … without going into all the lengthy details of the 111 page Network Time Protocol (NTP) standard document (RFC5905).


First of all, be sure to select a good server to synchronize to. The Windows default “” is not particularly well suited, because it is too slow to answer the incoming requests from all over the world, and synchronization is unreliable.

  • Better choice: if you do not know a time server nearby, use one of the regional servers in, depending on your region (e.g.


Unfortunately, this does not guarantee successful time synchronization. Would you believe someone telling you it’s 11 a.m. if it is pitch black outside (and you are not in the polar zone)? Similarly,  NTP clients will not blindly adjust their time, but will perform some sanity checks before. E.g. for Windows, if the local time of standalone computers (not within a domain) is off by more than 15 hours compared to the time received via NTP, the local time will not be adjusted at all.

  • Ensure that the date is correct before activating NTP on a Windows non-domain member server. (For Windows domain members, you probably will not need to configure NTP at all, because  they will get their time from the domain controllers.)


If you want to operate a time server of your own, be aware that Windows does only come with a “Simple NTP” implementation. The main limitation compared to full-fledged NTP is that Windows may synchronize to one server only, thereby lacking the error reduction (up to sub-second accuracy) offered by synchronization to multiple servers. Thus, some clients will not sync to Windows out of the box, because they consider the Windows server as being too unreliable. Cisco IOS devices are an example — they only synchronize to clocks with an accuracy of better than 1s, whereas Windows announces its accuracy by default as 10s. Fortunately, if this is sufficient because e.g. you only need a consistent time within your environment and some seconds of absolute deviation are acceptable, the announcement can be changed:

  • To synchronize non-Windows devices with a Windows time server, you may therefore need to set its registry key “HKLMSYSTEMCurrentControlSetServicesW32TimeConfigLocalClockDispersion” from the default value of 10 to 0 (this is the announced clock accuracy in seconds). And of course, ensure that your time server itself has its clock synchronized (in this example scenario, possibly from the local clock without external time source): this can — and will — also be checked by the NTP clients.


Misleading a bit, there is no dedicated flag for the clock synchronization status, but unsynchronized clocks are announced via special values of two different flags within the NTP packets: the leap indicator is set to (binary) “11” (“01″ resp. “10” indicate that one leap second needs to be inserted or removed at the last minute of the current day) and the stratum is set to 16 (which is the highest value defined).

  • Thus, if you see “leap 3″ or “stratum 16″ in a log file, it really means the NTP server’s clock is not synchronized and will therefore not be accepted by the client.


If you need to dig deeper, you will note that useful tools for debugging NTP are nothing fancy — Wireshark (or any other packet sniffer with NTP protocol support) will give you all available information on the packet exchange. If you work with Cisco network devices, their “debug ntp” commands are also very helpful, because they also show internal processing steps. On Linux, you could try “ntpq” to query NTP status, and on Windows, there is the w32tm command. Now it’s your turn … grab these tools and explore!



Frederik Anheuser hat über 20 Jahre Erfahrung als Network und Security Engineer, besonders im Entwickeln und Umsetzen verschiedenster Network Services sowie Remote und Security Solutions für Grosskunden im Enterprise Umfeld.