Browser Settings, OS-Settings, Preferred-Language, Regional Settings, …
There are so many settings, values and components which are responsible for the user interfaces and notifications. Wrong settings can lead to a bad user experience, licensing issues or incomprehensible system messages. In this globalized and fast world it’s more important than ever that everybody is able to receive the information he needs in a language he understands. Application menus and administrative messages in foreign language can also lead to more support calls etc..
One could think that this is a very profane topic, but it’s anything but easy to understand all the different correlations.
In this blog article I want to describe the settings and values and the impact of them on different Microsoft 365 Services. Mainly I will describe the impact on Exchange, Teams and SharePoint. The data location is, especially in Multi Region Tenants, also very important. But I will focus on the user experience here.
I do not claim to have described everything completely. While writing it I recognized more and more that it’s a moloch. Maybe this is the reason why I didn’t find other articles which try to explain the whole story. But I will update the blog every time I’ve found out something new.
A hybrid Identity scenario with synced identities brings additional complexity in this inconspicuous topic. I will also describe which values are relevant here.
While requesting your tenant you’ve been asked where you’re located. The field is prefilled. Based on the settings you’ve configured in your browsers privacy setting it will be based on the region where you started the tenant registration page. Choose it wisely! You will not be able to change this „root“ setting afterwards.
This decision will define the primary usage location off all your Office 365 Services and Data. The Region can have influence on the feature set and is especially relevant for regulated organizations with regard to compliance etc.
Furthermore this decision defines your Preferred Language.
Tenant Preferred Language: The Preferred Language Setting in the Tenant Organization Information
( https://admin.microsoft.com/AdminPortal/Home#/Settings/OrganizationProfile > Organizations Information )
will pretend the default usage language for all new cloud users. Once you’ve configured your Tenant you can switch the default preferred language to a small subset of languages Microsoft thinks that could make sense for you, but you can’t e.g. switch from German to Swedish.
However, if you have to change the Language Settings here afterwards, to a language that’s not available in you Region, you have to create a new Tenant.
Azure AD User Attributes:
UsageLocation: Similar to the Tenant Settings, you have to choose a Region when you create a new cloud user. This mandatory setting is primarily relevant for the license and feature set of the user.
You can change this setting afterwards via GUI or using the powershell command
Set-AzureADUser -Identity A.User@yourtenant.onmicrosoft.com -UsageLocation DE
The UsageLocation Values have to be entered in the ISO 3166-1 Alpha 2 format: https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2
It might happen that you’ve got it done somehow to create a Azure AD Account without a region. If you’re using group based licensing, the users UsageLocation is used, for accounts without configured UsageLocation, the usage location of the Tenant which will be pre-assumed.
PreferredLanguage: If you’re traveling around and use foreign workstations to login you might have recognized that the Microsoft 365 Portal Page welcomes you in the language of the region which is set your Browser or OS. When you login, the language changes to the language which is defined for your user in the Azure AD Attribute PreferredLanguage. If this optional Attribute has no value the Preferred Language of the tenant is chosen.
The Preferred Language is the value which most of the M365 Services use to display the information in the respecting language. The known Services are:
- Microsoft 365 Portal (portal.office.com)
- Office Web Apps (Word, Excel,… opened from the browser)
- OneNote Web App
- SharePoint (incl. OneDrive)
These services doesn’t make use of the PreferredLanguage Attribute:
- Exchange Mailbox
The PreferredLanguage Attribute is mainly used by SharePoint Online to define the language for the User. It seems that all Services that were not build on the base of SPO are not using the Attribute.
Mailbox Regional Configuration: Exchange makes its own thing which can also be very confusing if you’re not used to it. You have the Mailbox Regional Configuration in which you define the mailbox language, a Time Format and the Time Zone.
Tricky is that these values were defined at the first login of the user by the client language. So, if you’re using a Outlook Client which is configured for German, the Language will be set to German, if your first login to the mailbox is an passive one, like using the calendar in Teams, then the Language from the Teams client is used. It happens very often that the language, TimeZone and TimeFormat here is not the language the user expects. But especially in the mailbox, the language and time settings are relevant.
The calendar is using the Time-Settings and the default Outlook Folders like Inbox, Calendar etc. are named in the Language from the first client login.
You can meanwhile easily reset the folder names and regional settings using set-mailboxregionalconfiguration.
Active Directory User Attributes:
If you’re using a hybrid identity environment, the OnPrem Active Directory is the leading one. So you have to set the Attributes for synced Identities in youe OnPrem AD.
Usage Location: As stated before the usage Location attribute is needed to enable Microsoft 365 Licenses. But there is no UsageLocation Attribute Available in the OnPrem AD Schema. Commonly the country (c) attribute is used to store the country of Residence of the user.
You can use AzureAD Connect to sync e.g. the OnPrem c Attribute with the Online Attribute UsageLocation. This can be tricky because the OnPrem Values in CN are nor normalized and have to be modified while before or while syncing them
Another solution could be to use Azure Functions to modify the attributes when the identities have been synced.
There are plenty instructions available in the www because this is a very common task in a customer’s cloud journey.
PreferredLanguage: The PreferredLanguage Attribute is available in the OnPrem Active Directory Schema, but it’s not used very often. So, just check if it’s filled and make sure that AADConnect is synchronizing it.
If it’s not filled you can consider to fill it automated by reading out the c attribute or check the Mailbox Language of the corresponding user.
Exchange OnPrem Attributes:
If you’re planning to migrate mailboxes to Exchange Online you should double check if the mailbox regional configuration is synced within the migration job. I’ve experienced it often that this was not the case. Keep that in mind and build pre and post migration jobs to store the regional maibox settings before the mailbox is migrated, and reapply them afterwards.
Microsoft 365 Portal: The Microsoft 365 landing page is using the PreferedLanguage user AD Attribute to chose the language for the user. If there is no value in the Attribute, the preferred Language of the Tenant is used.
A cloud-only user has the ability to change the preferred Language. To do so he has to open his account Language Settings. You can share this link to get into the right menu: https://myaccount.microsoft.com/settingsAndPrivacy/?languagesettings=true.
If the user is not able to change the setting here, the user might use an synchronized identity and the admin has to modify the value in the OnPrem AD manually.
Office 365 Groups
If a user is creating a O365 Group (enabled for Teams, Yammer, Planner, or not) a related mailbox and SharePoint Site is created also created with the locale of the Preferred Tenant Language. The language of the Group Mailbox is set to another language, the language of the Mailbox of the creator 😖🤯.
This Mailbox Language settings are relevant here because group invitations and other notification messages of the group will be send out in that language.
If you want to change this you have to implement it in a Group / Teams deployment which handles the Language Settings for the related Site and Mailbox afterwards.
Teams Client Language: The Teams Client Language is independent from other Language-Settings and respects the OS Language Settings. There is no administrative possibility to change the Teams Client Language, but the user can do this easily himself by navigating to the Client Settings and chose another language. After a restart of the Teams application it uses the new language. This works the same in the desktop and in the browser version.
No question that the possibility to manage the teams client language settings is missing. Vote this UserVoice up to speed it up: https://microsoftteams.uservoice.com/forums/555103-public/suggestions/34846579-allow-admins-to-set-default-team-language
Meeting Invitations: The Meeting Invitation Language is defined by the client application. If you’re using Teams to plan an appointment and invite members, the invitation is using the teams Client Language Settings.
If you’re using Outlook to plan the Event and enable it for Teams than the Mailbox Language is used
There is a uservoice to allow the adjustment of the meeting invitation: https://microsoftteams.uservoice.com/forums/555103-public/suggestions/35621764-for-the-meeting-invitation-generated-by-teams-meet
If you need to send out meeting invitations now in other languages than the Teams/Outlook Client, you can check if you are able to use the Graph API and the OnlineMeeting Ressource: https://docs.microsoft.com/en-us/graph/api/resources/onlinemeeting?view=graph-rest-1.0. Because this is event type is not bound to your mailbox you can adjust the notification settings.
Teams Notifications: If you’re not online in Teams and somebody tries to reach you, or if you were added to a new team you will receive a email-notification. Till now I did not found a pattern what is responsible for the language of the E-Mail.
Spell checking: The Spell Checking in Teams is using the Teams Client Language
Audio Conferencing Information: If you enable the Audio Conferencing License for a user or force a new submission of the Audio Conferencing Information, the Azure AD Attribute PreferredLanguage is used to chose the language.
By the way: this fact was the initiator for writing this blog. A international customer enabled audio conferencing licenses and the message was send out to all users in German. The reason for that was that the Preferred Tenant Language was set to Germand and the user values for PreferredLanguage have not been filled. So we updated the user Attributes and forced a new submission of the audio conferencing option.
Meeting Transcripts: The Meeting Recording which is stored in Stream can be enriched with a automatically generated Transcript. You have to chose the language in the Meeting Recording using Stream and enable it. Right now there are 8 Languages supported.: https://docs.microsoft.com/en-us/stream/portal-autogenerate-captions
Conversation & Chat Translation: The translation feature is using the Teams Client Language. If you want to translate to another language, the user has to switch his Teams Client Language.
Live Transcript & Captions: The Teams Live Transcript supports only English right now, an automated live translation (Captions) is on it’s was. So by now, the client settings etc. don’t play a role.
Stay updated by voting this up: https://microsoftteams.uservoice.com/forums/555103-public/suggestions/37608421-real-time-translation-feature-for-teams-meeting
Dial In Numbers: If a user has an Audio Conferencing License assigned, the Audio Conferencing Number is automatically added to the meeting invitation. The default is that a shared Service Number is used for the user. The Shared Number is based on the Location of the user to allow domestic calls. The location used to assign the shared number is the UsageLocation AD attribute of the User.
This localized Shared Numbers play the greeting in the language that is configured for this Conference Bridge. For the shared lines you can’t change the primary and secondary language which will be played afterwards.
If you e.g. want to use a German Dial In Number which welcomes the user in English you can add you own conference bridge and define the primary and up to four alternate languages. To do so open the Teams Admin Center and navigate to Voice > Phone Numbers to request a new Service Number. When the Number is provided you can build a new conference bridge by navigating to Meetings > Conference bridges and click on „Add“.
When the new conference bridge is available you can assign it to Teams users.
OWA: The Language in Outlook on the Web aka. Outlook Web App is defined by the Mailbox Language attribute (set-mailboxfolderregionalconfiguration).
Mailbox Folder Names: The first start of Outlook (or other apps that use the users mailbox) against a new Mailbox defines the mailbox language if it wasn’t preset. If you want to change the mailbox folder names you can change the Mailbox Language and reset the foldernames with set-mailboxfolderregionalconfiguration
System Messages: Exchange Online Admin System Messages like password Reset Notifications etc. respect the PreferedLanguage Value in the Azure AD User Object.
E-Mail Reply/Forward Subject Prefix: The Subject-Prefix of a answered or forwarded mail is based on the e-mail client. If you’re using a Spanish Office Installation and want to use English Prefixes you can change this in the Outlook Advanced Settings.
As you see we have various dependencies that are responsible for the user experience. Unfortunately it’s technically not possible to manage them all, and it’s hard to find out which setting will impact what.
But if you can handle it to fill the AD attributes PreferredLanguage, UsageLocation and the Mailbox Regional Settings you are a big step forward.