Windows - System Preferences - Configure Device NTP Service

What the Windows NTP enforcement Worklet does

This Automox Worklet™ enforces a known-good NTP client configuration for the Windows Time service (W32Time) on every endpoint in your fleet. The Worklet manages eight registry properties under HKLM:\SOFTWARE\Policies\Microsoft\W32time\ that drive the NTP server target, the sync type, the polling cadence, and the event-logging behavior. Endpoints already aligned with the baseline are left untouched.

Two properties live under the Parameters subkey: NtpServer (server address combined with a flags suffix such as time.nist.gov,0x9) and Type (NTP, Nt5DS, AllSync, or NoSync). Six more live under TimeProviders\NtpClient: CrossSiteSyncFlags, ResolvePeerBackoffMinutes, ResolvePeerBackoffMaxTimes, SpecialPollInterval, EventLogFlags, and Enabled. The Worklet opens the HKLM hive in the correct 32-bit or 64-bit view, creates any missing path, and writes each property with the correct String or DWord type.

Every value is exposed as a policy parameter. You can override the default NTP server (time.nist.gov), pick a sync type for domain-joined or workgroup endpoints, and change the polling interval in seconds. You can also adjust DNS lookup backoff in minutes, choose which Active Directory site-sync behavior applies, and decide which NTP events are written to the Windows Event Log. The defaults match a sensible external-NTP baseline for non-domain or hybrid fleets.

Why enforce a Windows NTP baseline

Clock skew on a Windows endpoint breaks the things ITOps cannot afford to debug ad hoc. Kerberos authentication fails when the endpoint clock drifts more than five minutes from the domain controller. TLS handshakes fail when the certificate validity window appears to be in the future. SIEM correlation collapses when two endpoints reporting the same incident disagree on the timestamp by ninety seconds. The W32Time registry properties this Worklet writes are also the controls referenced by CIS Microsoft Windows benchmarks for time configuration and by NIST SP 800-53 control AU-8 (Time Stamps).

W32Time registry settings drift every time Group Policy refreshes against a stale template, an in-place upgrade resets defaults, or an admin fixes a single-endpoint clock skew by hand. Run this Worklet on the workstation and server groups in scope and the next evaluation catches a flipped Type value, a missing NtpServer entry, or a polling interval that no longer matches policy. Accurate time aligns with PCI-DSS requirement 10.4 and NIST 800-53 AU-8 audit time-stamp controls, so a clean evaluation result doubles as an audit artifact.

How NTP baseline enforcement works

1. Evaluation phase: The Worklet opens the HKLM hive using Registry64 on 64-bit Windows or Registry32 on 32-bit Windows, then inspects all eight properties: NtpServer and Type under SOFTWARE\Policies\Microsoft\W32time\Parameters, and CrossSiteSyncFlags, ResolvePeerBackoffMinutes, ResolvePeerBackoffMaxTimes, SpecialPollInterval, EventLogFlags, and Enabled under SOFTWARE\Policies\Microsoft\W32time\TimeProviders\NtpClient. If a required subkey is missing, or any property value differs from the policy parameters, evaluation exits 2 and remediation is scheduled. If every property matches, evaluation exits 0 and the endpoint is reported compliant without any registry writes.

2. Remediation phase: The Worklet creates any missing subkey under HKLM:\SOFTWARE\Policies\Microsoft\W32time\, then writes each of the eight properties with the correct registry type. NtpServer is written as a String built from the NTPServer and NTPFlags parameters (default time.nist.gov,0x9, which combines special-poll mode with client-only mode). Type is written as a String (default NTP for external sync; use Nt5DS to follow domain hierarchy or AllSync for fallback chaining). CrossSiteSyncFlags, ResolvePeerBackoffMinutes, ResolvePeerBackoffMaxTimes, SpecialPollInterval, EventLogFlags, and Enabled are written as DWord values from the matching parameters. If subkey creation or any write fails, the Worklet exits 2 with an error on stderr; otherwise it exits 0 once every property matches the baseline.

Windows NTP enforcement requirements

• Windows 10, Windows 11, or Windows Server 2016 and newer (workstation and server SKUs are both supported)

• PowerShell 5.0 or later, which is the default on every supported Windows build

• Local administrator context for the Automox agent so it can write to HKLM (the default agent context already satisfies this)

• Outbound UDP 123 to the configured NTP server (default time.nist.gov; substitute an internal stratum-2 mirror for air-gapped or PCI-segmented fleets)

• Policy parameters set as needed: NTPState, NTPServer, NTPFlags, NTPSyncType, NTPSiteSyncFlags, NTPRetryDNSInterval, NTPRetryDNSMaxTimes, NTPPollInterval, NTPEventLogFlags

• Pick the correct NTPSyncType for the host role: NTP for non-domain or hybrid endpoints, Nt5DS for domain-joined endpoints that should follow the domain hierarchy, AllSync to attempt Nt5DS then fall back to NTP, NoSync to disable

• Awareness that Group Policy time settings take precedence on domain-joined endpoints; coordinate with the GPO owner before enforcing a competing baseline

Expected W32Time state after enforcement

After the Worklet exits 0, the eight registry properties under HKLM:\SOFTWARE\Policies\Microsoft\W32time\ match the policy parameters exactly. The Worklet does not restart the W32Time service or force a resync; the service picks up the new configuration on its next reload, which you can trigger with w32tm /config /update or by restarting the W32Time service. Subsequent evaluations return exit code 0 without touching the registry, because each property already matches the baseline.

Confirm the new posture from an elevated PowerShell prompt. Run w32tm /query /status /verbose to see the current source, last successful sync, poll interval, and reference identifier. Run w32tm /query /configuration to verify the eight properties came through with the right values and the right policy origin. Force a sync against the new source with w32tm /resync /rediscover and watch the System event log for W32Time event IDs 35 (sync established), 37 (peer received), and 50 (time correction). For a fleet-level audit trail, store the output of w32tm /query /configuration alongside the Automox policy run identifier so the configuration applied on each endpoint is reproducible at audit time.

If a subsequent Worklet run flips back to exit code 2, something rewrote the W32Time registry between evaluations. The usual culprits are a Group Policy refresh that pushes a competing time configuration, a manual w32tm /config call from a help-desk script, or a feature update that resets the W32time subkeys. The next remediation cycle restores the baseline; if the drift is constant, reconcile with the GPO owner or move the conflicting controls out of GPO and into the Automox policy.