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:
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:
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:
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.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.