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 “time.windows.com” is not particularly well suited, because it is too slow to answer the incoming requests from all over the world, and synchronization is unreliable.
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.
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:
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).
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!