Forum Discussion
TimeZone Issues Windows 365 Cloud PC
Anyone having issues with time settings in Teams running on a Windows 365 Cloud PC using anything other than the Microsoft Remote Desktop Application? From a Chromebook with the correct time zone set, the Cloud PC reverts to a GMT -12 setting every time I reconnect. I have tried setting the time zone via GPO and Intune, but nothing "sticks" (also have users with MAC clients experiencing the same issue).
- And the plot thickens. From a Browser connection to my Cloud PC on a Chrome device, the time zone looks and acts "right" but, without signing out, I reconnected to my Cloud PC using the Remote Desktop App on the same Chrome device and the time zone is wrong again...
JimK1 I have the same problem. However, I only use the Remote Desktop. The location of the Windows 365 is Dublin and so the time zone is set GMT 00:00 but I am sitting in GMT 01:00 . When I manually change the time zone on the Windows 365 PC, it always overwrites it back to GMT 00:00. Microsoft support is not really responding to my probelm....
- I opened a ticket with Microsoft and they indicated this is happening because "Location" redirect isn't supported on Android or MAC. I asked for an explanation of why the time is correct via the web client but not the remote desktop app and am awaiting a response (will post here when I get something back). They did send me a powershell command to run on the cloud PC that will set the timezone, but as you noticed, it always changes back to GMT 00:00 so it would need to be run every time a connection is made to a cloud PC or as a scheduled task (unless I'm missing something) which is something I don't really want to do.
RajKanth, sadly, my solution is to use Chrome Remote Desktop. I lose sound and some screen resolution options, but it does not change the time when I connect, which is more important to me than what I give up.
- Any response from MS on this? I'm having the same issue. Teams time zone is GMT even though clock is right. I have to go into windows and change the time zone, save it, then go back in and change the time zone back again. Then Teams picks up the correct time. Until I log out, then it goes right back to GMT again. I am using Remote Desktop app on MAC to connect. I never had this issue using Remote Desktop app on MAC to connect to a local VM and run Teams. It only seems to be happening with 365 cloud PC (not sure if Enterprise Edition is the issue though).
- Yes, according to the MS tech the issue is due to the inability to support the timezone redirect setting from Mac and Android devices via the desktop app, if you connect using the web client it should work but then you loose other functionality... I was hoping to replace the majority of our desktop computers with lower cost Chrome devices, but it appears that isn't going to be an option until (if/when) MS can figure this little issue out but that doesn't seem to be a concern for them right now.
NirolfMicrosoft
JustinA1125 The time zone issue should be resolved with the latest version of the RDP client app for Mac devices. Latest version is 10.7.0 (1933). Please check and give us feedback. Thank you.
Nirolf - I am running Mac client 10.7.6 (1972) and have this problem. The Windows 365 PC resets to PST everytime I connect and I want it to run in EST.
- Is anyone still having this issue? My timezone keeps reverting after I changed it. Just checking if there has been some sort of fix.
JTurnCap15 - MAC devices seem to be good now but Android devices are still not working...
- It is currently supported in Windows and MAC clients only. Android client the time zone redirection is still not supported.
- I have an odd one: The time zone is set correctly (PST) and so is the time, and it shows properly (Windows clock, Outlook, etc.), but when I force an Intune sync via Access Work or School > AAD connection Info > Sync, the timestamp of the sync shows what looks to be UTC -8. I.e. Windows shows 3/28/22 at 5:23PM PST and the Intune sync shows 3/29/22 12:23 AM.
Anyone else experiencing this?
- This is a bug in the RDP client that is resolved in the latest Mac OS RDP client 10.9.4 (2162)
Update of the client fixes the issue.
