In my previous blog post we reviewed why time synchronization is important, as well as proper time synchronization configuration of domain controllers (DCs) holding the Primary Domain Controller Emulator (PDCe) role. We were able to properly configure Network Time Protocol (NTP) settings through the use of Windows Management Instrumentation (WMI) filters and Group Policy. Like with many topics, a deeper dive into NTP configurations can be useful for better understanding and custom configurations. In this blog we review troubleshooting NTP configurations for PDCes, DCs, and clients, as well as Group Policy settings for configuring time synchronization.
Troubleshooting NTP Configurations
Time synchronization is a very mature technology. Errors are most likely the result of one of two issues:
- Inability to reach the configured NTP server due to networking issues
- Misconfiguration either through policy or manual settings
To ensure that your device can reach the configured NTP server as expected, you can manually test access on UDP Port 123 or use the W32tm tool’s stripchart feature. This can be useful both to troubleshoot clients and to ensure that clients can reach your DCs for NTP synchronization.
In CMD
C:\Users\admin>w32tm /stripchart /computer:10.9.100.201
Tracking 10.9.100.201 [10.9.100.201:123].
The current time is 1/1/2022 11:58:18 AM.
11:58:18, d:+00.0057377s o:+00.1040979s [ * ]
11:58:20, d:+00.0068636s o:+00.1026444s [ * ]
11:58:22, d:+00.0044055s o:+00.1043254s [ * ]
11:58:24, d:+00.0039553s o:+00.1039550s [ * ]
11:58:26, d:+00.0062549s o:+00.1028866s [ * ]
11:58:28, d:+00.0036898s o:+00.1041307s [ * ]
Leftover manual configurations or incorrect Group Policy Object (GPO) settings may cause NTP configuration errors. In the event of a misconfiguration, the default behavior is for the Windows operating system to default back to the local CMOS clock. An example of the results of a broken configuration can be seen in Figure 1. Note that the source is set to Local CMOS Clock and the Stratum value is undefined. Stratum is covered in more detail later in this blog post.
In CMD
C:\Users\admin>w32tm /query /status
Leap Indicator: 3(last minute has 61 seconds)
Stratum: 0 (unspecified)
Precision: -6 (15.625ms per tick)
Root Delay: 0.0000000s
Root Dispersion: 0.0000000s
ReferenceId: 0x0000000 (unspecified)
Last Successful Sync Time: unspecified
Source: Local CMOS Clock
Poll Interval: 6 (64s)
Figure 1 – Example of output of misconfigured NTP settings
In such a situation it is important to determine where the settings are being applied from. There are three common situations in which NTP settings are applied:
- Local configuration on the client or server, such as manual registry settings
- Group Policy applied that gives incorrect settings
- Virtual machines (VMs) synchronizing time automatically from their host
Group Policy can be checked by running a Group Policy report and looking for the results of the NTP configurations. You can generate a Group Policy report using the gpresult tool. To generate a report, open an administrative command prompt and use the following command:
In CMD
gpresult /h results.html
This will generate a Group Policy report in the form of an HTML document that can be used to review the current configuration. Check the document under the following path to review the current NTP configuration settings applied via Group Policy:
Computer Configuration > Policies > Administrative Templates > System > Windows Time Service > Time Providers
As we can see in Figure 2, the Group Policy report shows an incorrect NtpServer value, causing the client to fall back to using the local CMOS clock.
Figure 2 – The NtpServer URL is misconfigured
In some situations, VMs may also inherit time settings from their hypervisor. You can manually configure a VM to not inherit time from its host by editing the VMICTimeProvider registry key. Open Regedit and navigate to the key stored at
HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider
To prevent a virtual client from syncing with its host, modify the Enabled key to a REG_DWORD value of 0.
To resolve these issues for any server or client other than the DC holding the PDCe role, use the following procedure:
- Ensure the impacted client has no Group Policy configuration applied that would impact NTP settings.
- Restore the client to the default Windows NTP configuration using the W32tm tool.
- Ensure the VMICTimeProvider registry key is properly configured.
When the W32tm service is unregistered and reregistered, it will default back to using the NT5DS time synchronization method. This is generally preferred for any device other than a DC holding the PDCe role. Once the Group Policy settings that may be impacting the client are removed, log on to the impacted client and open an administrative command prompt. Enter the following commands:
In CMD
gpupdate /force
net stop w32time
w32tm /unregister
w32tm /register
net start w32time
After these commands run, recheck the NTP client configuration status by entering the following command:
In CMD
w32tm /query /status
Note: It may take a few minutes from the service restarting to accurately reflect syncing configuration. You may still see time synchronizing from CMOS during this time.
To resolve these issues for a DC holding the PDCe role, perform the following procedure:
- Ensure the impacted client has a proper Group Policy configuration, as noted in my previous blog post.
- Ensure the VMICTimeProvider registry key is properly configured.
- Restore the client to the default Windows NTP configuration using the W32tm tool as explained above.
NTP GPO Configuration Details
Although for most situations there is no need to deviate from Microsoft default settings, a general understanding of the settings being applied can be useful for determining custom settings. All Group Policy NTP settings can be found in the following location:
Computer Configuration > Policies > Administrative Templates > System > Windows Time Service
If specific errors or issues are noted, it may be useful to carefully review the Group Policy configurations for troubleshooting purposes. The NTP settings that can be configured through Group Policy are as follows:
NTP Server: Specifies the external server to sync against. This setting will only work correctly if the Type is defined as NTP. Notice the bitmask at the end of each URL. This will apply settings based on the bitmask set. The bitmasks are additive, so for our setting of 0x09 we are specifying the use of Special Interval and Client (0x01 + 0x08 = 0x09).
The settings are as follows:
| Bitmask | Name | Detail |
| 0x00 | The DC will not advertise any time service | |
| 0x01 | SpecialInterval | Indicates that the DC should sync using the SpecialPollInterval time frame defined in the GPO |
| 0x02 | UseAsFallbackOnly | Indicates that the DC should only use this source if the primary source is not available |
| 0x04 | SymmetricActive | Indicates that the DC can sync from and to another source symmetrically. Synching symmetrically means the device can receive time from another device of the same stratum if it cannot reach a server of a lower stratum. |
| 0x08 | Client | Indicates that the DC is configured as a client to receive time |
Type: Specifies the method used for determining time sources. Our DC holding the PDCe role should use NTP to sync externally. All other Windows devices should use NT5DS or AllSync depending on use-case. NT5DS will only allow the client to sync from the domain hierarchy. AllSync will attempt to use the domain hierarchy and can be configured to fall back to another external NTP source. AllSync may be desirable for remote clients that may not have regular visibility to your domain hierarchy preventing NT5DS synchronization. A common example of this would be laptop devices that may not commonly be able to query your on-premises DCs. In such situations it is recommended that the backup external NTP servers be the same external NTP servers your DC holding the PDCe role is configured to query time from.
CrossSiteSyncFlags: Determines which sources of time a client can sync from outside of its own AD site. Note that this setting does nothing if NT5DS is not set. The settings are in bitmask format and are as follows:
| Value | Name | Details |
| 0 | None | Indicates that the client should never attempt to synchronize time outside of its own site |
| 1 | PDCOnly | Indicates that the computers that function as PDCes in other domains can be used as synchronization partners outside of the client’s own site |
| 2 | All | Indicates that any synchronization partner outside of the client’s own site may be used |
ResolvePeerBackoffMinutes: Sets the wait interval before attempting to synchronize with a peer. A peer is another device of the same strata value. If the time service fails to sync, it will retry using the time specified in this value.
ResolvePeerBackoffMaxTimes: Sets the maximum number of times to double the period of the ResolvePeerBackoffMinutes variable during peer synchronization failure. For example, if the ResolvePeerBackoffMinutes value is set to five and fails to sync, the client will wait 10 minutes, then 20, then 40.
SpecialPollInterval: Controls how often the client will attempt to sync with the external time source. This value is expressed in seconds. The default value is 3600, or one hour.
EventLogFlags: This value is a bitmask that controls how time-related events will be logged in Event Viewer. This can be especially useful if you can integrate with a Security Information and Event Management (SIEM) solution or create alerts for significant time synchronization changes for important clients such as DCs. As with other bitmasks, these values are additive and can be combined, which is how we reach our value of 3.
| Value | Name | Details |
| 0 | No logging | No NTP-related information is logged |
| 1 | Time Jump | An event is created whenever the time source “jumps” or has a significant change |
| 2 | Time Source Change | An event is created whenever the time source changes |
Additional NTP Terminology
Additional NTP Terminology
There are a few additional terms you might see relating to NTP synchronization. These include:
Stratum: A number value specifying the hierarchy of a time server. The lower the stratum value, the closer an object is to the base reference clock.
Root Delay: The round-trip packet delay from a client to a Stratum 1 server. This essentially gives a worst-case time error between the client and the server.
Root Dispersion: Provides information about how much skew is added due to other factors such as inaccurate clock frequency.
In Conclusion
Most time synchronization errors can be quickly resolved and managed through policy, taking one more thing off the busy administrator’s plate. Native Windows tools allow for quick troubleshooting and reconfiguration when required.
Need help with Active Directory, or looking for a review of your NTP settings? Contact the experts at Ravenswood Technology Group today!
