Configure Network Time Protocol on Windows endpoints with customizable NTP server and synchronization settings
This Automox Worklet™ configures the Windows NTP client service by modifying registry settings that control time synchronization behavior. The Worklet enables you to specify the NTP server, configure synchronization type, set polling intervals, and control cross-site domain synchronization flags.
The Worklet manages eight registry properties under HKLM:\SOFTWARE\Policies\Microsoft\W32time\ to control NTP client operations. It sets the NTP server address and behavior flags, defines whether time synchronization uses NTP servers or domain hierarchy (Nt5DS), and configures event logging for NTP events. All settings are stored in the Windows Registry and take effect immediately after the Worklet completes.
The Worklet supports fully customizable parameters, allowing you to override default NTP servers, adjust polling intervals in seconds, control DNS lookup retry behavior in minutes, configure site-specific synchronization flags for domain-joined endpoints, and define which NTP events are logged to the Windows Event Log.
Time synchronization is a foundational requirement for IT operations. When endpoints have misaligned system clocks, certificate validation fails, authentication logs become unreliable, and security incident timelines cannot be accurately reconstructed. Synchronized time across your infrastructure enables proper forensic analysis, maintains security events are correctly sequenced, and prevents outages caused by Kerberos authentication failures in Active Directory environments.
Many compliance frameworks require documented time synchronization strategies. Using this Worklet demonstrates that your organization maintains standardized NTP configuration aligned with NIST recommendations. Your IT operations team benefits from centralized time management that reduces support tickets related to clock skew, simplifies troubleshooting of time-dependent services, and prevents endpoints from drifting when automatic time updates are disabled.
For domain-joined endpoints, configuring explicit NTP servers prevents dependency on internal domain controllers for time synchronization, improving resilience and reducing domain infrastructure load. Organizations can standardize on trusted external NTP servers like NIST (time.nist.gov) or deploy their own internal time infrastructure while verifying all endpoints remain synchronized.
Evaluation phase: The Worklet connects to the Windows Registry and examines all eight NTP client configuration properties: NtpServer (under SOFTWARE\Policies\Microsoft\W32time\Parameters), Type, and six properties under SOFTWARE\Policies\Microsoft\W32time\TimeProviders\NtpClient (CrossSiteSyncFlags, ResolvePeerBackoffMinutes, ResolvePeerBackoffMaxTimes, SpecialPollInterval, EventLogFlags, and Enabled). For each property, the Worklet compares the current registry value against the desired configuration. If all eight properties match the specified values exactly, the Worklet exits with exit code 0 (compliant). If any property differs, the Worklet exits with exit code 2, indicating remediation is required.
Remediation phase: The Worklet attempts to create the registry path structure if it does not exist. It then sets all eight NTP client properties to the specified values. The NtpServer property is set to the NTP server address combined with flags (default: time.nist.gov,0x9). The Type property controls synchronization behavior (NTP, Nt5DS, AllSync, or NoSync). CrossSiteSyncFlags allows time synchronization across Active Directory sites (0x0 = no cross-site, 0x1 = primary DC only, 0x2 = allow cross-site). ResolvePeerBackoffMinutes (default 1) defines retry intervals for failed DNS lookups, and ResolvePeerBackoffMaxTimes (default 8) limits retry attempts before requesting a new server from the network. SpecialPollInterval (default 300 seconds) sets the synchronization frequency. EventLogFlags (0x3) logs time jumps and server changes. The Enabled property (default 1) activates the NTP client. After all properties are set, the Worklet exits with code 0.
Windows Server 2016 or newer, or Windows 10/11 endpoints (all editions supported)
PowerShell 5.0 or higher for script execution
Administrator privileges required to modify Windows Registry (HKLM hive)
Network connectivity to the specified NTP server (default: time.nist.gov on UDP port 123)
For custom parameters: knowledge of desired NTP server address, flags format (0x1, 0x2, 0x4, 0x8, 0x9), and polling interval in seconds
For domain-joined endpoints: optional understanding of Active Directory site topology for CrossSiteSyncFlags configuration
Registry write access to HKLM:\SOFTWARE\Policies\Microsoft\W32time\ (paths are created automatically if missing)
No additional services or software dependencies required beyond Windows operating system components
After the Worklet completes successfully, your endpoint will synchronize system time with the configured NTP server. The Windows Time service (W32Time) uses the registry settings to determine polling frequency, retry behavior, and event logging. You can verify successful configuration by opening the Windows Registry Editor and navigating to HKLM:\SOFTWARE\Policies\Microsoft\W32time\ to confirm all registry properties match your specified values.
Monitor time synchronization status using the command: w32tm /status (shows current time source) or w32tm /query /status /verbose (provides detailed synchronization information including offset, poll interval, and reference ID). The Event Viewer (eventvwr.msc) under System logs will display NTP events if EventLogFlags is configured with values 0x1 or 0x2. For domain-joined endpoints, you can verify the configuration applied correctly across your fleet by running w32tm /status on multiple endpoints and confirming they reference the same NTP server. If an endpoint fails the evaluation phase in a subsequent Worklet run, the registry properties do not match the desired configuration, indicating external changes were made or Group Policy overrides are in effect.
Run this Worklet on a pilot Windows endpoint and review evaluation output for configure endpoint ntp service.
Confirm Automox activity logs show successful completion and exit code 0.
Verify endpoint state using checks aligned to evaluation script logic, such as the evaluation and remediation scripts.
Validate remediation effects from script operations such as the evaluation and remediation scripts, then rerun evaluation for compliance.


By submitting this form you agree to our Master Services Agreement and Privacy Policy.
Already have an account? Log in
Consider Worklets your easy button
A Worklet is an automation script, written in Bash or PowerShell, designed for seamless execution on endpoints – at scale – within the Automox platform. Worklet automation scripts perform configuration, remediation, and the installation or removal of applications and settings across Windows, macOS, and Linux.

AUTOMOX + WORKLETS™
Uncover new possibilities with simple, powerful automation.
By submitting this form you agree to our Master Services Agreement and Privacy Policy