Configuring Multiple OWA/ECP Virtual Directories on the Exchange 2013 Client Access Server Role

[The_Exchange_Team]

6/17/2019 - We have some updated info relevant to this blog post - https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Monitoring-Exchange-using-Multiple-OWA-ECP...

We have previously published guidance for setting up multiple OWA and ECP virtual directories for Exchange Server 2007 and 2010, and now it is the turn of Exchange Server 2013.

The eagle eyed amongst you may spot some copy and paste from previous blogs on the subject, and well frankly, you’d be correct. The reasons for doing this haven’t changed, only the method by which you do it, so I’m re-using some of the text to avoid wasting electrons.

In short: Microsoft supports using multiple Outlook Web App (OWA) and Exchange Control Panel/Admin Center (ECP) front end virtual directories on a server with the Exchange 2013 Client Access Server role, when each is in its own website and is named ‘OWA’ and ‘ECP’.  Each virtual directory must be listening on the standard TCP 443 port 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. Here’s what we said for Exchange 2010:

• 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 Client Access Server (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 Public/Private File Access or other policy or segmentation features. (This might be a good place to remind you that customizing and branding OWA isn’t something we support in Exchange 2013, so this is NOT a reason you want to consider this type of configuration in case you were wondering)

Now things are actually a bit different with Exchange 2013. I’m calling this out in case you didn’t actually know. You can achieve scenario’s 1 and 2 out of the box with no additional configuration, specifically, no need for an additional web site. Yes, really.

Exchange 2013 ships with Integrated Windows auth enabled on the OWA and ECP virtual directories as well as Forms based auth. So, if you choose NTLM delegation, or KCD, from TMG/UAG to Exchange, it just works. And because OWA is smart enough to determine the machine connecting to it is a browser and not another Exchange Server, the second scenario just works out of the box too. Clients get FBA, but proxy still works. Genius.

With Exchange 2013 there’s one new reason to add to the list, separation of the client facing ECP settings pages, and the Exchange Administration Console (EAC) settings pages. Both of these are served by the ECP virtual directory, which is somewhat confusing I’ll admit. Basically the code behind the ECP virtual directory serves up either the personal ECP pages or the administrators EAC pages based upon on the credentials of the user logging in. Of course this means if you allow access to /ECP from the Internet (which you need to for OWA or Outlook users to go to ECP) you also allow someone with administrative credentials to log into EAC. Some customers don’t like this.

So to summarize, the only reasons for which you might feel the need to create multiple OWA and ECP virtual directories:

1. Separating admin/user ECP access.
2. Or scenario number 3 as described earlier, because you have different policies or settings, or authentication requirements.

Now that’s clear, here’s some more statements, warnings and caveats.

Microsoft supports creating additional OWA/ECP virtual directories in a new IIS Web Site with a new IP address, and using those only for client access purposes. By default that 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 users will be using to connect to the new FBA enabled OWA/ECP site is present on the installed certificate and that DNS for that name resolves to the correct IP address.

Additional considerations:

• To avoid issues with DNS registration, the following Hotfix is recommended, if Exchange is installed on Windows 2008 R2
  http://support.microsoft.com/default.aspx?scid=kb;en-US;2386184
• If one site uses too many resources and it is throttled, the operations in all web sites in this application pool will be throttled.
• If you ever decide to recycle the Application Pool, all web sites hosted in this Application Pool will cease to work temporarily.

So now you understand the scenarios properly, and understand the constraints and potential issues, there’s just the actual steps you need to use to go through.

Ok, just remembered, there’s one more warning. Only the following set of steps are supported. If you decide to miss a few steps out, change a few to suit yourself, or anyway otherwise generally ignore these and go your own way, you will not be supported. And, just as likely and more importantly, you will break something and your users will be angry, and so will your boss. So just follow the steps, and don’t cross the streams.

Here are the steps, at last.

This process assumes you are setting the default web site to use Integrated Windows auth only, and the new Virtual Directory will be configured for FBA, because that’s supported. You can leave default web site configured for FBA too, by not doing anything to it, but I’m documenting the steps for turning that off, just in case that’s your choice.

1. Add a secondary IP address to the server– this could be with another NIC, or done just by adding an IP to an existing NIC.
2. If you added a NIC, in the network properties, uncheck 'register this connection in DNS' in IPv4 for the NIC (this also prevents IPv6 from registering too as it happens).
3. Create the additional website in IIS in a new root folder (C:\inetpub\OWA_SECONDARY) and bind it to the new IP. Enable for SSL, choose whatever certificate you want to use for this site.

   

4. Give the local IIS_IUSRS group Read and Execute permission to the C:\inetpub\OWA_SECONDARY folder.
5. Copy the Default Web Site root folder contents in its entirety including any subfolders to the new site root folder (i.e. copy %SystemDrive%\inetpub\wwwroot\ contents to C:\inetpub\OWA_SECONDARY).
6. Create new OWA and ECP subfolders in your new web site’s root folder (C:\inetpub\OWA_SECONDARY\OWA, C:\inetpub\OWA_SECONDARY\ECP).
7. Copy the entire contents of the Default Web Site OWA and ECP folders including any subfolders to the new subfolders for new web site. (Copied from /…/FrontEnd/HttpProxy).
8. Run the following (substituting <Server> for the server hosting the CAS role);
   1. New-OwaVirtualDirectory -Server <Server> -Role ClientAccess -WebSiteName OWA_SECONDARY -Path "C:\inetpub\OWA_SECONDARY\OWA"
   2. New-EcpVirtualDirectory -Server <Server> -Role ClientAccess -WebSiteName OWA_SECONDARY -Path "C:\inetpub\OWA_SECONDARY\ECP"

      

9. Run the following to set the default site to IWA only (this is optional, but provided in case you want to do this);
   1. Set-OwaVirtualDirectory -Identity "<server>\owa (Default Web Site)" -FormsAuthentication $false -WindowsAuthentication $true
   2. Set-EcpVirtualDirectory -Identity "<server>\ecp (Default Web Site)" -FormsAuthentication $false -WindowsAuthentication $true
10. Perform an IISReset.
11. Test! Really, make sure you do.

The final thing to understand is what you need to do when you apply a Cumulative Update (CU) to any server you have made these changes to. The CU install will NOT properly update the files in the secondary OWA or ECP web site for you, nor will the secondary site work correctly. It’s not just a resource folder/file version issue and just updating the files in directory is not going to do it, there’s more to it.

The only supported solution here is to delete the secondary Vdirs and Web Site and re-do all the steps. So, make sure you have noted any non-default settings you had on the site, then delete the Vdirs, delete the web site (don’t forget to do this), delete any content in the folders, and start again at step 3 in the list above. Re-create the web site, re-create the Vdirs, copy the latest files and re-apply any custom configuration or settings you previously applied. Don’t skip any steps or take any shortcuts. Script it (you can even script the deletion/creation of a web site), run that script after you install the CU, and ensure you do this after each and every CU.

Once you have done that you should be good to go.

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
Principal PM Manager
Office 365 Customer Experience