The Clock Is the First Dependency: How Time Skew Breaks Autopilot and Looks Like a Network Fault

A pallet of refurbished laptops arrives. They were pulled from storage, wiped, and shipped. The first one boots into the out-of-box experience, joins the Wi-Fi, and then stalls. You get a generic failure. Nothing in the message mentions the one thing that is actually wrong.

You spend the afternoon on the wrong problem. You check the Autopilot profile assignment. You check the network endpoints. You check the licence on the test account. Then somebody presses Shift+F10, types date /t, and the machine says it is 2018.

The problem: a wrong clock fails as a network problem

Autopilot has no step called "check the clock". There is no screen for it. There is no error string that says the date is wrong.

What you get instead is a failure that looks like something else entirely. Microsoft states the symptom plainly in the Windows Autopilot known issues article, under the heading "Windows Autopilot device provisioning can fail".

Read that carefully. Two of the most-searched Autopilot failure classes are listed there. Trusted Platform Module (TPM) attestation errors send you hunting for firmware updates. Enrollment Status Page (ESP) timeouts send you hunting for slow app installs. Neither trail leads to the clock.

The error codes make it worse, because they are honest about the surface and silent about the cause. Microsoft documents error 0x801c03ea in self-deploying mode as meaning "TPM attestation failed, causing a failure to join Microsoft Entra ID with a device token". That is a true statement. It just does not tell you why the attestation failed.

Three fleet realities make this common rather than rare.

• Refurbished and returned hardware. A chassis that sat in a warehouse for two years has had two years to drain its coin cell.
• Factory-fresh stock with a wrong firmware clock. Some units leave the line set to a build date, or to a timezone on the other side of the world.
• Long-tail spares. The bench machine nobody powered on since the last refresh is the one that fails on the day you need it.

Why it happens: time is an input to every token check

Both authentication stacks a Windows device uses during provisioning treat time as a security control, not as cosmetics.

Kerberos. The protocol uses timestamps to defeat replay attacks. Microsoft's Kerberos troubleshooting guidance states the requirement without hedging: "The difference in time between the domain controller and the client computer or the target server must be less than five minutes." The policy that enforces it is a real, documented setting with a documented default.

Microsoft documents the Default Domain Policy value as 5 minutes, and the Domain Controller Effective Default Settings as 5 minutes. Exceed it and the Kerberos client receives KERB_AP_ERR_SKEW, logged as Event ID 4. Microsoft's entire documented remediation for that error is one line: "Make sure that the computer clocks are synchronized."

OAuth and OpenID Connect. Microsoft Entra ID issues JSON Web Tokens carrying iat (issued at), nbf (not before) and exp (expiry) claims. Microsoft's ID token guidance says these "should all fall before or after the current time, as appropriate". A device whose clock is a year behind sees a valid token as not yet valid. A device a year ahead sees it as long expired.

Transport Layer Security. Certificate validity is checked against the local clock too. The Windows Time team described the resulting deadlock better than anyone: "grossly incorrect system time can cause network security to be impaired, which in turn prevents obtaining the current time securely over the network. This is a classic circular dependency."

The part that surprises people: a pre-join device is a stand-alone client

During OOBE, before the Entra join completes, the device is not a domain member. It is what Microsoft's documentation calls a stand-alone client. That distinction changes the Windows Time service (W32Time) defaults substantially, and not in your favour.

Put those defaults together and you have the real mechanism. A device whose clock is out by twenty hours is out by more than MaxPosPhaseCorrection. The sample is rejected. The clock stays wrong. Authentication keeps failing. Nothing in the failure mentions time.

How to verify: four commands and one event log

Press Shift+F10 during OOBE to get a command prompt. Every check below is read-only.

1. Ask the time service what it thinks. The command w32tm /query /status /verbose is the highest-value single check. Microsoft's own sample output shows which fields to read: Last Successful Sync Time, Source, Phase Offset, and Last Sync Error.

2. Ask what it was configured to do, and where that came from. The command w32tm /query /configuration displays the runtime configuration and the source of each setting. Microsoft notes that when NtpServer is set through the Configure Windows NTP Client policy and applied to a domain member, W32Time does not use the NtpServer registry value, so reading the registry alone can mislead you.

3. Check the timezone separately. The command w32tm /tz displays the current timezone settings. A correct UTC offset with a wrong timezone is a different bug from a wrong clock, and it needs a different fix.

4. Read the registry rather than your assumptions. Microsoft also documents w32tm /dumpreg /subkey:Parameters for this, which avoids opening a registry editor during OOBE.

The event surface

The Windows Time service writes to the System log under the source Microsoft-Windows-Time-Service. Every event below appears in Microsoft documentation with the wording shown.

One more event sits in the same log under a different source, and it is the one that proves a jump actually happened. Microsoft documents Microsoft-Windows-Kernel-General Event ID 1 as "The system time has changed to" a new time "from" an old time, and states that it is logged every time W32Time updates the clock.

The Autopilot side of the story lives in its own channel. Microsoft documents it at Applications and Services Logs > Microsoft > Windows > ModernDeployment-Diagnostics-Provider > Autopilot, where Event ID 171 is "AutopilotManager failed to set TPM identity confirmed. HRESULT=[error code]" and Event ID 172 is documented as typically related to 171. Seeing 171 next to a Time-Service warning is the correlation that saves the afternoon.

The fix: resync now, then fix the fleet default

Step 1, unblock the device in front of you. This is Microsoft's own documented remediation, in Microsoft's own order.

1. Boot the device to the start of the out-of-box experience.
2. Establish a network connection, wired or wireless.
3. Press Shift+F10 to open a command prompt.
4. Run w32tm /resync /force.

Step 2, confirm UDP 123 is actually open. Microsoft documents that W32Time follows the Network Time Protocol specification, which "requires the use of User Datagram Protocol (UDP) port 123 for all time synchronization", and that the built-in NTP client can only use UDP 123 as its source port. A guest or provisioning VLAN that permits 443 and blocks 123 produces exactly the failure in this article. It is the most common environmental cause and it is trivially testable with a packet capture while you run w32tm /resync /rediscover.

Step 3, set the NTP client by policy so the fleet does not rely on defaults. The Windows Time Service settings are ADMX-backed, so they are available through Group Policy, through the Intune settings catalog, and through the Policy configuration service provider (CSP).

The Group Policy path:

The Intune settings catalog path:

1. Sign in to the Microsoft Intune admin center.
2. Go to Devices, then Configuration, then Create, then New policy.
3. Choose platform Windows 10 and later and profile type Settings catalog.
4. Search the catalog for Windows Time Service.
5. Add Enable Windows NTP Client and enable it. This maps to the Enabled value under W32Time\TimeProviders\NtpClient.
6. Add Configure Windows NTP Client and set NtpServer, Type and SpecialPollInterval. Microsoft documents the policy defaults as time.windows.com,0x9, NT5DS, and 1,024 seconds respectively.
7. Assign the profile to your device groups.
8. Confirm on a target device with w32tm /query /configuration, which reports the source of each setting.

The equivalent Policy CSP entries, for a custom OMA-URI or a non-Microsoft MDM, are ADMX-backed and require the SyncML chr format:

Step 4, fix the hardware and the staging process. No policy corrects a dead coin cell. Add three things to your intake workflow for refurbished or stored stock. Read the firmware clock before the device ships. Replace flat complementary metal-oxide-semiconductor (CMOS) batteries at the bench. Power each unit on once with network access, so Secure Time Seeding and NTP get a chance to run before a technician is standing over it.

Proof it worked: the readiness report, before and after

The companion script collects the whole picture in one pass. It reports service state, the configured source and type, the last successful sync, the measured offset against a reference peer, the timezone, and whether the offset exceeds the documented five-minute Kerberos tolerance. It is read-only. It never sets the clock and it never calls w32tm /resync.

Two behaviours are worth knowing before you run it. First, if the stripchart measurement returns no usable samples, the script aborts with exit code 1 rather than reporting a healthy clock, because a clean result from a failed measurement is worse than no result. Second, the optional -CheckIntunePolicy switch adds read-only Microsoft Graph GET calls, scoped to DeviceManagementConfiguration.Read.All, that list any Intune configuration policy whose name or description mentions the Windows Time Service. That answers the follow-up question every one of these incidents raises: is the whole fleet still running on built-in defaults?

The value of the report is not the pass. It is the shape of the fail. An offset larger than MaxPosPhaseCorrection tells you immediately that no amount of waiting will fix this device, because the sample that would fix it is being discarded by design.

References

• Windows Autopilot known issues — the documented real-time clock failure mode, the w32tm /resync /force remediation, and error 0x801c03ea.
• Windows Time service tools and settings — the full W32Time registry reference, stand-alone versus domain-member defaults, and the w32tm command-line parameters.
• Kerberos authentication troubleshooting guidance — the five-minute requirement, KERB_AP_ERR_SKEW under Event ID 4, and the W32Time UDP 123 port requirement.
• Maximum tolerance for computer clock synchronization — the policy location and the documented five-minute defaults.
• Configure W32Time against huge time offset — phase-correction behaviour, the stand-alone 54,000-second default, and why Microsoft advises against 0xFFFFFFFF.
• ADMX_W32Time Policy CSP — the three OMA-URIs, the ADMX Group Policy paths, and the documented parameter defaults.
• w32tm /resync fails with "no time data was available" — exact event text for Time-Service 129 and 134, and the three documented causes.
• Event 142: the time service has stopped advertising — exact event text for 142, 35, 37 and Kernel-General 1.
• Event ID 144, Time Service Advertisement — the source name Microsoft-Windows-Time-Service and the AnnounceFlags check.
• ID tokens in the Microsoft identity platform — the iat, nbf and exp validation requirement.
• Secure Time Seeding: improving time keeping in Windows — the circular dependency, the drained-battery scenario, and the UtilizeSslTimeData value.
• Windows Autopilot troubleshooting FAQ — the Autopilot event channel and Event IDs 171 and 172.
• TimeLanguageSettings Policy CSP — ConfigureTimeZone.
• Windows Time Service event IDs 24, 29 and 38 — the documented two-provider conflict.

Community deep-dive