Provisioning the accounts was the easy part.
The Problem
As soon as I started handing these accounts out, users were reporting the inability to get past the select language screen. Users were able to log in without issue, but after selecting an appropriate language and time-zone they simply recieved a blank screen. Anyone who was persistent enough to try 3 times in a row eventually did get in, and after they were in once, they didn't have any more problems.After replicating the issue and confirming it was in fact happening, I checked eventvwr, exchange logs and IIS logs but I was unable to pinpoint what was causing the problem. In fact the logs had nothing unusual at all in them.
I was able to determine the blank screen was when the web browser was attempting to access the following URL: https://OWAURL/owa/lang.owa
The Fix
As the problem seemed to disappear after the user entered and accepted the time-zone and language data 3 times, I thought I would try forcing the local ID onto the OWA instances in question.Voila, after executing the following command into an Exchange powershell console, users no reported any issues.
Set-OWAVirtualDirectory "owa (Default Web Site)" -DefaultClientLanguage <Locale ID>
You can use this table provided by Microsoft to search for your Locale ID.
If you are using a custom OWA instance with a different name, you can use the following command to get a list of all the OWA instances on your server.
Get-OwaVirtualDirectory
Hopefully you are smart enough to do this BEFORE you start adding accounts and not when users start having problems.
Thank you for publishing this. I am in the midst of planning a rollout and this will be most helpful.
ReplyDelete