Before you think I’m going off on a philosophical tangent, let me assure you that I have a point to make, and it is indeed about the importance of time.  More specifically, it’s about the importance of having accurate time – every device being deployed by Windows Autopilot needs to have a “reasonably-accurate” time on it.  And if it doesn’t, bad things can happen.

So how does the time on the device get messed up in the first place?  There are two primary scenarios:

• The real-time clock in the firmware isn’t accurate and the time drifts (maybe seconds an hour) – the longer the device sits around, the more out of sync it gets.  You don’t notice this on a device that’s running Windows and already in use because it will periodically fix itself through a time server, but if the device hasn’t yet been deployed (e.g. it’s been in a box for months) it can continue to drift.
• The battery powering the real-time clock runs out of power, causing the clock to reset to some “very long ago” date and time.  (Remember how PCs had batteries in them just for this purpose?  There are models of laptops made that don’t have a dedicated battery for this, so it’s dependent on the laptop battery.  An interesting way to save a couple of dollars on the design.)

So what problems does this cause?  Most typically, it will cause issues with certificates.  Imagine if the clock on the device is, say, 15 minutes slow.  If it then gets a new certificate from a remote server (one that has the correct time), and that certificate has a “valid from” date that is set to the current date and time, the device will end up with a cert that isn’t yet valid.  Sound far fetched?  It’s not, we’ve actually had support cases where the TPM attestation process failed for that exact reason.  Since that’s a key part of self-deploying and white glove processes, it can cause those to fail.  (You might not notice with other certs, if they aren’t used before time “catches up.”)

We have made some improvements in the next Windows 10 release to automatically sync the time during OOBE, to address this sort of issue.  (We thought this was already done, but obviously not.  It does happen for AD-joined machines when they boot, if a domain controller can be found, but that’s often too late to avoid the issue.)

There are also can be some challenges related to time zones, if by chance the time zone changes (or if the time is adjusted into the currently-configured time zone, especially if the real-time clock on the device was set to a time in a different time zone – you would think that in 2019 PCs would be smart enough to have a real-time clock that used UTC, but no) while the enrollment status page (ESP) is displayed.  When ESP is calculating whether the maximum time has elapsed and the time jumps forward, it can suddenly think that the maximum time has indeed elapsed.  We’ll fix that in the next Windows 10 release too.

We’re in the process of updating the Windows Autopilot known issues list to document a workaround for this:  When the device starts up into OOBE, press Shift-F10 and then force a time sync using these commands:

net start w32time

w32tm /resync /force