Introduction
You may think that setting up a language in Microsoft 365 [admin.microsoft.com] portals may be straightforward. However, it may not be as obvious as it seems at first, and there are many factors which can play a role in that.
The Basics
The interface language of Azure [portal.azure.com] and Microsoft 365 portals may be impacted by configuration set in different places. That configuration can be for instance [but not necessarily limited to] OS settings, browser settings, regional settings.
First things first, let’s begin with the tenant settings – you need to choose certain settings carefully from the very beginning. When you set up a tenant, the wizard asks you where you are located – ensure you select the correct location as you will not be able to change it. That location is used to define the usage location of Microsoft 365 data and services.
Selecting the correct location has two implications. Firstly, it is used to provide feature set – not every location provides the same features and services [please refer to: https://azure.microsoft.com/en-us/explore/global-infrastructure/products-by-region#products], secondly it can determine preferred language.
Below you can see a screenshot made in two separate Azure tenants. In both cases, the preferred language selection is very limited. To change it to a language which is not listed, you must create a new tenant.
To check the selected Region and preferred language field, please navigate to Microsoft 365 admin center / Settings / Org settings / Organization profile / Organization information.
Tests Setup
I have performed multiple tests, using both cloud-only accounts [Azure Entra ID], and on-premises accounts [created in Active Directory] synced with Entra ID [hybrid environment].
For the tests I have used a computer with Windows 11 Enterprise 23H2 with the display language being English (United States), language pack English (United States) and region also set to United States. [No tests were performed on macOS yet].
The browser I used was Microsoft Edge [latest available version at the time of writing the post]. None of the accounts tested were signed in to the browser [no browser settings were synchronized], and additionally, I conducted each test using in-private mode, to make sure all session cookies are cleaned on exit.
- On-premises accounts with preferred language set, synced with Entra ID:
- Cloud only accounts, with Preferred language property set:
For Luiza Ortega – one of the on-premises accounts synced to Entra ID, here are the language preferences that can be seen after signing in to the office.com portal and going to settings:
User Preferred Language can be set depending on the account origin.
- On on-premises Active Directory environment, the property preferredLanguage as seen on the previous screenshot is set in the ADSI Edit tool. The PowerShell “Get-ADUser -Properties *” does not retrieve this property.
- On cloud only account, in Entra ID you cannot directly set the Preferred language property after you click on Edit properties – this setting is not present there to modify. You can however do it in Microsoft Graph. Below short instruction shows how to do so.
Microsoft Graph
To launch Microsoft Graph, you must open the URL https://developer.microsoft.com/en-us/graph/graph-explorer (you can also connect directly using PowerShell, providing that all the prerequisites are met), and sign in to Microsoft Graph [top right corner]. When running Graph for the first time, you may need to provide consent to requested permissions. To update user attributes in Entra ID, more permissions may be required by Microsoft Graph. Please follow the link https://learn.microsoft.com/en-us/graph/api/user-update, to start with.
We will be checking and setting the preferred language for a user who does not have it set yet, which is required in the demo company tenant for the purpose of this exercise.
Below, an account which does not have the Preferred language set in Entra ID [and has never signed in].
Below shows a query in Microsoft Graph against the user whose preferred language needs to be set – see the highlighted line “”preferredLanguage”: null,“
Setting the value – we add the required code we need to execute, and select “PATCH”, then clicking on Run query:
{
“preferredLanguage”: “en-US”
}
Querying again to check if the preferredLanguage value is set, and it is:
Changes in Entra ID are visible after approx. 10 minutes.
The user can change the preferred language set by the admin.
- For the cloud only account, the preferred language property gets updated in Entra ID after the users changes it to its selection.
- For the on-premises account synced to Entra ID, user may change the language in the portal settings, but it does not seem to be saved in Entra ID account. After I have signed out the user, closed the browser [each time I am using in-private mode], opened the in-private mode again, signed back in, the preferred language previously set by the user remains.
Jan has his account preferred language set to Danish a day earlier, and it remains that way another day.
In Entra ID though, the preferred language remains as pl-PL.
Test results (On-premises accounts synced with Entra ID)
Each test account was used to perform certain tests. The accounts signed in to office.com, followed by Azure portal, then Microsoft 365 admin center from which all child portals were opened, using shortcuts on the left menu:
The below table shows the results of the tests performed. Each column was a separate sign in process using in-private mode. The table presents the preferred language set in on-premises Active Directory synced with Entra ID [the On-prem value], and the display language set in the browser [the Browser value]. Here are the results summarized.
The test shows that the display language on Microsoft portals like Azure, Intune, Exchange or SharePoint [and more] are only partially based on the Preferred language attribute set. The portals switch completely to desired language only when the browser display language is equal to the preferred language set in the user account attribute.
Test results (Cloud-only accounts)
As previously, the table shows the results of the tests performed, each column was a separate sign in process using in-private mode. The table presents the preferred language set in on-premises Active Directory synced with Entra ID [the On-prem value], and the display language set in the browser [the Browser value]. Here are the results summarized.
This time, using cloud-only accounts the test presented slightly different results. There is a small mismatch between the browser language and preferred language against the actual interface language in the visited portals. For sure, you can see the portals interface displayed in English, but when it comes to different ones, things are not coherent.
Languages support by Microsoft across the Azure and Microsoft 365 portals
- Azure
- Microsoft 365 admin center: https://learn.microsoft.com/en-us/microsoft-365/admin/admin-overview/admin-center-overview?view=o365-worldwide#what-language-options-are-available-the-admin-center
- Exchange Server: https://learn.microsoft.com/en-us/exchange/plan-and-deploy/deployment-ref/language-support?view=exchserver-2019
Conclusion
After examining possible scenarios using two account types, i.e.: on-premises Active Directory synced with cloud Entra ID, and cloud-only accounts, with different languages set in the account properties, and also having different browser display language set, I believe it is safe to conclude, that setting up the languages across Microsoft portals for coherent user experience is not an easy task and many factors need to be taken into the account. The factors that you need to take into account are (not limited to) following:
- Operating system language
- Browser language
- Preferred language set in the account properties
- Languages supported by the platforms
- It may take up to 24 hours to apply the new language selection on certain portal like: SharePoint, OneDrive, Excel or OneNote.
I want to end the post with a question – what is your experience with dealing with configuring languages across Microsoft admin portals? Do you have any ideas, thoughts or tips that you would like and can share with us?🙂
Marcin Chwała is IT Consultant at Mindcore with over 15 years of experience, in which last ten years focusing on endpoint management. He is based in Poland.
His areas of expertise cover Microsoft products, specifically:
- Microsoft 365 products suite (Exchange, SharePoint & OneDrive, Defender)
- Intune and Configuration Manager [Endpoint Management]
- Windows 11 & 10 [client operating systems in general]
- Application Management, packaging, lifecycle
- Windows Server systems (ADDS, DNS, DHCP, CA & PKI, Hyper-V)
Passionate about delivering the best possible end user experience, utilizing technologies for top productivity – I believe that technology must never exist purely for its own sake.
