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!
For some extra information on the new Windows Time features for Windows Server 2019, you can also take a look at the product group’s post on this topic over at https://blogs.technet.microsoft.com/networking/2018/07/18/top10-ws2019-hatime/!
Thanks for reading!
Tim Medina