Redirecting Webmail (OWA) URLs in IIS for All Exchange Versions

In this post I will show you how to redirect all OWA requests to the correct HTTPS address. It works not only with OWA, but with EWS and/or ECP.

I’ve been doing this for as long as I can remember in Exchange 2007/2010/2013 so that requests go automatically to https://owa.customer.com/owa (or /exchange). So, if someone goes to http://owa.customer.com or https://owa.customer.com, they get redirected to the correct (secure) URL.

Historically I’ve always done this with two components:

• A custom website listening on Port 80 on each CAS server;
• A default.aspx file in the root of the Default Web Site redirecting to /owa

This approach no longer works with Exchange 2010 CAS because the PowerShell virtual directory actually operates over Port 80 (authentication is Kerberized). If you try and tinker with this, you’ll start getting errors from Remote PowerShell like this:

VERBOSE: Connecting to cas01.customer.com
[cas01.customer.com] The WinRM service cannot process the request because the request needs to be sent to a different machine. Use the redirect information to send the request to a new machine.  Redirect location reported: https://owa.customer.com/owa/PowerShell. To automatically connect to the redirected URI, verify "MaximumConnectionRedirectionCount" property of session preference variable "PSSessionOption" and use "AllowRedirection" parameter on the cmdlet.
    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportRedirectException
    + FullyQualifiedErrorId : PSSessionOpenFailed


In order to work around this, you need to use the HTTP Redirection feature in IIS (the default.aspx trick mentioned above should work too), as well as remove the requirement for SSL at the top level Default Web Site object. You have to be careful doing this because when you set settings on the web site, IIS will push them down to any virtual directory below which does not explicitly set that setting itself. To setup the redirect, select the Default Web Site in IIS Manager, and open the HTTP Redirect option under IIS. Complete it like this:

Once this step is complete, you need to remove the enforced redirect from each of the virtual directories under the Default Web Site. To do this, select each virtual directory individually, and then open the HTTP Redirect property and uncheck the "Redirect requests to this destination" checkbox. You’ll need to do this on the following virtual directories:

• aspnet_client
• Autodiscover
• ECP
• EWS
• Microsoft-Server-ActiveSync
• OAB
• PowerShell
• Rpc

Note: The Exchange, Exchweb, and Public virtual directories should redirect to /owa.

 

If at this point you simply browse to http://cas01.customer.com and you’ll get an HTTP 403.4 error. This is because SSL is required at the top-level website. In order to get the redirect working, we need to disable SSL for the toplevel website while leaving it enabled for the relevant child virtual directories.

Select the Default Web Site and open the SSL Settings properties. Uncheck the Require SSL checkbox as shown below:

 

Like the redirection settings, this change will be inherited down the tree for any virtual directory which does not explicitly set the setting independently. Ensure that SSL is required for the following virtual directories:

• Autodiscover
• ECP
• EWS
• Microsoft-Server-ActiveSync
• OAB
• owa
• Rpc

Warning: If you require SSL for the PowerShell virtual directory, you will render Remote PowerShell inoperable!

 

Once you’ve configured the redirection and SSL settings, open a command prompt and run iisreset. At this point you should be able to browse to http://localhost on the CAS server and get redirected to https://owa.customer.com/owa. These steps were tested on Exchange 2007 and 2010 with Windows Server 2008 R2.

 

Notes:

• When you install an Exchange Service Pack or a Cumulative update, this definitions may be lost and you must do it all over again.
• When you change or renew the internal Exchange certificate, the IIS SSL settings may be lost and you must change the settings again.