Fix Windows Autopilot Failures When the Real-Time Clock Is Off by Several Minutes

If Windows Autopilot keeps failing during pre-provisioning or self-deploying mode and the device clock is clearly wrong, stop rebuilding profiles and stop deleting device records for a minute. Microsoft now documents a separate known issue where Autopilot provisioning can fail because the real-time clock is off by several minutes or more. The visible failure can look like TPM attestation trouble, Enrollment Status Page weirdness, or a generic early OOBE stall, but the root problem is simpler: the device time is too far off for the trust path to hold.

That matters because the affected Autopilot paths rely on time-sensitive cloud checks. If the clock is skewed far enough, the device can fail before you get to the part of the deployment that admins usually think about first.

Quick fix checklist

Use this order before you wipe the device again:

1. Confirm the device clock is actually wrong by several minutes or more.

2. Confirm the failure is happening in an attestation-dependent Autopilot path such as self-deploying mode or pre-provisioning technician flow.

3. Run Microsoft’s documented time-sync fix:

   w32tm /resync /force

4. Recheck whether the device can reach required NTP and TPM attestation endpoints.

5. Pull the Autopilot event log and look for event IDs 171 and 172.

6. Collect an Autopilot CAB before resetting the device.

7. Retest one pilot device after correcting time. Do not fan out to the whole batch yet.

If the clock is wrong because the provisioning VLAN blocks NTP, the same failure usually comes right back on the next device until networking is fixed.

What Microsoft is actually saying

Microsoft’s Learn search result for the current Windows Autopilot known issues page describes the issue like this:

Windows Autopilot device provisioning can fail. These failures might be because of TPM attestation errors or ESP timeouts on devices where the real-time clock is off by a significant amount of time. Run the command w32tm /resync /force to sync the time with the default time server (time.windows.com).

That short paragraph is more useful than it looks.

It tells you four important things:

• Microsoft considers this a real, known Autopilot issue, not just field folklore.
• The failure can surface as TPM attestation errors or ESP timeouts, which is why teams often misclassify it.
• The trigger is not a one-second drift. The device clock has to be off by several minutes or more.
• Microsoft points directly at Windows Time remediation first.

So if you have a machine fresh from storage, a motherboard-replaced device, a kiosk that sat powered off for months, or a batch on an isolated staging network, clock drift belongs near the top of the triage tree.

Why bad device time breaks Autopilot so early

Microsoft’s Windows Autopilot requirements page says self-deploying mode and pre-provisioning rely on TPM attestation and require access to TPM attestation URLs such as *.microsoftaik.azure.net. The same requirements page also says Windows Autopilot needs UDP 123 to the network time source and specifically calls out time.windows.com for NTP sync.

That combination explains the failure pattern.

Autopilot has to establish trust with Microsoft cloud services while the device is still in OOBE. If the local clock is wrong enough, one or more of these checks can fail:

• TPM attestation handshakes
• token validation during Microsoft Entra join
• HTTPS certificate validation to cloud endpoints
• time-sensitive OOBE actions that later show up as ESP delays or failures

This is why the symptom can look inconsistent from one device to the next. One machine might show an attestation-style error. Another might just hang and eventually time out. A third might appear to move forward and then die later in ESP. The shared problem is still the clock.

Which deployment paths are most exposed

This known issue matters most when you are using Autopilot flows that depend on early device trust.

Self-deploying mode

Microsoft’s self-deploying mode documentation says this scenario is designed for kiosks, digital signage, and shared devices. It also requires a physical device, TPM 2.0, and successful device attestation. There is no normal user credential flow to smooth over an early trust failure. If time is wrong, the deployment can fail fast.

Pre-provisioning technician flow

Microsoft’s pre-provisioning documentation says technician flow inherits behavior from self-deploying mode. That is the key detail. Even though the end-user experience later looks more like user-driven Autopilot, the technician phase still depends on the self-deploying trust path. So a skewed clock can break the device before reseal, even when the tenant config is otherwise fine.

Shared staging or bench networks

This is where many enterprise teams get burned. The production user network may have open NTP and normal outbound access, but the imaging room, warehouse, depot, or staging VLAN might not. If that network blocks UDP 123 or forces broken proxy behavior, devices that boot with stale hardware clocks can never repair their own time during OOBE.

Logs and where to check first

1. Autopilot event log

Microsoft’s Autopilot troubleshooting FAQ says to review the event log here:

Application and Services Logs > Microsoft > Windows > ModernDeployment-Diagnostics-Provider > Autopilot

The same FAQ says these event IDs matter for TPM attestation issues:

• 171 — AutopilotManager failed to set TPM identity confirmed. HRESULT=[error code].
• 172 — AutopilotManager failed to set Autopilot profile as available. HRESULT=[error code].

Pull them with PowerShell:

Get-WinEvent -LogName 'Microsoft-Windows-ModernDeployment-Diagnostics-Provider/Autopilot' -MaxEvents 200 |
  Where-Object { $_.Id -in 171,172,807,809,815 } |
  Select-Object TimeCreated, Id, LevelDisplayName, Message |
  Format-List

If 171 and 172 line up with the failure window and the local time is obviously wrong, stay on the clock and attestation branch before you start changing Intune assignments.

2. Device time and time source

Check the current status:

w32tm /query /status
w32tm /query /source
w32tm /query /configuration

What you want to know:

• Is the device synchronized?
• Is it using time.windows.com, a domain hierarchy, or something broken?
• Does the reported time source make sense for the network the device is on?

If the device is workgroup-like during OOBE and cannot reach any valid source, you are not going to fix this by pushing Intune policy later.

3. Collect the Autopilot CAB before reset

Use:

mkdir C:\Temp -Force
Mdmdiagnosticstool.exe -area Autopilot;TPM -cab C:\Temp\autopilot-clock-skew.cab

This gives you evidence you can compare across multiple devices instead of relying on screenshots and memory.

4. Check the cached Autopilot registry state

Microsoft’s FAQ says Autopilot profile settings are stored under:

HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot

This will not prove clock skew by itself, but it helps you confirm the device did receive an Autopilot profile and that you are not mixing a profile-download issue with a time-sync issue.

A practical remediation workflow

Step 1: Prove the clock problem first

Do not assume. Look at the actual device time in OOBE or diagnostics. If the clock is off by several minutes or more, treat that as a first-class incident.

Step 2: Run the Microsoft fix

Microsoft’s published command is:

w32tm /resync /force

If the device corrects time immediately, retry the Autopilot path before changing anything else.

Step 3: Validate NTP reachability on the provisioning network

Microsoft’s Autopilot requirements page says to allow:

• outbound UDP 123
• access to time.windows.com

If your provisioning network blocks those, a one-time manual correction is not enough. The next freshly booted device can land in the same broken state.

Step 4: Validate TPM attestation endpoints too

The same requirements page says self-deploying mode and pre-provisioning need access to TPM attestation URLs, including:

• *.microsoftaik.azure.net
• Intel: https://ekop.intel.com/ekcertservice
• Qualcomm: https://ekcert.spserv.microsoft.com/EKCertificate/GetEKCertificate/v1
• AMD: https://ftpm.amd.com/pki/aia

This matters because some teams fix the clock and still fail on the next step. That does not mean the clock was irrelevant. It means there was more than one blocker.

Step 5: Check hardware and firmware history

If the time keeps drifting badly across reboots, look beyond Windows.

Common field triggers include:

• long-stored devices with stale RTC state
• BIOS resets after repair or motherboard replacement
• weak CMOS battery behavior on older platforms
• firmware that is behind on TPM or clock-related fixes

If one model keeps showing severe drift and others do not, treat it as a model-specific hardware or firmware problem until proven otherwise.

Step 6: Retest one known-failing device

After correcting time and confirming network access, retest one device from the failing batch.

Watch what changes:

• If Autopilot proceeds, the clock issue was your primary blocker.
• If the error changes to another known code, you cleared the first blocker and exposed the next one.
• If nothing changes and the clock drifts back again, go deeper on NTP reachability or hardware clock integrity.

That is a much cleaner path than reimaging ten devices against the same broken staging network.

Commands worth keeping in your runbook

Check Windows Time status

w32tm /query /status
w32tm /query /source
w32tm /query /configuration

Force rediscovery and resync

w32tm /resync /force
w32tm /resync /rediscover

Pull Autopilot evidence

Get-WinEvent -LogName 'Microsoft-Windows-ModernDeployment-Diagnostics-Provider/Autopilot' -MaxEvents 200 |
  Select-Object TimeCreated, Id, Message

Capture TPM state

Get-Tpm | Format-List *
tpmtool getdeviceinformation

Caveats and limitations

A few limits matter here.

First, this known issue is not a catch-all explanation for every TPM attestation failure. Microsoft also documents distinct Autopilot failures for outdated Windows builds, TPM vulnerability branches, multiple MDM configurations, deleted Entra device objects, and unsupported deployment paths. Wrong time is one branch, not the whole tree.

Second, if your environment uses domain-based time hierarchy later in the deployment, that does not help you during early OOBE if the device cannot reach a valid time source at the moment Autopilot needs it.

Third, fixing the time on one device does not validate your network design. If the provisioning segment still blocks NTP or attestation endpoints, the outage can come back on the next batch.

Prevention

If you want to stop this from becoming a repeating bench problem, do these four things:

1. Validate UDP 123 and time.windows.com from the provisioning network before rollout.
2. Validate the TPM attestation endpoints for Intel, AMD, Qualcomm, and Microsoft cloud trust.
3. Add w32tm /query /status and w32tm /query /source to your Autopilot triage checklist.
4. Track model-specific drift or BIOS-reset patterns instead of treating every failure as an Intune problem.

Bottom line

When Microsoft says Windows Autopilot can fail because the real-time clock is off by several minutes or more, take that literally.

If you see early Autopilot failures that smell like TPM attestation or unexplained ESP timeout behavior, check the clock before you tear apart profiles, connectors, or app assignments. Run w32tm /resync /force, confirm NTP and attestation reachability, pull event IDs 171/172, and retest one device.

That sequence turns a vague Autopilot outage into a narrow trust-path investigation. In most enterprise rollout windows, that is the difference between a fast fix and a long night.