Exchange 2013 en meerdere OWA/ECP virtual directories

Soms kunnen er redenen zijn om op één Exchange 2013 CAS server meerdere /owa (en bijbehorende /ecp) virtual directories te hebben. Bijvoorbeeld voor één van de volgende scenario's.

Afwijkende authenticatie-instellingen

Interne gebruikers landen voor OWA op de /owa virtual directory op de CAS server. Forms-based Authentication (FBA) is geconfigureerd gebruiksvriendelijk in te kunnen loggen op de webpagina.
Externe gebruikers benaderen OWA via een reverse proxy, bijvoorbeeld een KEMP LoadMaster, Forefront TMG of UAG server.

Gebruikers authenticeren tegen de reverse proxy met een webpagina, de reverse proxy gebruikt deze credentials vervolgens om tegen Exchange te authenticeren. De reverse proxy vereist dat Basic authentication ingeschakeld is op de /owa en /ecp virtual directory.

Beheerinterface

Een organisatie vereist dat beheerinterfaces niet vanaf het internet beschikbaar is, intern moeten alle mogelijkheden wel volledig benut worden. Het op de reverse proxy blokkeren van /ecp is geen optie omdat normale gebruikers die virtual directory ook benaderen om hun eigen persoonlijke instellingen te configureren.

Het is mogelijk om toegang tot het beheerdeel, het Exchange Admin Center, uit te schakelen op virtual directory niveau:

Set-ECPVirtualDirectory -Identity "InternalCAS\ecp (default web site)" -AdminEnabled $false

Verkeer vanaf internet zou dus op een /ecp virtual directory moeten landen waarbij het EAC uitgeschakeld is, voor intern verkeer zou deze functionaliteit wel beschikbaar moeten zijn.

Segmentatie

Een derde voorbeeld is de noodzaak voor segmentatie, dat is het in- of uitschakelen van bepaalde functionaliteit. Net als bij de voorgaande twee scenario's is dit iets wat je per virtual directory instelt. Bijvoorbeeld om toegang tot functionaliteit voor een bepaalde groep gebruikers uit te schakelen:

Set-OwaVirtualDirectory -Identity "Contoso\owa (default Web site)" -InstantMessagingEnabled $false -PublicFoldersEnabled $false -ActiveSyncIntegrationEnabled $false

Meerdere sites of meerdere servers?

Een manier om aan bovenstaande eisen te voldoen is een CAS server uit te rollen voor elk scenario. Omwille van redundantie worden dat uiteraard twee CAS servers, dus om zowel OWA met als zonder IM client aan te kunnen bieden hebben we vier CAS servers nodig:





Op Exchange 2007 en 2010 was een alternatief, namelijk het aanmaken van één of meerdere extra /owa virtual directories. Zie bijvoorbeeld de volgende artikelen:

Supportability for multiple OWA/ Exchange Web Sites on Client Access Servers in Exchange Server 2007 and Exchange Server 2007 Service Pack 1
Configuring Multiple OWA/ECP Virtual Directories on Exchange 2010 Client Access Server

Exchange 2013

Vreemd genoeg is het plaatsen van dedicated CAS servers momenteel de enige door Microsoft ondersteunde manier om dit te doen met Exchange 2013. En dat is raar, want de methode voor Exchange 2010 werkt ook in Exchange 2013. En de noodzaak voor een dergelijke opstelling is er nog onverminderd, zie ook diverse discussies over dit onderwerp in de communities:

Multiple owa sites on a single server 2012 with exchange 2013 (mailbox, cas)
Exchange 2013, multiple IIS OWA sites with different authentication
Enable second OWA site with form based authentication

Maar wacht even, zei ik dat het werkte? Bij een klant van mij die ik overgenomen hebt draait een dergelijke opstelling al om zowel Basic als FBA aan te kunnen bieden. Dit werkte goed totdat CU5 werd geïnstalleerd, nu wil de tweede /owa geen Basic authentication meer aanbieden maar alleen FBA. En dan zit je dus "mooi" in een niet-ondersteunde situatie, heel vervelend.

Inmiddels heb ik wat lijntjes uitgegooid om een formele uitspraak van Microsoft te krijgen. Wetende dat mijn klant niet de enige is die dit scenario ingericht heeft en de noodzaak er overduidelijk is lijkt het mij goed dat er snel een duidelijke uitspraak komt. Ofwel dat dit ondersteund is, ofwel een bevestiging dat dit niet zo is alhoewel het ontbreken van het eerste ook al zodanig geïnterpreteerd kan worden.

Tot die tijd raad ik aan om dit scenario niet te implementeren tenzij je gedekt bent door Premier Support of anderszins weet dat je ondersteund bent. Zodra ik meer weet laat ik dit zeker horen.