Exchange server installation – don’t mess with the locale

By Marc

As I have done quite a few Microsoft Exchange installations in the past years, there are some things you should know before your installation starts. When I do fresh installations for any Windows server software, I always suggest installing the English (en-us) version of Windows. In the early days of Windows, updates were first released for English versions and later for other languages, but this has changed. Nevertheless, not every component in Windows server has been rewritten to be fully language independent. And that takes us to the point, where I want to show you, what can go wrong, when Microsoft Exchange server software get installed on such systems.

Non-English Windows installation and the audit log

I have many customers who do not like the thought of not installing an operating system in their native language – but that comes at a price: The Exchange audit log search will always return empty results, when the operating system is not installed in English locale (see this Microsoft docs article). Although there is a workaround (setting the system locale back to en-us), you could have bypassed that one installing Windows in en-us.

Windows server core and the OWA people search

Windows server core installations are getting more and more popular (yes, I like them, too) – but you need to take care here, too. Mostly when installing Windows server core, we change the locale at installation time (keyboard and time settings) to match the region the server is managed from (i.e. de-de or something like that). That should help, when we need to login interactively with strong passwords for setting up the server and joining it to a domain (or do you know where every special character is located on the en-us keyboard?).

In combination with an Exchange server installation, that practice has proven to be a bad one. After installing Exchange server on a Windows server core system with a locale other than en-us, you cannot search the offline address book from OWA any longer (as described in this Microsoft docs article). In this case, a package from the language is missing, so the search cannot be completed. Although there is a workaround described in this article, it did not work out in my test environment until now.


So, what can we learn from all this? Well quiet simply put: Always install your Windows server in English. Do not mess around with different locales, keyboard settings or other stuff – it will get you in trouble one way or the other. If working with Windows server core, the use not-so-complex passwords for setup, enable PowerShell remoting and change them remotely.