Forcing Exchange's Admin Center to use a specific language

Exchange 2010 SP1 introduced the capability of allowing administrators to run the Exchange Control Panel (ECP) without requiring their account to be linked to a mailbox. This is a big deal for many companies who require people to access their email using “normal” or unprivileged accounts and don’t want administrators to use their mailboxes when logged in with elevated permissions.

ITPro Today

November 7, 2014

3 Min Read
Forcing Exchange's Admin Center to use a specific language

Exchange 2010 SP1 introduced the capability of allowing administrators to run the Exchange Control Panel (ECP) without requiring their account to be linked to a mailbox. This is a big deal for many companies who require people to access their email using “normal” or unprivileged accounts and don’t want administrators to use their mailboxes when logged in with elevated permissions.

Exchange 2013 supports the same feature and you can run the Exchange Administration Center (EAC) when logged into an administrator account that does not have an Exchange mailbox. The trick here, of course, is to make sure that the administrator account is included in the RBAC management role groups that EAC uses to decide what pieces of its functionality it reveals to a user. For example, if your account is not a member of the Discovery Management role group, you won’t see the UI components that would otherwise allow you to create and run eDiscovery searches.

EAC is very like Outlook Web App (OWA). The two browser interfaces share many components and EAC is, like OWA, capable of displaying its UI in multiple languages (see TechNet for the full list of supported client languages). All of this is well and good, but how does Exchange decide what language to use when someone starts up either OWA or EAC?

The answer is much easier with OWA because mailboxes can be assigned a preferred language with the Set-Mailbox cmdlet, which is then stored as a mailbox property called Languages. This is a multi-value property and OWA takes the first value and uses as the display language. And if the languages property for a mailbox is not populated, OWA asks the user to select it and their region the first time the mailbox is accessed. Later on, if they have made an incorrect initial choice, the user can go to OWA options and select another language.

Obviously, if you are an administrator who does not have a mailbox, Exchange has no point of reference. EAC therefore includes some logic to determine the best language choice based on some facts that it can ascertain about its environment. The default language for the browser is one clue as is the language of the workstation. And if the stars align correctly, EAC picks a language that please the user.

But it is possible that EAC will make a bad selection. For example, all administration workstations and the browsers installed on these systems might be configured to use English as a corporate standard whereas administration might be done through a local language. In this case, if the administrator does not have a mailbox, EAC will show up in English. This might, or might not, be acceptable.

Fortunately a workaround exists. You can instruct EAC to start up in a preferred language (even overriding the language selected for your mailbox) by including a market query string at the end of the normal URL. For example, to start up and use EAC in German, I’d use the URL:

https://server-name/ecp?mkt=de-de

And as the screen show shows, EAC will be more than happy to follow my orders and give me a quick lesson in Exchange administration in German (the same technique works for Exchange 2013 on-premises and Office 365). The joys of dealing with a truly international multi-lingual product!

Follow Tony @12Knocksinna

Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

You May Also Like