Configuring Multiple OWA/ECP Virtual Directories on Exchange 2010 Client Access Server


A while back we published an article explaining the support constraints that surrounded deploying Exchange 2007 with multiple Outlook Web App (OWA) Virtual Directories (see here http://msexchangeteam.com/archive/2008/01/07/447828.aspx) and as this idea seems to come up more and more frequently, we wanted to do the same for Exchange 2010.

Microsoft supports using multiple OWA and Exchange Control Panel (ECP) virtual directories on a single Exchange 2010 Client Access Server, each in its own website. Each virtual directory must be listening on the standard port (TCP 443) for the site.

NOTE: You must ensure that the Default Web Site is set to All Unassigned for IP, or problems will occur with PowerShell.

There are usually three reasons for choosing this type of configuration. Each of these has slightly different considerations.

  1. Scenario 1: You have one Active Directory site facing the Internet, and are using a reverse proxy (such as Microsoft Forefront Threat Management Gateway or Unified Access Gateway) in front of Exchange. You are delegating credentials from that firewall to Exchange, meaning you have to use Basic or Integrated Windows Authentication (IWA) on the CAS and not Forms-based Authentication (FBA). Your requirement is to provide FBA for all users, internal and external.
  2. Scenario 2: You have a non-Internet facing Active Directory site and your requirement is to provide FBA for all users, internal and external.
    In this configuration, in order to provide external users access to OWA or ECP, a CAS in the Internet-facing site must proxy requests to the CAS in the non-Internet-facing site. This requires the CAS in the non-internet-facing site have IWA enabled, thereby disabling FBA.
  3. Scenario 3: You have different users within one organization who require a different OWA experience, such as a different customization of the Form Based login page, or different Public/Private File Access or Segmentation features.

If the objective of creating multiple sites is to allow a CAS to offer FBA to internal users, as well as accept proxy or delegated connections from an Internet-facing site or a reverse proxy, each virtual directory will have a different authentication method. The site accessed directly by the user population will be FBA-enabled, the site accepting proxy requests from the Internet facing site — or delegated authentication requests from the firewall, will have IWA enabled (or potentially Basic for the firewall scenario).

Microsoft strongly recommends OWA and ECP virtual directories in the Default Web Site be configured for IWA, leaving the InternalURL as with the default (Server FQDN), making that site and virtual directory the target of proxy requests from other Active Directory sites or delegated connections from the firewall.

Microsoft recommends creating the second OWA/ECP virtual directories in a new IIS web site with a different IP address, and using it for internal client access. By default the new virtual directories will be FBA-enabled, and have no internal or external URL values.

You will also need to ensure that whatever name the internal users will be using to connect to the new FBA-enabled OWA/ECP site is present on the installed certificate and the name resolves to the correct IP address (by making sure a valid A/CNAME record exists).

One side effect of this configuration is encountered when an Outlook 2010 user accesses ECP. AutoDiscover provides Outlook 2010 with both internal and external URL’s for ECP. When the Outlook client is inside the network and connected using RPC over TCP, as opposed to Outlook Anywhere (RPC over HTTPS), the InternalURL value is used to access ECP when triggered from a function within Outlook – such as delivery reports. In the configuration recommended above, this results in the user being directed to the web site with Basic or IWA authentication enabled, not FBA. If this is acceptable, your configuration is complete, no further steps are required.

If you would prefer to use FBA for internal ECP access you have some additional considerations.

For Scenario 1, you can set the InternalURL of both ECP virtual directories to resolve to the FBA-enabled web site — which means internal Outlook 2010 clients will end up reaching the FBA-enabled ECP virtual directory. Additionally any internal OWA users accessing ECP will benefit from seamless Single Sign On between OWA and ECP.

For Scenario 2, if the CAS is in a non-Internet-facing site, then having the same InternarlURL for both ECP virtual directories breaks the ability of a CAS in an Internet facing site to proxy to the target CAS. In this case, if you wish to have two web sites for ECP, and have both proxy and FBA, you will need to accept that Outlook 2010 and OWA users will see an authentication prompt. However, if the site is added to the Local intranet security zone for Internet Explorer, internal clients will pass credentials for the locally logged-in user to the CAS when they access ECP.

Additional considerations

  • To avoid issues with DNS registration, the following Hotfixes are recommended, based on your server version:
  • When one web site causes the Application Pool to crash, it will impact all web sites hosted in this Application Pool.
  • If one site uses too many resources and it is throttled, the operations in all web sites in this application pool will be throttled.
  • When you decide to recycle the Application Pool, all web sites hosted in this Application Pool will cease to work temporarily.
  • In the event that Segmentation is introduced, ensuring that users have an appropriate method to access required ECP features is a concern for the configuration.

We hope this helps you understand the configuration a bit better now should you choose to go down this route and please post back if you have any questions or comments.

Greg Taylor & Will Duff

Comments (9)
  1. Carlos Tronco says:

    Do these recommendations still hold in the scenario 1 when using hardware load-balancers? In that scenario should the EWS and Autodiscover vdirs also exist on the new secondary FBA IIS site or….?

  2. Greg Taylor says:

    Hi Carlos, it wouldn’t typically apply as a hardware load balancer is not delegating credentials to the CAS, nor doing Forms Based Auth.

    There’s also no need to put AutoDiscover or EWS on any second web site, and in fact EWS may not work if you do so anyway. Leave those on the default web site.

  3. Kit says:

    Hi Greg & Will, my scenario falls into #3, and I’ve a requirement for the new IIS website to be configured for IWA and the InternalURL in the alternate site populated in order for Proxy of the new IIS website to work. Is this a supported MS configuration? Also the recommendation is to use two IPs, however are using IIS host headers a supported configuration (two websites sharing the same IP address). Thanks.

  4. markus says:

    Hi Greg

    just created in the test environment an additional vdir for Reverse-Proxy-Autentication. How will a Rollup or SP upgrade inpact the additional vdirs? Are they correctly upgraded as well or are manual steps involved? Because one creates a new webapp…

  5. Greg Taylor says:

    @Kit – we don’t recommend you configure it to use host headers. As the article says, we recommend you use two IP addresses and two web sites. Your solution would not be supported at the current time.

    @Markus – it’s impossible to say what a future roll-up may or may not do, though they should not break this if we do our bit right, though as with all roll-ups and service packs, it’s always very good practise to test it yourself first in a test lab before deploying to production, just in case you have something unusual configured. So try and keep a virtual lab copy of what you have in production, so you can quickly and easily test (and rollback if needed) any updates you want to apply.

  6. Fredrik says:

    Great article!

    But when testing this for a customer we ran into a problem related to the DNS hotfix (2386184) and the new ‘skipassource’ flag. When using this flag on a IP-address it won’t show up in IIS Manager when trying to create the new web site. If we add the IP-address without this flag (ie not set, or set to false) we can see the IP in IIS Manager.

    We’ll continue to test with static DNS entries instead of this flag…

  7. Gp230014 says:

    Great post

  8. Eric says:

    Hi Greg, I’m curious about companies who will have OCS 2007 R2 and Lync running side by side.  Would that basically fall into scenario 3 or is there a way to have both IM servers enabled?

  9. Greg Taylor says:

    Hi Eric, I’m sorry, I don’t know, I would suggest reaching out to the Lync team to get their input.

Comments are closed.

Skip to main content