Frank Plawetzki posted a great article on issues that can affect how clients retrieve their Offline Address Book (OAB). This has also been the source of some recent work for myself, though with slightly different root causes. The issues that I have encountered were due to:
-
Invalid SSL Certificate
-
OAB web.config file
-
Incorrect process followed for HTTP redirect
Update 4-3-2014: Added link to KB 975341 How to configure Exchange to redirect OWA HTTP requests to HTTPS requests in IIS 7
Invalid Certificate Installation
OAB by default uses HTTP rather than HTTPS. This is because the web OAB download mechanism uses BITS, and BITS does not support self signed certificates. Thus to ensure a working initial configuration with the default self signed Exchange certificate, HTTP is used. Once the correct certificate is installed, with all the URLs as per your CAS namespace design, then the URL can be changed to HTTPS.
This is important as sometimes certificate issues can block the HTTPS connection to CAS. To bypass this, the client can connect to CAS by using HTTP thus eliminating SSL. If the OAB download then works, then the issue is most likely with the certificate. How do we get the client to connect with HTTP? Either the OAB download location can be changed in EMS to HTTP with the command below or an AutoDiscover tweak can be used.
Set-OABVirtualDirectory –InternalURL “http://Exch-1.tailspintoys.com/OAB”
Though if this is not permissible due to change control etc. then it is possible to override the connection on an individual workstation. Since AutoDiscover is responsible for handing the URLs to the client, all we have to do is to override AutoDisover results from the server by specifying a local AutoDiscover XML file as specified in the bonus tips of this blog entry.
It should also be noted, and as shown in Frank’s blog, Internet Explorer should typically be used as the browser when making test connections to Exchange. This is because IE will use the same certificate infrastructure as Outlook, where other browsers maintain their own certificate stores. That said, if you suspect that there is an issue with the IE certificate components then it would be a good test to use a different browser to see if the behaviour persists.
Invalid web.config File
Traditionally Exchange administrators have configured redirects on Outlook Web App so that users who do not add /Exchange or /OWA to the end of the URL are automatically redirected to the correct URL (with the /Exchange or /OWA appended). The same is also true for some organisations who want to automatically redirect users who do not enter the HTTPS:// prefix and use HTTP, again the URL will be automatically redirected.
This is an established practise with the Exchange community, and the process is documented on TechNet. So what could possibly go wrong? In short, not reading all the instructions, or working from a forum post that has incomplete instructions. In the scenario that I will describe a web.config file is added to the OAB virtual directory and can cause issues. By default no web.config file is present in the OAB directory as can be seen here:
When settings on the OAB virtual directory are changed to disable the redirection which is inherited from the root of the web site for example, a web.config is created to hold the settings. This file does not have the correct ACL set and thus will cause issues for OAB download.
An ACL to allow Authenticated Users to have Read & Execute permissions should be added. Once the ACL is added the OAB will be able to be downloaded. This is documented on the TechNet article, but is not always implemented. Please also review the note at the bottom of the TechNet article with regards to removing the redirection.
Additionally, KB 975341 How to configure Exchange to redirect OWA HTTP requests to HTTPS requests in IIS 7 is also available to discuss how to redirect users.
Cheers,
Rhoderick
Hi Rhoderick, I am willing too to automatically redirect http owa requests to https, to make life easier for my end users.
My environment consists of Exchange 2013 CU23 on WIndows Server 2012 R2 (IIS 8.5).
First, I carefully read your article and you say that a web.config file should not exist in %ExchangeInstallPath%ClientAccess\OAB folder. I looked into %ExchangeInstallPath%ClientAccess\OAB path and I already see the web.config file in there, with the ACE "Authenticated Users" missing. However, my users correctly download the OAB.
Another question, the main one: I have read around of many "ways" to accomplish the task, other than the official one(s) from technet:
1) One is well explained here: https://blog.expta.com/2016/05/redirection-in-exchange-2013-cu6-and.html
It refers specifically to Exchange 2013 CU6+ and 2016. Basically he suggests to create an error page in IIS mmc for the error code 403.4 to answer with a 302 redirect to the correct URL (ie https://mail.contoso.com/owa). The reason is that with this method you don't need to mess with the Exchange virtual directories security settings, inheritance, etc.
2) Than there is this one, written by Ace Fekay: https://blogs.msmvps.com/acefekay/2013/04/16/redirect-owa-exchange-2010-exchange-2013-the-cool-and-easy-method/.
He claims to have had a talk with MS Support for other reasons, and while troubleshooting his issue they debated about the best way to accomplish the http->https autoredirect task. Briefly, they ended up saying that instead of applying settings to the "Default Website" root with the inheritance implications (the need to unset inherited settings on the subfolders where not needed and the risk of messing up things), it's way better to apply the redirect method only to the "iisstart.htm" file.
3) Technet provides two methods, quite similar but not identical.
3a)If you look for Exchange 2013, there is this one: https://docs.microsoft.com/en-us/exchange/simplify-the-outlook-web-app-url-exchange-2013-help
3b)If you look for Exchange 2016 and later, there is this one instead: https://docs.microsoft.com/it-it/exchange/clients/outlook-on-the-web/http-to-https-redirection?view=exchserver-2016
Basically, they differ on the "require ssl" unsetting part, where for 2013 you have been told to just unset the redirect for all the virtual directories that inherited the redirect setting from the root "Default Website"; for Exchange 2016-2019 you should remove both the inherited "redirect" setting on all vdirs and the "Require SSL" setting on all vdirs except for the /owa vdir.
Honeslty, I am quite confused on how to proceed. In the logic of "the simpler the better" I should opt for option 1) or 2). In the logic "follow the Technet bible" I should follow the 3rd option (but which one? 3a or 3b?).
I hope you can kindly give me some hint in order to make the best decision.
Thank you,
Francesco
Hi there!
This post was written orginally for Exchange 2010, and as such is old.
Realistically there should be some firewall or load balancer in front of Exchange and the Internet, and that device should be able to do the HTTP -> HTTPS transition. In my deployments nowadays, TCP 80 is not published to the Internet or even internally.
Cheers,
Rhoderick