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
Categories: Windows Autopilot
Many thanks for this article as it has confirmed several issues we are seeing at multiple customers. The command by itself isn’t helpful as the Windows Time Service isn’t running at that point in the build, it needs to be started before the command can be used. Another complicating issue is most corporate enterprises block unauthenticated access to the time service URLs. The ‘best’ answer we have seen so far is to run ‘start ms-settings:’ and manually set the time and timezone then allow the build process to continue. It would be nice to have a ‘fix’ for this that works in controlled corporate enterprises.
I updated the instructions to include starting the service. Since the device needs to sync the time before it is managed, allowing access to time.windows.com is the best option for where to get the time, and we do already document that requirement. The time zone problem is a little more challenging.
we have built a custom MSI-Package which will be installed in ESP Device Phase. It start the service, sets a NTP Server and triggers a sync. Then the machine time is correct and all other related features (SCEP, TPM) are going to work smooth.
There is a sequencing issue here, as TPM attestation would occur before you could install the MSI. So it might fix some issues, but probably not all of them.
Since 1903 MS changed the default value for location service (confirmed by MS). It is disabled by default. On 1809 it was enabled by default and the issue didn’t exist I would say. That causes the an issue where a wrong timezone is set and can’t be changed automatically. Maybe this has also an influence on this.
Is this in some way related to that the time zone isn’t set by your regional settings and/or the previous time zone setting on the machine after an autopilot reset? It always goes to Redmond time
No, but that is something we should probably fix 🙂