Mailboxes in Exchange Online have two timezones; one in regional settings and the other in working hours. These are both set to Pacific Standard Time by default, regardless of where in the world the mailbox is created or what tenant or Exchange regional settings are in place. This behaviour is by design, according to Microsoft support.
The first time a mailbox is accessed by a user, these settings are determined based on their location and the defaults are changed automatically (most of the time). Where this does not occur, such as in the case of a resource mailbox, these defaults are never replaced. This leads to problems such as where a room is set to deny bookings outside of working hours but instead denies them within working hours.
Light on detail
As far as I can tell none of this is actually documented, or at least not in one place; this is mostly based on what I’ve discovered in the course of a support case.
It must surely be a common complaint since MS Docs has an article entitled ‘Time zone settings are incorrect or missing for multiple mailboxes in Microsoft 365’, yet this fails to mention that the problem occurs by design and therefore the workaround must be continually repeated. It also neglects any reference to working hours. I know this because it was the first resource I came across when I encountered this problem and I was stumped that changing the regional settings alone didn’t fix the problem.
Demo
This is what I went through on a support ticket to show the issue.
Firstly, I checked that my tenant region settings were correct (it’s in Australia):
Get-OrganizationConfig | Select DefaultMailboxRegion
DefaultMailboxRegion
--------------------
AUS
Then I created a new mailbox with default settings and checked it to see the PST default:
Get-MailboxCalendarConfiguration -Identity [email protected]
Identity WorkDays WorkingHoursStartTime WorkingHoursEndTime WorkingHoursTimeZone
-------- -------- --------------------- ------------------- --------------------
Test Weekdays08:00:00 17:00:00 Pacific Standard Time
Then I signed into Outlook from my device (located in UK) and checked again to see my local timezone, different from both my tenant default and the created PST default:
Get-MailboxRegionalConfiguration -Identity [email protected]
Identity Language DateFormat TimeFormat TimeZone
-------- -------- ---------- ---------- --------
8ae0d1aa-bed1... en-GB dd/MM/yyyy HH:mm GMT Standard Time
Get-MailboxCalendarConfiguration -Identity [email protected]
Identity WorkDays WorkingHoursStartTime WorkingHoursEndTime WorkingHoursTimeZone
-------- -------- --------------------- ------------------- --------------------
8ae0d1aa-bed1... Weekdays 08:00:00 17:00:00 GMT Standard Time
Back in the old days we’d be greeted with a message like this when logging in for the first time:
It seems that Exchange is now getting those language and regional settings directly from the browser without user interaction, which is great – apart from still needing a user in the equation.
To correct the issue on a non-user-facing mailbox, both timezones must be separately set by Powershell. Changing the region setting does not affect the working hours setting.
Where to from here?
Last year’s Ignite previewed the release of a revamped working hours which hasn’t yet materialised in my tenant but since its focus seems to be on the user experience, I doubt it will change anything here.
Until we have a better fix, the workaround is remembering to run the Powershell commands to update both timezones when creating any shared or resource mailbox. Additionally, a couple of times a year I’ll do a sweep to include all mailboxes in case any were missed:
Get-Mailbox -ResultSize unlimited | Set-MailboxRegionalConfiguration -TimeZone "W. Australia Standard Time"
Get-Mailbox -ResultSize unlimited | Set-MailboxCalendarConfiguration -WorkingHoursTimeZone "W. Australia Standard Time"
To find alternative timezones use this bit of Powershell from the command reference linked above:
$TimeZone = Get-ChildItem "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Time zones" | foreach {Get-ItemProperty $_.PSPath}; $TimeZone | sort Display | Format-Table -Auto PSChildname,Display
I have requested a change to the documentation and have also submitted a feature request to at least put this on the radar for future development. If you have found this post because you’re in a similar predicament, please add a vote.
Update 26/05/23 I got an email notification that Microsoft closed my issue on the GitHub repository for Office Docs and all links to it are dead since they have also removed Issues from public view entirely. It’s disappointing that they have not only refused to acknowledge this issue but also removed the ability of customers to comment directly on their documentation in a way that’s tracked and responded to (as opposed to just leaving feedback on an article which is like shouting into the void).
Update 21/02/24
I noticed that the new Outlook client has a welcome dialog that explicitly states it’s taking regional settings from the client and updating the mailbox. No change to non-user-attached mailboxes as yet.
