Windows Time Service https://docs.microsoft.com/archive/blogs/w32time/feed.xml The official blog site for the Windows Time Service Sat, 06 Apr 2019 02:05:59 GMT en-US hourly 1 Impending GPS Week Number rollover https://docs.microsoft.com/archive/blogs/w32time/impending-gps-week-number-rollover Sat, 06 Apr 2019 02:02:57 GMT https://blogs.msdn.microsoft.com/w32time/?p=275 Disclaimer: Microsoft neither endorses, manufactures nor sells any GPS-enabled time sources or servers. This post is just an FYI, based on information published by GPS/USNO. GPS time sources are widely used in accurate, reliable NTP and PTP time servers and it is my understanding that they are often used to supply time to Microsoft Windows deployments as well. Other operating systems in your environment are likely be affected by time issues arising from this event. Hence this last minute blog post to give a heads up about an impending GPS event that can potentially affect the time in your systems. The "Week Number" field in the GPS messaging is scheduled to rollover in about 22 hours time from when this post is made, just before April 7th, 2019 UTC rolls in. You can read about this event on the dedicated USNO website or on gps.gov homepage. The latter website has a countdown clock to the event for easy visualization. Whether or not the Microsoft Windows machines in your deployment are affected depends on many factors. The most important factor is the GPS time source you are using and whether it handles the week rollover correctly. Subsequent factors include your time distribution topology and W32time service configuration on the individual Windows machines. Please refer to documentation from your GPS time source supplier about how the equipment will fare during this rollover. The default W32time service settings should prevent it from accepting very large time corrections from upstream sources. How your Windows machine(s) is/are affected depends on your specific settings. In any case, I would suggest to keep an eye out for unusual time issues when the rollover occurs tomorrow. (And be cautious using your GPS for navigation tomorrow, may be?)]]> Windows Time Sync Accuracy Adendum is Available https://docs.microsoft.com/archive/blogs/w32time/windows-time-sync-accuracy-adendum-is-available Fri, 16 Dec 2016 21:20:44 GMT https://blogs.msdn.microsoft.com/w32time/?p=256 published a new document which contains more details about our testing and measurement methodologies for high accuracy time synchronization.  This technical document describes how samples are normalized and presents the data across all the machines we tested.  Using this information, you should be able to duplicate the tests in your own environment as well as corroborate our results.  So if you have some spare hours this weekend, and are really interested in the nitty gritty detail, give it a read.]]> Windows Server 2016 Time Accuracy Improvements Video https://docs.microsoft.com/archive/blogs/w32time/windows-server-2016-time-accuracy-improvements-video Tue, 04 Oct 2016 17:17:38 GMT https://blogs.msdn.microsoft.com/w32time/?p=255 We’ve posted a short video on Channel9 which provides a high-level discussion of the improvements to time accuracy with Windows Server 2016, as well as some simple guidance on what is required in order to achieve the highest accuracy in your environment.   Of course the TechNet article has much more detail, but this should help you come up to speed quickly.  Enjoy! The short link is: https://aka.ms/WS2016TimeVideo]]> Windows Server 2016 Improvements in Time Accuracy https://docs.microsoft.com/archive/blogs/w32time/windows-server-2016-improvements-in-time-accuracy Fri, 30 Sep 2016 15:33:24 GMT https://blogs.msdn.microsoft.com/w32time/?p=245 In 2017, governments are requiring stricter time accuracy with regards to UTC for financial transactions.   We have improved the time accuracy in Window Server 2016 and under the right conditions, UTC time accurate to within ±1 millisecond, can be distributed throughout your domain.  Additionally, these improvements extend to Hyper-V where the same accuracy can be delivered to Windows Server 2016 and Windows 10 Anniversary guests. For all the details about these changes, measurements and best practices, please visit our TechNet article at https://aka.ms/WS2016Time.  Accurate time is becoming increasingly more important not only for financial scenarios, but healthcare, IT, manufacturing, retail, and many other transaction based activities.  Provided you have a suitable environment, Windows Server can now support these types of workloads by distributing time accurate to within ±1 millisecond in your domain. ]]> Secure Time Seeding – improving time keeping in Windows https://docs.microsoft.com/archive/blogs/w32time/secure-time-seeding-improving-time-keeping-in-windows Wed, 28 Sep 2016 19:09:17 GMT https://blogs.msdn.microsoft.com/w32time/?p=225

What year is it?

(https://i1.kym-cdn.com/entries/icons/original/000/007/784/what-year-is-it-robin-williams.jpg AKA Robin Williams' Jumanji meme) Most network security protocols rely on the use of keys that expire after a certain amount of time. This appears to be a plain vanilla statement until you think a bit about it. Timekeeping over long periods of time is critical for tracking the lifetime and expiry of security keys. We innately understand the passage of time and take it for granted that our computers and devices will automatically do this for us with reasonable accuracy, at least to the extent required for key rollover. Computers must keep track of time when they are running and even when they are turned off. The latter functionality is the only way to know what time it is when they are turned back on again. By extension this is also the only way they know which keys are valid and which are not. PCs and big form-factor hardware have a dedicated battery to power their system clock. We barely notice anything is amiss when we power-cycle these machines. Miniaturization of consumer devices has led to the elimination of this on-board dedicated (CMOS) battery, whose function is now delegated to the main device battery. The device batteries do this job as expected most of the time. One of the annoying things about device batteries is that they run out of power (often when we seem to need them the most). As the device battery depletes and then drains completely, the time keeping function it supports also stops. The devices powered up from this state typically start up with their clock set to a random time value. This presents a little problem to the device in keeping track of the validity of its keys, some of which are used in secure networking – i.e. the device cannot connect securely to the outside world without an intervention to correct its clock. You may ask – why doesn’t the device ask the nearest time server for the current time over the network? Since the device is not in a state to communicate securely over the network, it cannot obtain time securely over the network as well, unless you choose to ignore network security or at least punch some holes into it by making exceptions. To summarize the issue, grossly incorrect system time can cause network security to be impaired, which in turn prevents obtaining the current time securely over the network. This is a classic circular dependency. You may have experienced this problem on your tablet or mobile device in the form of connectivity issues to secure services. Increasing use of sleeker/smaller devices means this issue is bound to occur widely, impacting the users of these devices. Devices with aging batteries will start to experience this problem more often, contributing to the frequency of occurrence of this issue. It could also occur on larger hardware like PCs when their on-board battery drains completely (a rare event, but a certain event nonetheless). Asking the users to check their system time when they cannot get their emails or when they cannot sign on to their websites or when they cannot sign into their AD domains will get old really fast. We had to address and solve this problem at a system level.

Solutions to this problem

Hosting a custom "Secure" Time Service:

A possible solution would involve the client obtaining the current time from a server over a protocol like SSL, ignoring errors in time-related protocol validations on the client. Any exceptions to the security validations requires thorough scrutiny since we are opening the client to potential attacks, which in part makes this an unfavorable solution. Additionally, we have to maintain a server available at all times and the clients may or may not be able to reach said server from the network they are on – additional challenges that reduce the effectiveness of this solution.

Secure Time Seeding - a client-side solution:

We started looking for solutions that would not require us to make security exceptions and SSL protocol contained data that we could use. We decided to stick to the principle of trusting only the data from SSL connections that can be established based on the certificates installed on the client, without treating specific certificates differently – i.e. a mechanism that is not very different from the one we had before. SSL protocol allows a client to securely participate in a handshake with a server and perform time-related validation towards the end of the handshake (e.g.: certificate validity using the local system clock). Essentially a client can trust the certificates installed locally to perform the SSL handshake, but it may not trust the server enough to establish the connection because its local system time indicates the server’s certificate chain is invalid. The SSL handshake contains encrypted/signed time metadata from the server that can be used by the client to determine the current time. This secure metadata helped us to break the cyclical dependency between client system time and security keys including SSL certificates. We use the following two pieces of metadata from the SSL handshake:
  1. ServerUnixTime, an informational field.
  2. OCSP validity period, which is part of the cryptographically signed data obtained from optional stapled OCSP packet that has been tacked on to the SSL certificate chain presented by the server to the client.
The ServerUnixTime is supposed to be the current system time on the server, but it can also be set to a random value by some SSL implementations. We have observed that most servers provide a fairly accurate value in this field and the rest provide random values. We use this data field assuming it is somewhat accurate but can also be incorrect. Stapled OCSP packets provide a very reliable time range, but it has low adoption on the internet and the time range can be as long as a week, making it not very suitable for use by the system clock. However, in cases where the system clock is off by weeks/months/years, setting the system clock to within a week’s accuracy is certainly a huge improvement. This OCSP time range data can be used by itself or combined with the ServerUnixTime to improve the accuracy of the time range. We took the approach to not trust the data from a lone server, irrespective of who the server identifies itself as. We rely on corroborating information from multiple servers to arrive at a common truth about the current time. The SSL connections made from the client are randomly interspersed in time and the metadata they provide follows suit as well. Our algorithms corroborate the data and determine reliable range for the current time. The information from ServerUnixTime and OCSP validity periods are merged to produce the smallest possible reliable time range value along with a confidence score. When the confidence score is sufficiently high, this data becomes information.  We are calling this as Secure Time Seed of High Confidence (STSHC). STSHC is actionable information and it is used to correct grossly incorrect system clocks (i.e. seed them with a good value). After this occurs, a more accurate time synchronization is expected to be carried out using NTP (secured or unsecured) to bring the system clock close to the current time. In fact, both clock correction functions are performed by the Windows Time Service (W32Time). A grossly incorrect system clock may cause the initial few SSL connections to fail, but the calling client applications tend to retry the calls after a short time. STSHC may have been established and the system clock corrected when the retry occurs and the retried SSL calls would likely succeed. This provides a very seamless experience for the end users, instead of them having to diagnose errors originating from SSL certificate validation failures due to incorrect system time. This is a big win for the overall user experience with SSL. STSHC is also used to monitor the system clock for gross errors and correct those at the next chance. This adds another obstacle to tampering the system clock or even flaky clock hardware to some extent.

Does this work?

The Secure Time Seeding feature was shipped in the Windows 10 November 2015 release and is turned on by default. You may have seen the improvements in timekeeping on your Windows tablets and other Windows devices running this version of the OS. We have seen it work time and again given the prerequisites are met.

I want to see this in action

This feature requires W32time Service to be enabled (“Set Time Automatically” Date-Time UI setting enabled), internet connectivity and outgoing SSL traffic from your machine or device to function. Assuming you have the above prerequisites met, you can watch this feature in action by moving your system clock forward or backward by a week or longer and watch it get corrected after a short duration.

I trust my hardware clock and time synchronization mechanisms. I don't want this!

If you would rather trust your system clock than time data generated from your SSL traffic and want to forgo any benefit this feature gives you, we got your back. Set the following registry value to 0 and reboot your machine and the Secure Time Seeding feature will be disabled. (Standard warning about exercising care while modifying registry applies here). Registry Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config Value Name: UtilizeSslTimeData Value Type: REG_DWORD

I changed my mind and want the feature back on.

Just set the above registry value to 1 and reboot your machine. Please remember that W32time service must also be enabled (“Set Time Automatically” setting in the Date-Time UI). (Standard warning about exercising care while modifying registry applies here as well).

Feature Availability

This feature was first introduced in Windows 10 Client November release (November 2015 release). It is available in both Windows Server 2016 and Windows 10 Client Anniversary releases. The feature is turned on by default in all these versions of the OS.

Known Issues

We have a known issue related to this feature in the Windows 10 Client November Release. Refer to KB article 3160312 for more details.  This issue has been fixed in the Windows 10 Anniversary Release.
]]> Moving Day https://docs.microsoft.com/archive/blogs/w32time/moving-day Wed, 16 Nov 2011 15:43:00 GMT https://blogs.msdn.microsoft.com/w32time/2011/11/16/moving-day/ How the time flies.

With over 2 years since the last post, it is high time we get this blog moving again. Looking at the traffic statistics, there were nearly 50k views of the NET TIME and w32time post, so it is evident that folks are still interested in this content. However, since I am no longer a developer for the Windows Time Service, I wont be posting to this blog. Instead, I have a now blog that is just a click away: https://blogs.msdn.com/ryansize

On the new blog, I will still talk about the Windows Time Service, as well as a few other interesting topics. The first few posts will be dedicated to the Active Directory Management Pack, but take heart; I have a few ideas already lined up for the Windows Time Service.

With that, I would recommend jumping to (and bookmarking) my new blog. Let the posting begin!

 

]]> NET TIME and w32time https://docs.microsoft.com/archive/blogs/w32time/net-time-and-w32time Fri, 07 Aug 2009 12:10:00 GMT https://blogs.msdn.microsoft.com/w32time/2009/08/07/net-time-and-w32time/ It seems there is a bit of ambiguity out there regarding the relationship between w32time and the NET TIME command. Well, here are the answers, straight from the horse's mouth.

Taking it from the top 

As all of you know (or at least should) know by now, w32time is the Windows Time Service, which is an independent service that runs on nearly all Windows computers from Windows 2000 onward. It is comprised of the time service (aka w32time) and the w32tm.exe user-mode application for management and troubleshooting. The service communicates on port 123 via UDP for time synchronization using the NTP protocol. Communication between w32tm.exe and the time service uses a custom RPC interface.

In contrast, NET TIME (or more appropriately, the net.exe application) is a user-mode tool for verifying the time on a remote computer using a totally separate mechanism. The net.exe application lives in the System32 directory and is a jack-of-all-trades tool for changing various configuration elements of the operating system. 

How the NET TIME command works 

The net.exe application has been around for a long time, perhaps even pre-Windows 2000. All of the functionality in the net.exe application revolves around the Net* functions exposed in the NetApi32.dll library. This includes a number of really powerful functions such as NetUserAdd, NetUserChangePassword, NetJoinDomain, and other such functions. Among the list of functions is the NetRemoteTOD function, which is exposed via NET TIME. This function can be called locally on a computer to get the time on a remote system using RPC. Now, you may be saying "Ryan, why would I use the NET TIME command when I can call 'w32tm.exe /stripchart' and get essentially the same information, but more accurately?" I'm glad you asked!

Let's take a moment and read a sentence from that last paragraph again. The NetRemoteTOD function can be called locally on a computer to get the time on a remote system using RPC. The important part is that this communication occurs using RPC, not NTP, which is why the NET TIME command is still useful today. Let's say that for some reason the time service wasn't running on a particular computer, perhaps because it had (gasp!) crashed or (double-gasp) was mis-configured and was not running. Well, if you need to check the time on that system, you are out of luck with w32tm.exe. Because w32tm.exe uses NTP to check the time on a remote system, the time service needs to be running on that remote system in order for the time check to work. By comparison, since the NetRemoteTOD facility uses RPC, the remote system only needs to have the RPC service running on a remote system in order to check the time. This is the power of NET TIME.

The NET TIME command is however not perfect. In a typical environment, domain controllers (which are the typical target of a NetRemoteTOD call) might not be accessible from every machine on the domain. On the other hand, UDP 123 which is used by the time service is rarely blocked.

How to use the NET TIME command

The net.exe application the following syntax:

 C:\>net
The syntax of this command is:

NET
    [ ACCOUNTS | COMPUTER | CONFIG | CONTINUE | FILE | GROUP | HELP |
      HELPMSG | LOCALGROUP | PAUSE | SESSION | SHARE | START |
      STATISTICS | STOP | TIME | USE | USER | VIEW ]

We are particularly interested in the 'TIME' argument, which has the following syntax (note that this is the output according to Windows7):

C:\>net help time
The syntax of this command is:

NET TIME

[\\computername | /DOMAIN[:domainname] | /RTSDOMAIN[:domainname]] [/SET]

NET TIME synchronizes the computer's clock with that of another computer
or domain, or displays the time for a computer or domain. When used without
options on a Windows Server domain, it displays the current
date and time at the computer designated as the time server for the domain.

\\computername  Is the name of the computer you want to check or
                synchronize with.

/DOMAIN[:domainname]  Specifies to synchronize the time from the Primary Domain
                      Controller of domainname.

/RTSDOMAIN[:domainname]  Specifies to synchronize with a Reliable Time Server
                         from domainname.

/SET            Synchronizes the computer's time with the time
                on the specified computer or domain.

The /QUERYSNTP and /SETSNTP options have been deprecated. Please use w32tm.exe
to configure the Windows Time Service.

NET HELP command | MORE displays Help one screen at a time.

As you can see, there are a number of options here, all of which deserve some explanation. By default, when you run the NET TIME command without any arguments, it will attempt to locate a domain controller (using DC Locator) and then use NetRemoteTOD to get the time on that DC.

The NET TIME command exposes three switches which can be used to control it's behavior. The /DOMAIN option can be used to specify the name of a domain in which to locate a domain controller to talk to by requesting a domain controller with the TIMESERV flag set in NetLogon.  The /RTSDOMAIN option works the same way, except that it requests a domain controller with the GTIMESERV flag set instead. The /SET command can be used to update the clock on the local computer to match the time stamp returned by the remote computer.

Finally, you can call the NET TIME command with the name of a machine on your network to force NET TIME to get the time of that machine, rather than locating a domain controller.

You may also notice that the /QUERYSNTP and /SETSNTP flags are also included with the NET TIME command. Prior to the days of w32tm.exe, these commands were used to configured the server that w32time would synchronize with. Since w32tm.exe handles this work now, the /QUERYSNTP and /SETSNTP arguments have been deprecated.

Putting it in practice

By calling the NET TIME command without any arguments, we will get the time according to a domain controller in the domain. The domain controller that is chosen is completely arbitrary - there is no guarantee that you will get a specific DC, only that it will have the TIMESERV flag set, saying that it is a time server for the domain.

C:\>net time
Current time at \\DC-01.mydomain.com is 8/7/2009 10:01:42 AM

If we use the /DOMAIN flag, we can specify the domain that we want to query:

C:\>net time /DOMAIN:mydomain.com
Current time at \\DC-01.mydomain.com is 8/7/2009 10:04:12 AM

Additionally, we can query the domain controller directly:

 C:\>net time \\DC-01.mydomain.com
Current time at \\DC-01.mydomain.com is 8/7/2009 10:06:01 AM

In fact, the machine that we query doesn't need to be a domain controller. I could just as easily query my local machine using the NetRemoteTOD facility:

C:\>net time \\localhost
Current time at \\localhost is 8/7/2009 10:12:11 AM

Note: Keep in mind that unless you explicitly specify the name of the machine you want to query, the NET TIME command will locate a time source using DC Locator. If the time service has failed for one reason or another, the TIMESERV flag will likely NOT be set for that machine. However, you can still query the machine explicitly and you will still be able to check the time on that machine.

Conclusion

As always, I try to anticipate any questions you might have regarding the content here. However, if you do have any questions or feel that I have missed something, please post a comment below. If you have a general question about the time service, I encourage you to ask it in the forums.

]]> Group Policy Settings Explained https://docs.microsoft.com/archive/blogs/w32time/group-policy-settings-explained Mon, 02 Feb 2009 11:31:00 GMT https://blogs.msdn.microsoft.com/w32time/2009/02/02/group-policy-settings-explained/ In an effort to alleviate confusion around the Windows Time Service group policy settings, here is a detailed explaination of the various settings, what their respective purposes are, and a small bit about how to configure them.

Keep in mind that Windows Time Service is designed to be very robust right out of the box. Only adjust these settings if you see a clear and present reason to do so.

Note that these settings are targeted at Windows Server 2008.

W32Time Global Configuration Settings
    
      Specifies a set of parameters for all domain controllers that are installed in your environment. These parameters may differ from the parameters that are set on domain member computers. For domain member values, see Configure a client computer for automatic domain time synchronization (https://go.microsoft.com/fwlink/?LinkId=139706). These parameters control how the local clock is controlled (disciplined) and how availability is advertised. Many of the settings are scalar values. This means that they do not correspond to specific unit measurements; instead, the values have meaning only in relation to one another.

Clock discipline parameters

FrequencyCorrectRate: This is a scalar value that controls the rate at which the Windows Time service (W32time) corrects the local clock's frequency (speed). Lower values reduce the local clock's frequency, which causes the local clock to correct more slowly. Larger values cause the local clock to correct more quickly. If this value is too small, the local clock is unstable and it overcorrects. If this value is too large, the clock takes a long time to synchronize. This value must be set to a whole number of 1 or greater. The default value is 4.

HoldPeriod: This value indicates how many potentially accurate time samples the client must receive in a series before subsequent time samples are evaluated as potential spikes. After a period of not receiving any usable time samples, a time client ceases to evaluate time samples for spikes as soon as the first potentially accurate time sample is received. When a series of time samples (as indicated by the HoldPeriod) is received, the time client evaluates subsequent time samples for spikes. A time sample is considered to be a spike when the time difference between a time sample and the client's local clock is greater than that of the LargePhaseOffset value. The default HoldPeriod value is 5.

LargePhaseOffset: This value, expressed in 100-nanosecond (ns) units, specifies the time variation from the client's local clock (phase offset) that a time sample must have to be considered a spike. Time samples that have time variations larger than the LargePhaseOffset value are considered spikes. The default value is fifty million (50,000,000, or 5 seconds). For reference, there are 10 million (10,000,000) 100-ns units in 1 second.

MaxAllowedPhaseOffset: This value, expressed in seconds, controls how W32time corrects the clock based on the size of the calculated time variation between the time sample and the client's local clock. If a response is received that has a time variation that is larger than this value, W32time sets the client's local clock immediately to the time that is accepted as accurate from the Network Time Protocol (NTP) server. If the time variation is less than this value, the client's local clock is corrected gradually. The default value is 300 seconds (5 minutes).

MaxNegPhaseCorrection: This value, expressed in seconds, controls the maximum allowable clock correction that can be made in a reverse direction. If a time sample is received that indicates a time in the past (as compared to the client's local clock) that has a time difference that is greater than the MaxNegPhaseCorrection value, the time sample is discarded. If this happens, the Windows Time source logs an event in the System log of Event Viewer. The default value is 172,800 seconds (48 hours).

MaxPosPhaseCorrection: This value, expressed in seconds, controls the maximum allowable clock correction that can be made in a forward direction. If a time sample is received that indicates a time in the future (as compared to the client's local clock) that has a time difference greater than the MaxPosPhaseCorrection value, the time sample is discarded. If this happens, the Windows Time source logs an event in the System log of Event Viewer. The default value is 172,800 seconds (48 hours).

PhaseCorrectRate: This is a scalar value that controls how quickly W32time corrects the client's local clock difference to match time samples that are accepted as accurate from the NTP server. Lower values cause the clock to correct more slowly, while larger values cause the clock to correct more quickly. This value must be a whole number greater than 0. The default value is 7.

PollAdjustFactor: This is a scalar value that controls how quickly W32time changes polling intervals. When responses are considered to be accurate, the polling interval lengthens automatically. When responses are considered to be inaccurate, the polling interval shortens automatically. The default value is 5.

SpikeWatchPeriod: This value, expressed in seconds, specifies the amount of time that suspicious time samples are received from a time source before these time samples are accepted as accurate. Time samples are considered suspicious when the time difference between the time sample and the client's local clock is larger than the value of LargePhaseOffset. SpikeWatchPeriod is used in conjunction with the HoldPeriod to help eliminate sporadic, inaccurate time samples that are returned from a peer. The default value is 900 seconds (15 minutes).

UpdateInterval: This value, expressed in 1/100-second units, specifies the amount of time that W32time waits between corrections when the clock is being corrected gradually. When it makes a gradual correction, the service adjusts the clock slightly, waits this amount of time, and then checks to see if another adjustment is needed, until the correction is finished. The default value is 100 hundredths of a second units (1 second).

General parameters:

AnnounceFlags: This is a bitmask value that controls how time service availability is advertised through NetLogon. For all possible values, see Config\AnnounceFlags Entry (https://go.microsoft.com/fwlink/?LinkId=139718). The default value is 10 decimal (0x0a hexadecimal).

EventLogFlags: This is a bitmask value that controls special events that may be logged to the Event Viewer System log. For all possible values, see NtpClient\EventLogFlags Subkey (https://go.microsoft.com/fwlink/?LinkId=139720). The default value is 2 decimal (0x02 hexadecimal).

LocalClockDispersion: This setting, expressed in seconds, is applicable only when the NTP server is using the time of the local CMOS clock. The LocalClockDispersion value indicates the maximum error in seconds that is reported by the NTP server to clients that are requesting a time sample. The default value is 10 seconds.

MaxPollInterval: This value, expressed in log base-2 seconds, controls the maximum polling interval, which defines the maximum amount of time between polls of a peer. The default value is 10, which is computed as 2 to the power of 10 and equals 1,024 seconds. The time service itself is considered unsynchronized after 1.5 times the number of seconds that are specified by this entry have elapsed. NTP specifies that the maximum clock age is 86,400 seconds. Therefore, if the value of this entry is greater than 15, peers will eventually ignore this server.

MinPollInterval: This value, expressed in log base-2 seconds, controls the minimum polling interval that defines the minimum amount of time between polls of a peer. The default value is 6, which is computed as 2 to the power of 6 and equals 64 seconds.


Read-only domain controller parameters:

To learn more about how Windows Time service works on a read-only domain controller (RODC), see Appendix A: Technical Reference Topics (https://go.microsoft.com/fwlink/?LinkID=128273).

ChainEntryTimeout: This value, expressed in seconds, specifies the maximum amount of time that an entry can remain in the chaining table before the entry is considered to be expired. Entries that are marked as expired may be removed when the next request or response is processed on the RODC. The default value is 16 seconds.

ChainMaxEntries: This value, expressed as a number of entries, controls the maximum number of entries that are allowed in the chaining table. If the chaining table is full and no expired entries can be removed, any incoming requests are discarded. The default value is 128 entries.

ChainMaxHostEntries: This value, expressed as a number of entries, controls the maximum number of entries that are allowed in the chaining table for a particular host. If a time synchronization request is received and the chaining table already contains the maximum number of entries for that IP address, the request is discarded. The default value is 4 entries.

ChainDisable: This value, expressed as boolean value, controls whether or not the chaining mechanism is disabled. If chaining is disabled, the RODC can synchronize with any domain controller, but hosts that do not have their passwords cached on the RODC will not be able to synchronize with the RODC. The possible values are 1, which disables chaining, or 0, which enables chaining. The default value is 0.

ChainLoggingRate: This value, expressed in minutes, controls the frequency that an event that indicates the number of successful and unsuccessful chaining attempts is logged to the System log in Event Viewer. The default value is 30, which causes an event to be generated every 30 minutes.


W32Time NTP Client Configuration Settings
     
Specifies a set of parameters for controlling the Windows NTP Client.

NtpServer: The Domain Name System (DNS) name or IP address of an NTP time source. This value is in the form of "dnsName,flags" where flags is a hexadecimal bitmask of the flags for that host. For more information, see the NTP Client Group Policy Settings Associated with Windows Time section of the Windows Time Service Group Policy Settings (https://go.microsoft.com/fwlink/?LinkId=139727). The default value is "time.windows.com,0x09".

Type: This value controls the authentication that W32time uses. The default value is NT5DS.

CrossSiteSyncFlags: This value, expressed as a bitmask, controls how W32time chooses time sources outside its own site. The possible values are 0, 1, and 2. Setting this value to 0 (None) indicates that the time client should not attempt to synchronize time outside its site. Setting this value to 1 (PdcOnly) indicates that only the computers that function as primary domain controller (PDC) emulator operations masters in other domains can be used as synchronization partners when the client has to synchronize time with a partner outside its own site. Setting a value of 2 (All) indicates that any synchronization partner can be used. This value is ignored if the NT5DS value is not set. The default value is 2 decimal (0x02 hexadecimal).

ResolvePeerBackoffMinutes: This value, expressed in minutes, controls how long W32time waits before it attempts to resolve a DNS name when a previous attempt failed. The default value is 15 minutes.

ResolvePeerBackoffMaxTimes: This value controls how many times W32time attempts to resolve a DNS name before the discovery process is restarted. Each time DNS name resolution fails, the amount of time to wait before the next attempt will be twice the previous amount. The default value is 7 attempts.

SpecialPollInterval: This NTP client value, expressed in seconds, controls how often a manually configured time source is polled when the time source is configured to use a special polling interval. If the SpecialInterval flag is enabled on the NTPServer setting, the client uses the value that is set as the SpecialPollInterval, instead of the MinPollInterval and MaxPollInterval values, to determine how frequently to poll the time source. The default value is 3600 seconds (1 hour).

EventLogFlags: This value is a bitmask that controls events that may be logged to the System log in Event Viewer. Setting this value to 0x1 indicates that W32time will create an event whenever a time jump is detected. Setting this value to 0x2 indicates that W32time will create an event whenever a time source change is made. Because it is a bitmask value, setting 0x3 (the addition of 0x1 and 0x2) indicates that both time jumps and time source changes will be logged.

]]> Demystifying Group Policy Settings https://docs.microsoft.com/archive/blogs/w32time/demystifying-group-policy-settings Fri, 30 Jan 2009 18:12:00 GMT https://blogs.msdn.microsoft.com/w32time/2009/01/30/demystifying-group-policy-settings/ The settings for the Windows Time Service exposed through group policy have long been seen as a bit mysterious, and for good reason. Well, today we will take the first steps towards remedying that problem. After spending a good amount of time with one of my favorite writers (thanks Kurt!), we have developed a revised text for explaining these group policy settings.

Keep in mind that this is simple text. The prupose is not to explain every scenario where these values should be changed or which environments dictate that a change be made. Rather the point of this text is simply to provide a better understanding of what these values are, what effect they will have on the Time Service, and what values are applicable when adjusting these settings.

https://blogs.msdn.com/w32time/pages/group-policy-settings-explained.aspx

Enjoy!

]]> Configuring an Authoritative Time Server with Group Policy Using WMI Filtering https://docs.microsoft.com/archive/blogs/w32time/configuring-an-authoritative-time-server-with-group-policy-using-wmi-filtering Fri, 05 Dec 2008 18:45:00 GMT https://blogs.msdn.microsoft.com/w32time/2008/12/05/configuring-an-authoritative-time-server-with-group-policy-using-wmi-filtering/ https://blogs.technet.com/askds/archive/2008/11/13/configuring-an-authoritative-time-server-with-group-policy-using-wmi-filtering.aspx]]>