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 a 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 their impact 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 to this inconspicuous topic. I will also describe which values are relevant here.

Tenant Settings

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 afterward.
This decision will define the primary usage location of all your Office 365 Services and Data. The Region can have an 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 user 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 afterward, to a language that’s not available in your 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 afterward 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 an 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 using 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 in 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 that 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)

• Delve

• Forms

• Planner

These services do not make use of the PreferredLanguage Attribute:

• Exchange Mailbox

• Bookings

• Kaizala

• Stream

• Sway

• …

The PreferredLanguage Attribute is mainly used by SharePoint Online to define the language for the User. It seems that all Services that were not built on the base of SPO are not using the Attribute.

Exchange Online Attributes

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 an Outlook Client which is configured for German, the Language will be set to German, if your first login to the mailbox is a 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 your 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 not 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 of instructions available on 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 filling it automated by reading out the c attribute or checking 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 mailbox settings before the mailbox is migrated, and reapply them afterward.

General

Microsoft 365 Portal: The Microsoft 365 landing page is using the PreferedLanguage user AD Attribute to choose 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 a synchronized identity and the admin has to modify the value in the OnPrem AD manually.

Azure Notifications: Various admin and end-user notifications were sent out by azure via E-Mail, examples are Access Package Request and Expiry Notifications, Azure Alerts, Microsoft Defender Notifications etc.. These notifications were sent out using the default tenant language.

Microsoft 365 Groups

If a user is creating an M365 Group (enabled for Teams, Yammer, Planner, or not) a related mailbox and SharePoint Site are created also 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 sent 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 afterward.

Programmatically Creating or Cloning a Group / Team: If you are using Microsoft Graph, or PNP to deploy or clone Groups and Teams, you can’t define the language of the new M365 Group. The tenant language is used, also if you clone a Group with other language settings defined I recently had a conversation about that topic with Loryan Strant on Twitter where we spoke about the different approaches.

Loryan published a blog post sharing his experience for that use case: Programmatically creating a Team in a tenant with a different language – Loryan Strant, Microsoft 365 MVP. The only way that worked for me to build a complete automated solution, was to use the SharePoint Rest API for Group Creation. For cloning – using the Graph API – there is no way to use another language than the default tenant Language. So if you need a team that uses another primary language than the tenant language, you can’t make use of the clone Method.

Teams

Teams Client Language: The Teams Client Language is independent of 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 choosing another language. After a restart of the Teams application, it uses the new language. This works the same on 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: Allow admins to set default Team language · Community (microsoft.com)

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 then the Mailbox Language is used

Meanwhile, MSFT allowed a centralized Management of the meeting invite language. You can now use Teams Meeting Policies to define the language that is used for meeting invitations of a user (Regardless if you use Teams or Outlook to generate the meeting invitation). Tony Redmond wrote a good article how to use this additional policy setting: Teams Meeting Invitation Language Set by Meeting Policy (office365itpros.com)

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 an E-mail notification. Till now I did not found a pattern of 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 choose the language.
By the way: this fact was the initiator for writing this blog. An international customer enabled audio conferencing licenses and the message was sent out to all users in German. The reason for that was that the Preferred Tenant Language was set to German 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 an automatically generated Transcript. You have to choose 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 its way. 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.
These 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 afterward.

If you e.g. want to use a German Dial In Number which welcomes the user in English you can add your 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 clicking on „Add“.

When the new conference bridge is available you can assign it to Teams users.

Exchange Online

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 folder names 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 an 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.

Conclusion

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.

Other news