This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
We notice that every time after Windows Autopilot OOBE setup procedure, Windows has a nasty habit of offsetting the time to our regional time zone. Except, the system clock was already in tune with our time zone. So the clock advances 8 or 15 hours ahead for no good reason.
That's a massive annoyance since standard users don't have the permission to change date and time.
But, it's already set to synchronise with time.windows.com, yes? Except, the Windows Time service doesn't run, and the [Sync now] button only ever results in "Time synchronisation failed" errors.
Can't find anything within Intune (administrative templates, device restrictions) that can allow users a chance to correct this on their own.
What's supposed to be the proper method to correct this misconfiguration?
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(22.400000000000002, 6%, 12%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EEZ%3C/text%3E%3C/svg%3E)
why does this work with initial autopilot setup or local Reset and NOT after remote Autopilot Reset?
For now a workaround is for users to boot into laptop BIOS and correct the date/time from there.
But surely, there're some areas of Windows (+ Intune) that need to be addressed to fix this at the OS level.
UPDATE
Also, looks like the jump to 8 or 15 hours depends on which keyboard layout (US or UK) was chosen at OOBE setup. I think that is highly unncessary.
In my case the Bios is correct. I feel like this is a big bug
Have been trying to fiddle with the Policy CSP
./Vendor/MSFT/Policy/Config/UserRights/ChangeSystemTime
set with payload
<![CDATA[AdministratorsLOCAL SERVICEUsers]]>
Despite some errors in Intune, I see the target OSes did have their local group policies adjusted for [Change the system time]. However standard users still cannot adjust the clock date & time. I don't know what else is missing.
https://github.com/MicrosoftDocs/windows-itpro-docs/issues/6367
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(304, 88%, 39%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESC%3C/text%3E%3C/svg%3E)
Anybody has any more ideas?
Or do I really have to use a script to do "modern web management"?
But even with script (running as System), it seems not possible!
C:\Windows>w32tm /resync /rediscover
Sending resync command to local computer
The following error occurred: Access is denied. (0x80070005)
I can get it to work running as TrustedInstaller, but at this point we are getting to really silly situation!
Have not yet tested, but was told that scheduled task does work
schtasks /Create /F /RU SYSTEM /RL HIGHEST /SC HOURLY /TN SysTimeResync /TR "cmd /c w32tm /resync"
schtasks /Run /I /TN SysTimeResync
Or one can use http://www.timesynctool.com/
Download: Installer: NetTimeSetup-314.exe (Version 3.14
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(284.8, 67%, 37%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EGA%3C/text%3E%3C/svg%3E)
Now with proactive remediations, you could check to make sure the service is started, if not, run a remediation script to start it. Will also give you some historical data over a 30 day window to see how things look for your fleet.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(297.6, 72%, 38%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EAD%3C/text%3E%3C/svg%3E)
This was a great suggestion as I was having the same problem.
Created some detection and remediation scripts to start the W32Time service and run "w32tm /resync"
Hope this helps others that run into the same problem.
https://github.com/oniled/personal/blob/main/DetectW32TimeService.ps1
https://github.com/oniled/personal/blob/main/RemediateW32TimeService.ps1
We had somewhat of similar issues with our time sync in our corporate sites. We noticed deploying intune (Azure AD connected) devices outside corporate firewalls had the right time while devices inside the network didn't. We were stumped for a bit as devices were previously connected to a local domain controller that set the times of AD connected devices.
Just a suggestion that you should check if UDP Port 123 is open on your network. Once we allowed the port to communicate with time.windows.com, our time synchronized at all of our corporate sites.