I recently had an issue with an AVD client, where the time zone on AVD hosts randomly changed to the US Central time zone, even though the Time Zone was configured to MST with Intune. Adding a scheduled task to set the time zone at user login still didn’t completely resolve the issue. Users still randomly reported the time zone being off. I even witnessed this happen in real time while connected. So, we needed to start digging into the cause. I was surprised I hadn’t encountered this in 15+ years of working in IT, but there’s a first time for everything.
Initial troubleshooting started in the system event log. We can see event ID 22 in the screenshot below, indicating a time zone change. In this case, the time zone was changed back to the desired time (Mountain Standard Time) with a time bias of 420. The Time bias is the difference in minutes from UTC 0. A list of the time zone biases is also below:
UTC-12:00: -720 minutes
UTC-11:00: -660 minutes
UTC-10:00: -600 minutes (Hawaii-Aleutian Standard Time)
UTC-09:00: -540 minutes (Alaska Standard Time)
UTC-08:00: -480 minutes (Pacific Standard Time)
UTC-07:00: -420 minutes (Mountain Standard Time)
UTC-06:00: -360 minutes (Central Standard Time)
UTC-05:00: -300 minutes (Eastern Standard Time)
UTC-04:00: -240 minutes (Atlantic Standard Time)
UTC-03:00: -180 minutes (Argentina Standard Time)
UTC-02:00: -120 minutes
UTC-01:00: -60 minutes
UTC+00:00: 0 minutes (Greenwich Mean Time)
UTC+01:00: 60 minutes (Central European Time)
UTC+02:00: 120 minutes (Eastern European Time)
UTC+03:00: 180 minutes (Moscow Standard Time)
UTC+04:00: 240 minutes (Gulf Standard Time)
UTC+05:00: 300 minutes (Pakistan Standard Time)
UTC+06:00: 360 minutes (Bangladesh Standard Time)
UTC+07:00: 420 minutes (Indochina Time)
UTC+08:00: 480 minutes (China Standard Time)
UTC+09:00: 540 minutes (Japan Standard Time)
UTC+10:00: 600 minutes (Australian Eastern Standard Time)
UTC+11:00: 660 minutes (Solomon Islands Time)
UTC+12:00: 720 minutes (New Zealand Standard Time)
We can see the name of the user who initiated the time change in the event. This is strange because this is not an admin user and the time zone is being set by policy, so they should not be allowed to change it. We also see Event 24 right after Event 22, confirming that the time zone was refreshed to US Central Time:
After contacting that user, they insisted they did not change the time zone of the computer and I confirmed their account did not have permission to change the time zone in Windows. However, some more digging led to event ID 1, indicating that the system time zone was changed by Outlook and also showed the process ID for the Outlook instance:
If we look up that process ID, it leads us to the remote desktop session number, which maps back to the same user identified in the event logs who insisted they did not change the time zone:
After contacting the user again to review this, it turns out that they are a remote user in US Central time zone. Each morning after signing in and opening Outlook, they changed the calendar time zone in Outlook to reflect their native time zone. Surprisingly, this changes the operating system time zone as well. So, although we couldn’t go into the Time settings and change the time zone within Windows, standard users can override a time zone policy by changing their time zone under the calendar settings in Outlook. There is no way to prevent this in Outlook Classic. The recommended course of action is educating the users to add a secondary time zone:
If you were wondering – this behavior is only experienced when using Outlook Classic. New Outlook does not change the system time zone if the calendar time zone is modified.