Tick Tock, Time to Configure the Clock: Time Settings and Controls in the Modern Environment

When the clock strikes twelve…it’s time to get to work. Hello, and welcome back to this ongoing series discussion about Windows Time. My name is Tim Medina, and today we are going to look at some of the configuration items for Windows Time and put them in context of the modern infrastructure.

First, for those that may need it please have a look at the base articles on the Windows Time. There is a good deal of information to take in and work with there. So let’s look at some of the items of note as it deals with the modern infrastructures. For that I mean both an on prem and IaaS or cloud-based perspective.

So, when we look at the configuration items we generally are dealing with stratum (source) targets and how it propagates in the environment. Working with on-prem systems is pretty tried and true of setting a DC to target a NTP source and then letting the organic domain time flow the time throughout the environment. In the world of 2019 that can mean that all systems are in a ~50ms (or less) time sync making audit transactions and controls more finite than ever before. If we are leveraging the modern homogenous of multiplatform, we can use the base system as the strata propagation source to push time to non-Windows systems. They will treat it as a regular times source and with some configuration changes can keep up with the high accuracy constraints if configured properly.

With all that in hand, we should mention a few things. It is recommended to use one NTP source inside the domain and have the rest of the members set to NT5DS. It is also recommended to ensure your source configuration is properly set. Meaning that the source address should be a URL not an IP and the flag set properly. For the flags, you should keep in mind what each of them do. Looking at the parameters, it is generally directed to use 0x1 for the primary source and then if configured 0x2 for the secondary. The other item of note is the time source type. Generally, in a domain you should see NTP for a single source and NT5DS as all other sources. The use of AllSync can cause issues as it will attempt to build an amalgamation of all configured source the system is configured to use based on response from the source. With this in mind, the use of AllSync is generally discouraged in the modern environment.

On to IaaS and VM configuration notes. There is scarcely an enterprise today that does not have some form of virtualized system. If on prem they generally follow the rules above if inside of a domain. It should be noted that the time correction here can sometimes have an issue and in that event (and only that event) we should look at adjusting the configuration on the hosts and guests to reconfigure the VMNICTimeProvider.

For cloud based IaaS solutions it should be noted that most providers control time via the instance you are building in. This holds true in Azure as the IaaS based systems unless configured otherwise will pull time from the Azure Data Center they are housed in. This is also true for PaaS solutions and other cloud based initiatives.

That about wraps things up for this installment in this three part series. We will going over configuration and a deeper technology dive in our final installment. Hope to see you all there!

Join the conversation

From KB875424 there’s a list of Windows Time Service Flags:
The valid settings for the mode used with the /manualpeerlist switch include the following:
•0x01 – use special poll interval SpecialInterval
•0x02 – UseAsFallbackOnly
•0x04 – send request as SymmetricActive mode
•0x08 – send request as Client mode

Flag 0x08 should be used in preference to 0x1
0x01 and common Special Poll Interval instructions for 1024 seconds waste public server resources.
0x04 is inappropriate to use with public servers. It can cause time sync requests to be rejected. End systems should not be trying to set the time of the public servers. One might use 0x04 among your own group of authoritative NTP servers, e.g. 3 candidate DC’s, one each at different AD sites.
at least 3 and preferably 5 time servers should be specified instead of 1 or 2 to improve the resilience against errant source servers, “false tickers” in NTP terms,
Use 0x08 and let Windows Time Service monitor the quality of the source servers. The interval will float from 2^6 (64) seconds to 2^17 seconds (>36 hrs) . Monitor with w32tm /query /status /verbose

NTP users, especially users of public resources like the ntp pool project or public time servers, have an obligation to be conservative in the resources used. Locking down a system @ 48 times a day when it might be just as stable at every 1.5 days is wasteful, if not abusive.

Anecdotally, I’ve used 0x08 with 5 public pool and isp time servers with time.windows.com as a last resort (0x02) on Server 2003 and later. With other documented Microsoft recommendations, this has kept time mostly within 10ms and always within 50ms of time.is for years at intervals up to the default maxpollinterval of 2^17 seconds.