Table of Contents
Managing Azure AD User Country and Regional Settings
A question arose about why Exchange Online doesn’t synchronize country settings from Azure AD user accounts, leading to a situation where an Azure AD user account and its mailbox might have inconsistent values. Here’s an example where the Get-MgUser and Get-Recipient cmdlets report different country values for a user account:
Get-MgUser -UserId Sean.Landy@Office365itpros.com | Format-Table country, usagelocation Country UsageLocation ------- ------------- Austria FR Get-Recipient -Identity Sean.Landy@Office365itpros.com | Select-Object country* CountryOrRegion --------------- France
The technical reason for the apparent inconsistency is simple: Get-MgUser reads data for a user account from Azure AD while Get-Recipient reads information about a mailbox from EXODS, the Exchange Online directory. We’re dealing with two different objects stored in two different directories.
EXODS exists to manage mail-specific properties for mail-enabled objects, like mailboxes. EXODS also manages Exchange objects that aren’t in Azure AD such as public folders and dynamic distribution lists.
Dual Write Between Azure AD and EXODS
To ensure consistency across the two directories, Azure AD and EXODS use a dual-write process. In other words, when an application attempts to update an object, the write operation must succeed in both directories before Azure AD and EXODS commit the change.
However, this doesn’t happen for every property for every object in the two directories. Although the mailbox CountryOrRegion property receives the same value as the user account’s Country property when Exchange Online creates a new mailbox, synchronization doesn’t follow for further updates. Azure AD and EXODS synchronize updates to other elements of address information like the street address, city, and province made in either directory, but ignore changes to the Country property in Azure AD or the CountryOrRegion property in EXODS. Perhaps the reason is that the two properties have different names and purposes: One is specific to a country while the other can store a country or region name. In fact, EXODS doesn’t store a Country property for mailboxes.
All of which means that it is possible to update an Azure AD account with a new value for the country property without any effect on EXODS. For example, this command updates Azure AD without doing anything to EXODS:
Update-MgUser -UserId Sean.Landy@Office365itpros.com -Country "Ireland"
Likewise, the same is true of an update to EXODS with the Set-User cmdlet. Azure AD ignores this update:
Set-User -Identity Sean.Landy@Office365itpros.com -CountryOrRegion "United States"
In practical terms, the inconsistency might be irritating but it isn’t important. Azure AD is the directory of record for Microsoft 365 and applications should go to it for information about user accounts. The information stored in EXODS about mailbox owners is for informational purposes only. If you want everything to match, then you must create a mechanism (a PowerShell script most likely) to synchronize the properties you want to be consistent.
Azure AD Account Usage Location
Another potential inconsistency is the usage location assigned to an Azure AD account. In the example above, the usage location is FR (France) but the Country property says Austria. The usage location is where Microsoft delivers the service to the account and it’s important that it’s correct because Microsoft cannot deliver some elements of Microsoft 365 (mostly to do with encryption) in certain countries.
Life being what it is, the usage location set when creating an account can change. For instance, a user might relocate to work in an office in another country for a period. There’s no requirement to update the usage location for the account because this should reflect the user’s normal location. In addition, an account’s usage location isn’t associated with the tenant home location. The location (or datacenter region) for a tenant establishes where Microsoft delivers services to the tenant from and where tenant data resides. This can be a country-level datacenter (like France, Switzerland, or South Africa), or a regional datacenter (like the U.S. or Western Europe). Tenant accounts located in countries outside a datacenter location can access services delivered to the tenant. Multi-geo tenants are available should local data residency be necessary.
Mailbox Regional Settings
When you create a new Microsoft 365 account and license the account for Exchange Online, the mailbox does not inherit regional properties from the country or service location defined for the Azure AD account. This is deliberate because regional properties are personal to the user and define the language used to interact with the mailbox, its time zone, and the preferred date format. Different groups of people in the same country often use different regional settings. Examples include Welsh speakers in the United Kingdom and Flemish speakers in Belgium.
OWA applies default regional properties based on the tenant location the first time the mailbox owner signs in and creates a set of default folders. For example, mailboxes that use the English language have an Inbox folder, while mailboxes configured for French use Boîte de réception. Users can update regional settings for OWA through Outlook settings. (Figure 1). If they change the selected language, they have the option to rename the default folders.
Administrators can run the Set-MailboxRegionalConfiguration cmdlet to change the regional settings for a mailbox. In this example, the mailbox language, time zone, and date and time formats match the settings for a Dutch user working in the Netherlands. Notice the use of the LocalizeDefaultFolderName parameter, set to $True to force Exchange Online to create default folder names in Dutch for the mailbox:
Set-MailboxRegionalConfiguration –Identity 'Rob Young' –Language nl-NL –TimeZone 'W. Europe Standard Time' –DateFormat ‘d-M-yyyy’–TimeFormat 'HH:mm' –LocalizeDefaultFolderName:$True
Apart from the language, the time zone is the most important setting because it’s used by Microsoft 365 applications. For example, Teams displays the local time zone for other users when showing their details in profile cards. If your organization scripts the creation of new accounts, it’s a good idea to make sure that the code includes the configuration of an appropriate time zone setting for the mailbox.
Reporting Azure AD User Country and Regional Settings
It’s easy to audit the language settings of Azure AD accounts and mailboxes. Here’s some code to show how:
$Report = [System.Collections.Generic.List[Object]]::new()
[array]$Users = Get-MgUser -Filter "assignedLicenses/`$count ne 0 and userType eq 'Member'" -ConsistencyLevel eventual -CountVariable Records -All
ForEach ($User in $Users) {
Write-Host ("Processing account {0}" -f $User.DisplayName)
$RegionalSettings = $Null
$RegionalSettings = Get-MailboxRegionalConfiguration -Identity $User.UserPrincipalName -ErrorAction SilentlyContinue
$CountryOrRegion = (Get-User -Identity $User.UserPrincipalName -ErrorAction SilentlyContinue) | Select-Object -ExpandProperty CountryOrRegion
If ($RegionalSettings) {
$ReportLine = [PSCustomObject]@{
User = $User.UserPrincipalName
DisplayName = $User.DisplayName
Country = $User.Country
"Preferred Language" = $User.PreferredLanguage
"Usage Location" = $User.UsageLocation
"Country or region" = $CountryOrRegion
Language = $RegionalSettings.Language.DisplayName
DateFormat = $RegionalSettings.DateFormat
TimeFormat = $RegionalSettings.TimeFormat
TimeZone = $RegionalSettings.TimeZone }
$Report.Add($ReportLine) }
}
Figure 2 shows the output. This data is from a test tenant, but it illustrates how easy it is for inconsistencies to occur across the range of country settings available for accounts and mailboxes.
The most important element to get correct is the time zone because it affects the user experience. It would be easy to make sure that Country (Azure AD) and CountryOrRegion (EXODS) contain the same value, but aside from configuring values during account creation, you should leave regional settings alone as they’re a matter of personal choice.
Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.
There are some fun features here about how Microsoft sets-up country localization. The big one is when you create your tenant – this setting is still locked forever as far as I know – which affects notifications from SharePoint (our US-based users in particular love the alerts in Swedish!)
The other feature is the default names used for mailbox items – for example the calendar. Some of our users setup their Outlook mailbox using their local language. Running powershell MailboxFolderPermission then fails for certain users when using “calendar” – instead I need to then try “kalender”.
Another interesting localization feature is that at least one French localization produces dramatically different email replies – only the date was included instead of To, From, CC and Subject fields.
Localization is not easy, especially in a product that’s continually changing. I worked on the original ALL-IN-1 (Office product) Basic European Version in the mid-1980s and getting everything translated and to appear in the right place at the right time was a real challenge. Given the increase in functionality, lines of code, and language coverage, I imagine that I18N (internationalization) problems crop up all the time. The good thing is that at least there’s a focus on I18N across the board now.
Im trying to update the Country code for a AD synched user and it still shows the incorrect country on O365 Outlook Contact info
Maybe synchronization doesn’t copy the country code across? (I don’t have a hybrid environment, so I cannot test).