Jaa

Group Policy Settings Explained

  • Artikkeli

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.

Comments

  • Anonymous
    February 10, 2009
    The settings for the Windows Time Service exposed through group policy have long been seen as a bit mysterious,

  • Anonymous
    February 18, 2009
    When I follow the guidance from ADRAP report and set the "global configuration settings" via group policy and apply to all domain controllers, they do not take effect. I have tried gpupdate /force, stopped and started w32time service and tried w32tm /resync /rediscover. All to no avail. The maxposphasecorrection values remain at fffffff instead of 172800 seconds that I defined in the Group policy. Any ideas folks? Thanks. Must try a reboot of all DCs next?

  • Anonymous
    February 18, 2009
    @Stu, This sounds more like a problem with group policy than with the Time Service. You might try asking this over in the Group Policy section of the forums: http://forums.microsoft.com/TechNet/ShowForum.aspx?ForumID=2023&SiteID=17

  • Anonymous
    November 25, 2009
    The comment has been removed

  • Anonymous
    February 17, 2010
    My DHCP Server sends out "Option 004 Time Server" to all clients. Is this necessary? Does it actually tell Windows clients to use that IP address as the time server?

  • Anonymous
    November 05, 2014
    For me W32Time consistently does not adjust time from the first communication with an NTP server. It then proceeds to wait for the SpecialPollInterval (usually more than an hour). Only after it has made a second synchronization attempt, time is actually applied. This happens regardless how large SpecialPollInterval is (tried 120 to 3600 seconds), or whether the service is started at boot or restarted later. 151118 10:44:52.4843750s - Logging information: NtpClient is currently receiving valid time data from 192.168.15.254,0x01 (ntp.m|0x1|0.0.0.0:123->192.168.15.254:123). 151118 10:44:52.4843750s - W32TmServiceMain: resync req, irreg already pending. 151118 10:44:52.4843750s - W32TmServiceMain: waiting i15.984s (1023.984s) Time does not change. Then. 151118 11:44:52.5000000s - Logging information: NtpClient is currently receiving valid time data from 192.168.15.254,0x01 (ntp.m|0x1|0.0.0.0:123->192.168.15.254:123). 151118 11:44:52.5000000s - W32TmServiceMain: resync req, irreg now pending. 151118 11:44:52.5000000s - W32TmServiceMain: waiting i0.000s (511.968s) 151118 11:44:52.5000000s - W32TmServiceMain: timeout 151118 11:44:52.5000000s - Sample Prepared at 130566374925000000 for peer 192.168.15.254,0x01 (ntp.m|0x1|0.0.0.0:123->192.168.15.254:123) 151118 11:44:52.5000000s - NtpClient returned 1 samples. Time is actually updated. This is a problem if the computer does not have a working CMOS battery. It is not an issue of MaxPosPhaseCorrection being too small; an error in the Event Log is also only ever generated at the second attempt. __ In the blog post above two sentences appear to be contradicting each other. FrequencyCorrectRate: [..] Larger values cause the local clock to correct more quickly. [..] If this value is too large, the clock takes a long time to synchronize. [..]