First things first…  Let me say I LOVE WINDOWS AUTOPILOT!!  It’s an awesome way for organisations to on-board Windows 10 devices in this new Modern Workplace world.  But while the technology has been ground-breaking for Window by bringing that user driven on-boarding experience that people are used to with iOS and Android, it has not been without its problems.

Recently, I’ve had an issue when implementing this solution and it’s taken some serious troubleshooting, multiple service calls and some rather stressful times.

I want to state here that while I detail this experience originally from a client site, nothing in this post is from that site and the issue has been replicated in and all screenshots taken from my lab tenant.

The root cause of the problem traces back to July 2019.  I’d just started with this client, and I discovered that while on-boarding a brand new Windows 10 device, selecting the time zone in the OOBE (in this case New Zealand), everything worked as expected.  But I also wanted to test re-provisioning the device just to ensure the full life-cycle loop is closed.

So, after the first on-boarding was successful, I jumped into Intune to do a device wipe.  Everything was going to plan until the device had logged on.  The clock was out… WAY out.

On further investigation, I found that the device was set to Pacific Standard Time (the default Windows time zone).  Silly me, maybe I forgot to select New Zealand on the OOBE, so off I went again to reset the device.  This time I made sure I selected New Zealand and once again on device logon, the clock was way out and the device time zone was set to Pacific Standard Time.

So one service call to Microsoft later, a fix was provided with a PowerShell script setting the time zone to New Zealand.

Note: The CSP option wasn’t considered as this only works on Windows 10 v1903 and above and the majority of devices at the time were Windows 10 v1809.

Fast forward to January 2020 and all of a sudden, devices being on-boarded started timing out during the Device Setup phase on the Enrollment Status Page.

It always seemed to be when Office 365 Pro Plus was being installed.  Upon further testing, we started to get some inconsistent results so I raised a ticket with Microsoft Support.

Some devices worked at first and then failed when running through the test again.  Some ended up with Office installing, while failing on other apps (There was A LOT of testing done to rule out possible issues).  Just when I though I was on top of the problem and had a possible fix, something else would change.

It was starting to drive me mad, and there was a potential loss of faith in Windows Autopilot as a solution.  I gathered data from these multiple tests and tried to establish some patterns.

Some things I noted:

It appeared to only happen during the Device Setup phase, specifically during the App installs.  I started to exclude all apps and the on-boarding was successful, so I started to add apps back in.  The results were promising, until Office 365 was added back in.

Maybe it was this current version of office, after all, there was a known issue with a timeout issue and the Enrollment Status Page in versions of Windows earlier that v1903.  As this issue started occurring in January 2020, I decided to change the Office 365 deployment from being the “Latest version” to a version prior to January 2020.

Unfortunately,  this did not resolve any of the problems.

One pattern that became noticeable was devices that were new, or had been removed from Azure Active Directory, Intune and reset using a Windows 10 ISO (not an Intune reset) did not have this issue.

It was an email from the MS engineer who had been escalated to this call who had a number of suggestions, but there was a small section of his email that pointed out that he had noticed a time change in the logs during the process.

This was my eureka moment!!

It was then I remembered the call from July 2019 while adding in the pattern of this issue only happening to devices being reset.  I decided to disable the PowerShell time zone script and reset a test device.

The result?

Well the first on-boarding on an Intune wiped device went through with zero issues, well, apart from the time zone being set to Pacific Standard Time.  This was good, but I needed to make sure that this result was consistent, so I Intune wiped the device a few more times, with each time resulting in a successful on-boarding.

This was indeed the root cause of the problem.

This however did not solve the issue of an Intune wiped device having an incorrect time zone set, and I could not provide a solution where the user had to manually change this.

The solution was to re-enable the time zone PowerShell script, but have it run using the logged on credentials meaning this would sill run in the Enrollment Status Page, but just in the Account Setup phase rather than the Device Setup phase.

This worked!  I haven’t tried the CSP option yet, but assume if it’s deployed to either “All Users” or a group containing user accounts, it should also have the same result

Ideally, it would be great if Microsoft could fix Windows/Intune so the region selected by the user in the OOBE is honored when on-boarding an Intune wiped device using Windows Autopilot.  I can also see my work around being a bit more complex to implement in an environment that spans multiple time zones adding an extra layer of administration by ensuring users are in a group that is specific to their time zone.

I have done a Uservoice here for this issue, please feel free to give it a vote or three

 

 

P.