Server Man
Well-Known Member
- May 17, 2015
- Windows 7
- IE 11
Looking at the Windows Time process and configuration there and back again
As last we met, I am Tim Medina Sr PFE with Microsoft and we are coming to a conclusion of our three-part journey in time. First we took some time to look at the new features and aspects of Windows Time in Windows Server 2019. Then we took a some of the more common configuration items. This moment before we set off on further adventures, is going to draw all the information (past and present) in one nice neat spot for reference and help for those still needing it.
Where do we start? I would say with some of the more informative articles on current Windows Time Service here. From the reading you see what we consider the use and control spaces of Windows Time. This would include 2 important support boundaries. First and foremost, we see that we have the old standard bearer of Kerberos 5 requiring a time accuracy in the ticket issuance and expiration. Next, we see our new 2016 and 2019 items for highly accurate time. This will allow you in the confines of the configuration to each constraint. Meaning that each highly accurate increment needs to be defined and controlled properly to meet the support boundary.
Ok now that we have our playing field set, let’s look at what we touch and how it interacts in an environment.
See the two charts below as reference found here
As you will note the typical system that is providing time will reach out to a higher stratum source and then pull in the information via standard port. From there it displays and services the system itself to keep accuracy based on its configuration. Putting that same system into a domain-based model you can then see that the PDC will be the controlling stratum by organically populating the time for them as the primary source.
As noted in the previous blog and the technical reference, we need to make sure we have the settings properly configured. So, let’s break those down based on the documentation. First, we can still use the W32tm commands here to set stand-alone systems. In the case of a domain based system the encouraged path is to use a GPO. Both translate into registry settings that are found in HKLMSystemCurrentControlSetServicesW32Time. There are some key ones we need to discuss in context that were called out.
First we have the parameters items as seen below.
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeParameters
Version
Windows XP, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, and Windows Server 2008 R2
This entry Indicates which peers to accept synchronization from:
The default value on domain members is NT5DS. The default value on stand-alone clients and servers is NTP.
Key things to remember here is that when you have something set to AllSync, it will pull in all sources to the system and make an amalgamation of the reliable sources to establish a time for the system. This can be problematic when you have 3 sources on a VM or more. This is where we note the proper setting to configure this should be NTP and Nt5DS in most cases.
Our next part is the flags set for the sources seen below.
This entry specifies a space-delimited list of peers from which a computer obtains time stamps, consisting of one or more DNS names or IP addresses per line. Each DNS name or IP address listed must be unique. Computers connected to a domain must synchronize with a more reliable time source, such as the official U.S. time clock.
There is no default value for this registry entry on domain members. The default value on stand-alone clients and servers is time.windows.com,0x1.
We need to take care when making setting changes here as they affect the behavior of the system. The standard use targets are 0x02 and 0x01. The note here would be the use of the 0x08 for only a specific race event. It is discouraged to set an authoritative source (PDCe or main standalone time server) as a client as it will not be properly conform to the requests for an authoritative source (commonly seen as 0x09). As with other items it falls into the if it is not broke, don’t change it.
There is one final note here that deals with the source targets and that has to do with VMNICTimeProvider. If you are in Azure or other cloud environment, it is recommended that those systems continue to use this source as it pulls in time stratum from the data center source. However if you have an on prem virtual it is a good idea to partially disable it to ensure that your VMs follow domain hierarchy.
Let’s put this into a nice time stream shall we? Using the following blogs as context you can configure a WMI filter to follow your PDCe and then build a GPO to set the time information for your domain. Again, if it ain’t broke principle applies here in current Windows server editions as it does in previous. Use of the w32time commands can be used here as well though its control is purely manual and can be mistyped or error because of a command entry error.
So, what is new? Let’s take a look at what Server 2016 and Windows 10 is presenting us in the GPO area as well in the registry of note in the high accuracy area. In the same parameter space and under the GPO settings we can reduce the Polling Intervals (min and max). We also can set the Update Interval as well as the key Special Poll Interval and Frequency Correction rate. With these changes you can then tune down your rate of variance to 1ms. This does require that the GTIMESERV role is enables as well a reliable GPS enabled source clock on your network. The down level (2012 and Windows 8) systems still benefit from this configuration though they cannot participate readily in its implementation.
On 2016 we see a host of new entries and configurable settings that differ from previous versions in configuration in GPOs. In the registry we also see some changes to the previous versions allowing us to take advantage of the parameter and configuration changes in the modern OS.
With the previous mentioned base MSDN articles, some of these settings are not generally altered or controlled to a degree. To be explicit though they can all be found here for reference.
Also just in case things should start to be a bit wibbly wobbly timey wimey on a client or system the debug log settings are still in the same hive entries and can be turned on to provide rich data for troubleshooting.
And there we go, just a quick run around the blogosphere universe in relation to time. As we head into Server 2016 and 2019 universe I can only see bright things for Windows Time. Drop a line if you have questions here on Windows Time, until next time, Fantastic! Allons-y! Geronimo!
Continue reading...
As last we met, I am Tim Medina Sr PFE with Microsoft and we are coming to a conclusion of our three-part journey in time. First we took some time to look at the new features and aspects of Windows Time in Windows Server 2019. Then we took a some of the more common configuration items. This moment before we set off on further adventures, is going to draw all the information (past and present) in one nice neat spot for reference and help for those still needing it.
Where do we start? I would say with some of the more informative articles on current Windows Time Service here. From the reading you see what we consider the use and control spaces of Windows Time. This would include 2 important support boundaries. First and foremost, we see that we have the old standard bearer of Kerberos 5 requiring a time accuracy in the ticket issuance and expiration. Next, we see our new 2016 and 2019 items for highly accurate time. This will allow you in the confines of the configuration to each constraint. Meaning that each highly accurate increment needs to be defined and controlled properly to meet the support boundary.
Ok now that we have our playing field set, let’s look at what we touch and how it interacts in an environment.
See the two charts below as reference found here
As you will note the typical system that is providing time will reach out to a higher stratum source and then pull in the information via standard port. From there it displays and services the system itself to keep accuracy based on its configuration. Putting that same system into a domain-based model you can then see that the PDC will be the controlling stratum by organically populating the time for them as the primary source.
As noted in the previous blog and the technical reference, we need to make sure we have the settings properly configured. So, let’s break those down based on the documentation. First, we can still use the W32tm commands here to set stand-alone systems. In the case of a domain based system the encouraged path is to use a GPO. Both translate into registry settings that are found in HKLMSystemCurrentControlSetServicesW32Time. There are some key ones we need to discuss in context that were called out.
First we have the parameters items as seen below.
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeParameters
Version
Windows XP, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, and Windows Server 2008 R2
This entry Indicates which peers to accept synchronization from:
- NoSync. The time service does not synchronize with other sources.
- NTP. The time service synchronizes from the servers specified in the NtpServer. registry entry.
- NT5DS. The time service synchronizes from the domain hierarchy.
- AllSync. The time service uses all the available synchronization mechanisms.
The default value on domain members is NT5DS. The default value on stand-alone clients and servers is NTP.
Key things to remember here is that when you have something set to AllSync, it will pull in all sources to the system and make an amalgamation of the reliable sources to establish a time for the system. This can be problematic when you have 3 sources on a VM or more. This is where we note the proper setting to configure this should be NTP and Nt5DS in most cases.
Our next part is the flags set for the sources seen below.
This entry specifies a space-delimited list of peers from which a computer obtains time stamps, consisting of one or more DNS names or IP addresses per line. Each DNS name or IP address listed must be unique. Computers connected to a domain must synchronize with a more reliable time source, such as the official U.S. time clock.
- 0x01 SpecialInterval
- 0x02 UseAsFallbackOnly
- 0x04 SymmetricActive
For more information about this mode, see Windows Time Server: 3.3 Modes of Operation (Windows Time Server: 3.3 Modes of Operation).
- 0x08 Client
There is no default value for this registry entry on domain members. The default value on stand-alone clients and servers is time.windows.com,0x1.
We need to take care when making setting changes here as they affect the behavior of the system. The standard use targets are 0x02 and 0x01. The note here would be the use of the 0x08 for only a specific race event. It is discouraged to set an authoritative source (PDCe or main standalone time server) as a client as it will not be properly conform to the requests for an authoritative source (commonly seen as 0x09). As with other items it falls into the if it is not broke, don’t change it.
There is one final note here that deals with the source targets and that has to do with VMNICTimeProvider. If you are in Azure or other cloud environment, it is recommended that those systems continue to use this source as it pulls in time stratum from the data center source. However if you have an on prem virtual it is a good idea to partially disable it to ensure that your VMs follow domain hierarchy.
Let’s put this into a nice time stream shall we? Using the following blogs as context you can configure a WMI filter to follow your PDCe and then build a GPO to set the time information for your domain. Again, if it ain’t broke principle applies here in current Windows server editions as it does in previous. Use of the w32time commands can be used here as well though its control is purely manual and can be mistyped or error because of a command entry error.
So, what is new? Let’s take a look at what Server 2016 and Windows 10 is presenting us in the GPO area as well in the registry of note in the high accuracy area. In the same parameter space and under the GPO settings we can reduce the Polling Intervals (min and max). We also can set the Update Interval as well as the key Special Poll Interval and Frequency Correction rate. With these changes you can then tune down your rate of variance to 1ms. This does require that the GTIMESERV role is enables as well a reliable GPS enabled source clock on your network. The down level (2012 and Windows 8) systems still benefit from this configuration though they cannot participate readily in its implementation.
On 2016 we see a host of new entries and configurable settings that differ from previous versions in configuration in GPOs. In the registry we also see some changes to the previous versions allowing us to take advantage of the parameter and configuration changes in the modern OS.
With the previous mentioned base MSDN articles, some of these settings are not generally altered or controlled to a degree. To be explicit though they can all be found here for reference.
Also just in case things should start to be a bit wibbly wobbly timey wimey on a client or system the debug log settings are still in the same hive entries and can be turned on to provide rich data for troubleshooting.
And there we go, just a quick run around the blogosphere universe in relation to time. As we head into Server 2016 and 2019 universe I can only see bright things for Windows Time. Drop a line if you have questions here on Windows Time, until next time, Fantastic! Allons-y! Geronimo!
Continue reading...