Using IIS 7 URL Rewrite Module to simplify Exchange 2007/2010 Outlook Web Access URLs on Windows Server 2008/2008 R2

The default URL for Outlook Web Access i Exchange Server 2007 is https://<server FQDN>/owa. This URL is always an issue for end users who find it too long or complex. They either forget to use HTTPS in front of the URL, or to append /owa to the server name, or both. The first mistake results in an error saying SSL is required. The second loads the root of the site. I agree that this could be made more user-friendly so I always implement some form of rewrite or redirection. Typically I make OWA available at just <server FQDN>. No HTTPS or subfolder, e.g. This requires two things; redirecting HTTP traffic to HTTPS and redirecting the root folder to the /owa subfolder.

Note: The final URL for OWA is always (almost) https://<server FQDN>/owa. We cannot disable HTTPS or publish OWA at the root of the site. But the URL users type can be simplified. This simplification is what I mean when I say redirect in this article.

Until recently the redirection to HTTPS and the subfolder OWA could be accomplished by first redirecting the root folder with IIS 7’s HTTP redirect functionality and then editing the HTTP error page , typically 403, so that it would redirect to HTTPS instead of throwing an error. I have never liked this approach, especially the latter part. You could also use ISA Server 2006 in front of your Exchange server and do the same there. But recently a much better solution has arrived. The IIS team has released the URL Rewrite Module extension to IIS 7 which lets you perform advanced URL rewrites and redirects using, among other things, regular expressions.

How to simplify the OWA URL with URL Rewrite:

      1. Download and install the URL Rewrite extension on your CAS server.
        Remember to get the version for your architecture. This will almost always be x64 unless you are in a lab and running the x86 version of Exchange 2007.
        To avoid having to restart your server follow the steps in this post:
        Also, these instructions are written for the 2.0 version. I cannot guarantee that they will work with any older or newer version.
      2. Disable the Require SSL setting on the Default Web Site.
        This is necessary for the redirection in URL Rewrite to work. This is not a security issue since URL Rewrite will force SSL for the entire site (except for OAB).
      3. Open the web.config file under your wwwroot folder.
        This is usually under %systemdrive%inetpubwwwroot.
        The web.config file does not exist by default, so change a setting on your site and change it back again to have IIS generate the file.
      4. Paste the following text in web.config in the <system.webserver> section:

NOTE: The PowerShell vdir entry is to exempt the /powershell virtual directory found on Exchange 2010 Servers from HTTPS enforcement. This is necessary for remote management of Exchange 2010 Client Access Servers. This rule should have no bearing on an Exchange 2007 server as they do not have the powershell vdir.

This will create three new rewrite rules.

      • Open the URL Rewrite item under Default Web Site.
      • Your three new rules will look like this:
        The rules will be processed from top to bottom.
Rule name Function Notes
Redirect root Redirects the root folder to /owa
Exempt OAB from SSL Turns off the requirement for SSL for the /OAB subfolder.
This is the default Exchange 2007/2010 setting. If you want to have SSL for the OAB folder as well, delete this rule and update the OAB URL setting in Exchange.
Stop processing enabled
Exempt PowerShell vdir from SSL This rule is only required for Exchange 2010, but can safely be imported on Exchange 2007. Stop processing enabled
Force HTTPS Enforces HTTPS for all requests to the site.
      • Perform a test

All requests for the root folder or for the /owa folder missing SSL will now be redirected to the OWA logon page. All other subfolders are not redirected, except to enforce SSL, and can be accessed directly.

Note: The Exchange 2007/2010 web folders usually inherit their SSL settings from the Default Web Site, so when you turn off the SSL requirement for the site you also turn it off for the web folders. If, for some reason, any of the subfolders manage the SSL setting in their own context (ie. they do not inherit the SSL setting from the site level) you have to disable Require SSL for those folders as well. If not, the URL Rewrite will not kick in and you will get an error instead of a redirect. The folders associated with Exchange 2007/2010 are:

      • Autodiscover
      • EWS
      • ecp
      • Exchange
      • Exchweb
      • Microsoft-Server-ActiveSync
      • OAB
      • Owa
      • Public
      • Rpc
      • RpcWithCert
      • UnifiedMessaging

All these should have their Require SSL Setting turned off. For any other folders you may have on the server you will have to decide for yourself if you want them to be included in the URL Rewrite SSL Enforce or manage their SSL settings individually. Also make sure to check any other folders that should have SSL active still has that setting set when you deactivate the requirement for the site.

I find this solution to simplifying the URL for OWA to be much more streamlined and elegant than any previous solution. The URL Rewrite filer is a module developed by Microsoft meaning it has been through the Secure Development Lifecycle (SDL). You have only one place to make all changes. You do not have to make changes to the default IIS configuration (ie. editing or changing the error pages).


Update: When you disable the Require SSL setting in IIS you rely on URL Rewrite to perform the enforcement for SSL on your sites and directories. I have been in contact with the author of URL Rewrite, asking him if this configuration is a security risk and if the enforcement of SSL through URL Rewrite is as strong as the one in IIS. His reply was that it was not but that this was a cause for concern in very few situations. You have been warned.

11 thoughts on “Using IIS 7 URL Rewrite Module to simplify Exchange 2007/2010 Outlook Web Access URLs on Windows Server 2008/2008 R2”

  1. Really nice “workaround”. Are these steps applicable also to Exchange 2010?

    Thank you for your answer,

    1. Hello Dawid

      The procedure is not quite ready for Exchange 2010, but I have a working setup that I will document here shortly. Thanks for your feedback.


      1. Is this process now Exchange 2010 ready? I am having quite a time redirecting non-https requests for my owa site to https, and I have followed a number of suggested procedures (individually) with none of them being 100% successful.


        1. Hello Ryan

          Yes, these steps have been tested on Exchange 2010. I am using the procedure with good restults on several locations. After a little tweaking I was able to come up with rules that work for both Exchange 2007 and Exchange 2010.


    1. Hi Aaron

      Unfortunately no, the IIS Rewrite Module is only available for IIS 7 (Windows Server 2008) and IIS 7.5 (Windows Server 2008 R2). There are other ways to accomplish this on Exchange 2003, I mention some of them in the introduction to my post; you can use a combination of IIS 6’s bulit in redirection and custmoizing the error page for SSL required. Or you can use a reverse proxy like ISA Server 2004/2006 to do the redirection.


  2. I installed this following the example,but it’s a bit out of my understanding to be honest. “the only” thing i want is to redirect users to my /owa folder with a link i came up myself. Suppose my domain is , than i want users to be able to type in and the be redireted to owa. Is (and if so,how!) this possible?

  3. Can I use these rules with some modification in another internet facing IIS 7.5 box (using it as reverse proxy) and forward request to CAS server.

  4. Hi thanks for this tutorial will this help me if i want to connect owa using http only? because i´m able to conect using http but after logon automatic redirects to https and i dont want it to make this. thanks

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.