NTP Drift Remediation Fixlet
This fixlet detects endpoints whose system clock has drifted out of sync with the configured NTP time source and remediates them by forcing a resync. Accurate system time is required for authentication protocols (Kerberos), certificate validation, log correlation, and any service that depends on timestamp ordering across machines. When an endpoint's clock drifts beyond an acceptable threshold, this fixlet becomes relevant and can be deployed to bring it back into alignment.
- This fixlet corrects drift by stepping the clock, not slewing
it.
w32tm /resync /force and sntp
-sSboth apply the correction instantly rather than gradually. The larger the existing drift, the larger and more sudden this jump will be. - Avoid deploying to endpoints running time-sensitive coordination
logic
nodes participating in a distributed lock, lease-based leader election, or a clustered service that relies on wall-clock timestamps (rather than monotonic clocks or fencing tokens) to make shared decisions. A forced clock jump mid-lease on such a node can cause it to appear to have expired or to conflict with peers.
-
Be cautious with fleet-wide deployment to clustered endpoints:
If multiple members of the same cluster receive this fixlet in the same deployment window, each may experience an independent clock jump around the same time, increasing the chance of two nodes briefly disagreeing about lock/leadership state.
- Larger existing drift = higher risk.
A badly out-of-sync endpoint will see a bigger one-shot correction than a lightly-drifted one, so consider reviewing the drift magnitude before a broad push.
- General guidance
For most standard endpoints (workstations, general-purpose servers), this Fixlet is low-risk and does exactly what it is supposed to do. The concerns above apply specifically to endpoints that are active participants in lease or timestamp-based coordination at the moment the fixlet runs, those should be excluded, staggered, or scheduled separately with monitoring.
