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.
- 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.
- 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.
- 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
