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


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.

    owa1

  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"

      owa2

  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

Comments (11)
  1. Anonymous says:

    Thanks for the details. One question though: how is this any better than using IP restrictions in IIS to restrict the ECP site to internal subnets?

    I’m far from an expert, but from what I can tell, using IIS IP restrictions to limit ECP to internal addresses has two strikes against it:
    1. The ECP site is still available from the outside, but the authentication fails. It effectively blocks the ECP site from being seen from the outside, but it’s sloppy.
    2. External OWA users can’t manage their settings (OOO, signatures, etc) because OWA uses ECP to manage those.

    It seems to me like the method in this blog post would solve issue #1 by making the ECP completely unavailable from the outside, but issue #2 would still exist. And with this method you would have to re-deploy with each new CU/SP, and that seems just as sloppy
    if not more than issue #1 above.

    Am I thinking correctly here, or am I missing something? (probably the latter. =)

  2. Anonymous says:

    There’s a small typo on step 5: %SystemDrive& -> %SystemDrive%

  3. Julia S. Iglesias says:

    I´m setting the co-existence environment between Exchange 2007 and Exchange 2013 publishing OWA services throught ISA Server 2006.

    For OWA I have FBA just on ISA Server ( NTLM on Delegation Tab) and "Windows Authentication" set on Exchange 2007 OWA virtual directory authentication.

    If I left default OWA authentication for Exchange 2013 (FBA).. The internal proxy redirection (between Exchange 2013 – Exchange 2007) in order to access OWA for users not migrated will works?? I assume they get the FBA from Exchange 2013 Client Access and they
    will get the Exchange 2007 OWA experience without a second validation. Is this OK?

    External users only will get the FBA presented for ISA Server and not double-FBA (1st ISA , 2nd Exchange 2013). Is this correct??

    Regards,

  4. Joseph says:

    I suppose I’m shooting the messenger here, but I have to point out that this is ridiculously complicated for something that should be simple. Delete and recreate the vdirs every time we do an update to Exchange, really?

    Why not just have a separate vdir for EAC so that we don’t have to worry about this anymore? (Do it in the next CU … Keep the original vdir as-is for anyone who doesn’t mind opening up their EAC to the Internet, but then give us the option of turning off
    EAC on it, and using /eac instead.)

    Or, why not make the CU installer figure this stuff out for us? We’re using Exchange Powershell commands to do all of it, why wouldn’t it be able to keep track of what it needs to do during an update?

    Also this is two years too late … everyone’s already come up with their own set of steps in the meantime. Seems a little odd to call all of these installs unsupported, since they didn’t follow instructions that didn’t exist yet?

    By the way, it seems to work fine if I point the second IIS web site to the same wwwroot as the first, and point the second ECP or OWA vdir to the same directory as the default vdir. Not sure if I did any cumulative updates yet, but it seems like that problem
    should solve itself, since they’re pointed to the same directory? Maybe this should be the officially supported method instead?

  5. Deepak Khandelwal says:

    Hi Greg

    Thanks for sharing. I am trying to configure TMG to pre-Auth (FBA) and FBA authentication on internal and external. You mention above in scenario’s 1 we no longer need the multiple OWA website to make it work. and don’t have to do anything.

    But it is not working for me. the TEST RULE fails if I don’t change the OWA Virtual directory to NTLM and BASIC.

    by default my Exchange 2013 virtual directory is set to following authentication

    ClientAuthCleanupLevel : High
    InternalAuthenticationMethods : {Basic, Fba}
    BasicAuthentication : True
    WindowsAuthentication : False
    DigestAuthentication : False
    FormsAuthentication : True
    LiveIdAuthentication : False
    AdfsAuthentication : False
    OAuthAuthentication : False
    ExternalAuthenticationMethods : {Fba}

    is the setting correct for scenario 1 to work?

    Can you please provide me more details on how to set the scenario 1? will it work in Exchange 2013 without additional website? Do you know any TechNet article on how to do it?

  6. Sam says:

    Hi Greg,

    Could you please explain in detail about "Separating admin/user ECP access" mentioned in the blog.
    I’m new to MS Exchange 2013 and would like to understand benefits of creating multiple virtual directories on CAS
    Examples with screenshots would be great if someone has tested it.

  7. Jalinder Singh says:

    I followed the article now my default exchange web site is not functioning and this is where all external internal users were connecting to. in short i am screwed.

  8. Shawn says:

    Appears to us Forms based auth and Integrated auth are mutually exclusive on the same site, but you document that works fine with Exchange. When I enable FORMs, Integrated is disabled and when I enable Integrated, Forms is disabled. Is that by design?

  9. Second Website for ActiveSync says:

    Would it be possible to configure a second website like this for ActiveSync on Exchange 2013 on premises instead? We really do not need OWA, or ECP, or Outlook Anywhere, or EWS to available to the outside world. If I could move ActiveSync to the secondary
    website, I could then port forward to 443 to the secondary website and greatly reduce the exposure of Exchange to the internet.

  10. Nicholas Poh says:

    @Scott Powers,
    Your concern is more towards the "AdminEnabled" attribute of the ECP virtual directory. If it is set to "false", it can only be used by users to manage their settings. Thus setting it to "false" resolve both issue #1 and #2 because,
    1. ECP site is available from the outside but will only show the user settings
    2. External OWA users can manage their setting since #1 is resolved.

    So, in addition to the steps in the blog,
    1. Set "AdminEnabled" attribute to "false" for your default ECP (accessible via internal and external network).

    2. Set "AdminEnabled" attribute to "true" for the secondary ECP (accessible via internal network only).
    3. Use the secondary ECP to manage the server.

  11. Nicholas Poh says:

    On the issue where applying CU breaks the secondary OWA and ECP, to resolve,

    1) Perform the copy process again. If you stop here, you can access the ECP page but when you tries to login, it may tell you that the authentication failed.
    2) Use Set-OwaVirtualDirectory and Set-EcpVirtualDirectory to set the FormsAuthentication or WindowsAuthentication for both OWA and ECP with the original values you have set previously. You can view the original settingd using Get-OwaVirtualDirectory and Get-EcpVirtualDirectory.
    3) Run IISRESET and the secondary OWA and ECP should be working again.

    I have done this across several CUs (latest CU 8) and it works fine.

    Note: After logging in to the ECP for the first time, sometimes it would show an error page. To resolve, just enter the ECP URL again (example, https://mysecondary/ECP) and the page should load properly.

Comments are closed.