Exchange Server: Separate OWA Virtual Directory

Während der Installation eines Exchange Servers, werden automatisch zwei virtuelle Verzeichnisse für Outlook on the Web, besser bekannt als Outlook Web App (OWA), angelegt. Eines für die Mailbox-Rolle und eines für den FrontEnd. Letzterer dient als direkter Zugriffspunkt für die Anwender und dieses ist oft gemeint, wenn von OWA die Rede ist. Über das OWA oder besser gesagt das äquivalente ECP Virtual Directory wird auch der Exchange Server verwaltet. Veröffentlicht man das Standard OWA im Internet, veröffentlicht man zwangsläufig auch das Exchange Admin Center (EAC) im Internet. Und die meisten Admins wollen das sicher nicht.

Darüber hinaus kann man mit dem nachfolgend beschriebenen Verfahren eigene OWA mit spezifischen Domänen erstellen, wenn man mehrere öffentliche Domänen hostet.

Um das EAC aus dem Internet zu bekommen, konfigurieren wir als erstes eine weitere IP-Adresse. Dazu kann man ruhig die bestehende Netzwerkkarte nutzen. Um zu vermeiden, dass die zusätzliche IP automatisch in DNS registriert wird, hilft ein Parameter, der mit Windows Server 2008 eingeführt wurde: SkipAsSource. In einer administrativen Powershell wird dieser Parameter über Set-NetIPAddress, wenn die IP bereits konfiguriert wurde, oder über New-NetIPAddress festgelegt.

PS C:\> New-NetIPAddress -IPAddress 192.168.47.20 -InterfaceAlias "Ethernet" -SkipAsSource $true -PrefixLength 24

IPAddress         : 192.168.47.20
InterfaceIndex    : 8
InterfaceAlias    : Ethernet
AddressFamily     : IPv4
Type              : Unicast
PrefixLength      : 24
PrefixOrigin      : Manual
SuffixOrigin      : Manual
AddressState      : Tentative
ValidLifetime     : Infinite ([TimeSpan]::MaxValue)
PreferredLifetime : Infinite ([TimeSpan]::MaxValue)
SkipAsSource      : True
PolicyStore       : ActiveStore

Der Parameter bewirkt nicht nur, dass die so markierte IP-Adresse nicht im DNS registriert wird. Sie wird zur Kommunikation mit anderen Geräten niemals als Quelle verwenden. Das macht es einfacher, die IP-Adresse in Firewalls freizuschalten, da nur eine kleine Anzahl an Regelwerken erstellt werden muss. In diesem Fall ist nur eine Freischaltung der Prtokolle https (tcp/443) und http (tcp/80) für die Umleitung nach https.

Als nächsten Schritt erstellt man im IIS Manager eine neue Webseite, die auf der neuen IP lauscht und einen eigenen Host Name eingetragen bekommt. Letzteres könnte man zwar weglassen, dann kann die IP aber nicht mehr für andere Webseiten für bspw. weitere OWA-Verzeichnisse genutzt werden.

Das Verzeichnis (Content Directory) ist dabei unerheblich. Dort wird außer der IIS-Konfigurationsdatei nichts weiter abgelegt. Wichtig ist nur, dass der Worker-Prozess lesend darauf zugreifen kann. Dazu eignet sich am besten die serverlokale Gruppe IIS_IUSRS, die auf den Ordner berechtigt wird.

Für die nachfolgenden Anpassungen, legen wir eine Kopie der owa- und ecp-Verzeichnisse an. Diese liegen im Ordner %ExchangeInstallPath%\FrontEnd\HttpProxy, also bei einer Standardinstallation ist das C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy. Die Kopien werden nach Belieben umbenannt.

Nun legt man in der Exchange Management Shell das Virtual Directory für OWA und ECP an. Dabei ist mittels Path-Parameter auf die Kopie zu verweisen.

PS C:\> New-OwaVirtualDirectory -WebSiteName "EAC" -Path "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\eac-owa" -InternalUrl $Null -ExternalUrl $Null
PS C:\> New-EcpVirtualDirectory -WebSiteName "EAC" -Path "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\eac-ecp" -InternalUrl $Null -ExternalUrl $Null

Dass ich weder intern noch extern einen Url angegeben habe, liegt daran, dass ich vermeiden möchte, dass der Autodiscover-Prozess diese an die Benutzer weitergibt. Dass diese Url weggelassen werden, ist dem Exchange egal und schränkt die Funktionalität nicht ein. Apropos Einschränkung. Wir möchten das EAC vom Internet abschneiden. Also ist das ECP der Standardwebseite noch zu konfigurieren und die Einstellungen abschließend zu prüfen.

PS C:\> Set-EcpVirtualDirectory "ecp (Default Website)" -AdminEnabled $false
PS C:\> Get-EcpVirtualDirectory | ft Name, Server, AdminEnabled

Name                   Server AdminEnabled
----                   ------ ------------
ecp (Default Web Site) EXSRV  False
ecp (EAC)              EXSRV  True

Soweit ist die Separierung abgeschlossen. Geht man mit dem Browser auf die Webseite, erscheint das neue OWA. Aber Moment, wir müssen zum EAC immer über das ECP Virtual Directory gehen. Sonst bekommt man als Admin nach der Anmeldung den Fehler 500: “Da hat etwas nicht geklappt. Für Admin wurde kein Postfach gefunden.”. Es wäre doch ganz geschmeidig, wenn man direkt zum EAC umgeleitet wird, wenn man die Seite öffnet.

Also zurück in den IIS Manager und auf die neue Webseite gehen. In den SSL-Einstellungen den Haken SSL erforderlich entfernen, diesen dann aber für die virtuellen Verzeichnisse owa und ecp wieder setzen.

Nun setzen wir eine Umleitung im Root der Webseite und entfernen die Umleitung in den virtuellen Verzeichnissen owa und ecp.

Ein Teil der Einstellungen werden in die config.web der ecp– und owa-Ordner geschrieben, weshalb man peinlichst darauf achten müsste, ob sie sich auf das OWA für die Anwender auswirken. Das ist der Grund, warum Kopien dieser Ordner erstellt wurden. Somit ist der Weg frei, weitere IIS Einstellungen vorzunehmen, ohne auf Abhängigkeiten zum OWA der Anwender achten zu müssen.

Um es noch ein wenig bequemer zu haben, können wir die Anmeldedomäne vorgeben und müssen uns nur mit dem Benutzernamen anmelden. Ein Sicherheitsrisiko ist es nicht, da das EAC nur intern verfügbar ist und die Anwender ihre Domäne kennen, vorausgesetzt es wird keine separate Admin-Domäne verwendet. Das muss man im Einzelfall abwägen. Wer es gern bequem hat, führt folgenden Befehl aus.

PS C:\> Set-OwaVirtualDirectory "owa (EAC)" -DefaultDomain contoso.com -LogonFormat UserName

Wie eingangs erwähnt, dient dieses Verfahren nicht nur der Härtung des Exchange Servers. Vielmehr kann man so den Anwendern eigene OWA mit ihren individuellen Domänen anbieten.