All computers deployed via AutoPilot, AutoPilot Reset, or manual reset (settings, recovery, reset this PC) are deployed with the computer time zone being set to PST (Pacific Standard Time). We are working with national and international customers that require AutoPilot computers being shipped globally but we are trying to deliver the “Zero Touch” Out of the Box experience to the end user. In order to maximize security our standard AutoPilot deployment profile sets “User Account Type = Standard”. Therefore when a computer is delivered, the recipient is unable to update their time or time zone without contacting support. Additionally, if we try to assist the user with traditional web tools such as “MS Quick Assist” or 3rd Party tools, such as ConnectWise, Screen Connect, or TeamViewer the connection is established with the user’s credentials. The moment the change is attempted MS User Access Control (UAC) kicks in and we are unable to see or assist with the dialogue box to enter alternative administrative credentials. Our position is that we should be reducing software on computers to reduce the attack surface. We should not have any administrative accounts on a local computer to reduce the attack surface.
We need to be able to set the clock automatically in Intune. We also need it to be able to be changed/updated for travelling users in a Zero Touch manner.
How much revenue/pipeline for your company is this impacting?
This issue isn’t about revenue generation but is about reducing support expense, loss of productivity time, and time inaccuracies effect almost every aspect of computing from logs to file time stamps. Everyone in the organization, except those individuals in the Pacific Time Zone, are effected. Even those people in the PST are effected when they travel to any other time zone.
How many users total do you anticipate this impacts?
Every one in the company is affected. Since we support multiple companies, I can safely say that this effects all users in all companies that use Intune deployments at some point.
Is this blocking the use of autopilot completely?
No, the inaccurate time stamp does not block the user of AP completely but unless corrected the issue has a severe negative impact on users.
The workarounds that I have attempted so far are described here:
I uncovered an article by Microsoft MVP, Peter van der Woude, from the Netherlands. He developed a Custom Device Configuration Profile using and OMA-URI setting that can set the time zone for a user at the time of deployment. This saves the user from having to set their Time Zone. However, it is a one-time setting and the user cannot change their TZ without admin support. If traveling the user would need to manually change the setting to a new local time and again require admin support.
https://www.petervanderwoude.nl/post/configure-time-zones-via-windows-10-mdm/comment-page-1/?unappro...
(Note about this fix is that when I opened a ticket with MS support, I was offered this as solution as a work around.)
Another work-around suggestion is to create and send a PowerShell script to the computer (see below)
Set-TimeZone -Id “Central Standard Time”
Start-Service W32Time
Restart-Service W32Time
Finally -
Nickolaj Andersen from MSEndPointMgr.com developed PowerShell scripting using Windows 10 location services and Azure Maps that can get Time Zones working but would also incur Azure charges. The author notes that it currently works but if Windows code changes in anyway, it scripting can break and there would be no one to support the problem at that point.
https://msendpointmgr.com/2020/05/20/automatically-set-time-zone-for-devices-provisioned-using-windo...
Ultimately, we would like to see a native solution in Intune which just works. Any help getting us toward that solution would be greatly appreciated!
