CAS Proxy 2010

Exchange 2007 Administratoren sollten Sie die Seite CASProxy 2007 anschauen.

Exchange 2013 Administratoren sollten die Seite CASProxy2013 lesen.

Upgrading Outlook Web App to Exchange 2010
http://blogs.technet.com/b/exchange/archive/2009/12/02/453367.aspx
Ein ganz wichtiger und deutlicher Blogeintrag, was der Exchange 2010 CAS macht und was nicht.

Mit Exchange 2010 hat Microsoft die Rolle des Client Access Servers stark erweitert, weil damit auch die MAPI-Clients über den CAS-Server auf das Postfach zugreifen. Ein Exchange 2010 CAS Server ist aus Sicht eines MAPI-Anwenders ein Postfachserver. Aber der CAS-Server ist weiterhin  der einzige Zugangspunkt für Outlook WebApp (der neue Name statt Outlook Web Access), ActiveSync (Push-Mail), POP3 und IMAP4. Allerdings unterstützt die Exchange 2010 Rolle nur die Exchange 2010 Postfachserver direkt. für die Koexistenz mit Exchange 2007 und Exchange 2003 werden die Zugriffe teilweise selbst direkt durchgeführt, an den Exchange 2007 CAS weiter gegeben (Reverse Proxy) oder der Client auf einen anderen CAS-Server umgelenkt.

Direkt, Reverse Proxy oder LegacyURL

Die Exchange 2010 CAS-Rolle unterstützt drei verschiedene Arten, wie Anfragen der verschiedenen Clients weiter verarbeitet werden:

  • Direkt
    Die Exchange 2010 CAS-Rolle greift dann direkt auf den Postfachserver (per MAPI/RPC) zu. Dieser Weg wird immer für Exchange 2010 Postfächer angewendet aber nicht immer für ältere Versionen  der Postfachserver
  • Reverse Proxy
    Die Exchange 2010 CAS-Rolle enthält keinen Code für einen direkten Zugriff auf Exchange 2003 oder Exchange 2007. Aber für bestimmte Zugriff leitet er die Anfragen als Reverse Proxy an den Exchange 2007 CAS oder den Exchange 2003 Server weiter. Der Client spricht also weiter mit dem Exchange 2010 CAS, obwohl die Daten von einem anderen Server kommen. Die Funktion ähnelt der eines Exchange 2003 "Frontend" Servers oder Exchange 2007 CAS-Servers, wobei ein Exchange 2007 CAS diese Funktion nur bereit gestellt hat, wen keine Mailboxrolle installiert war (Konflikt des virtuellen Verzeichnisses /EXCHANGE als OWA2003-Zugriff nud WebDAV-URL)
  • Umleitung/LegacyURL
    Zuletzt gibt es Protokolle, bei denen der Exchange 2010 CAS den Client auf einen anderen Server verweist. Dies passiert z.B. beim OWA-Zugriff oder wenn Sie per MAPI/RPC intern aus versehen den Exchange 2010 CAS-Server angegeben haben aber noch auf Exchange 2007/2003 arbeiten. Dann wird ihr Outlookprofil einfach umgestellt.
  • Autodiscover
    Outlook 2007 und Windows Mobile 6.1 und neuer unterstützen "Autodiscover". Wenn diese Clients also keine Verbindung mehr mit den bekannten Daten aufbauen können, dann führen Sie eine Autodiscover-Erkennung durch, um den Weg zu finden. Es ist daher wichtig, dass die "Autodiscover"-Funktion sehr früh auf Exchange 2010 CAS-Server umgeleitet wird.

Da es sehr viele Client, Server und Protokolle gibt, ist eine Übersicht als Tabelle hilfreich.

Versionsabhängigkeiten

Zum Erstellungszeitpunkt habe ich noch keine ähnliche Übersicht in den Microsoft Dokumenten gefunden. Die Daten müssen daher nicht korrekt sein. Korrekturen nehme ich gerne an.

Die folgende Tabelle zeigt, welche Zugriffe für die verschiedenen Protokolle wie unterstützt werden. Sie werden keine Exchange 2000 oder 5.5 Server mehr finden, da diese nicht mit Exchange 2010 in einer Organisation existieren können.

Protokoll Client Postfach Zugriff

MAPI/RPC

Outlook 2003/2007/2010

2010

Über CAS-Server bzw. CAS-Array auf Postfachserver. Ein direkter Zugriff auf eine Mailboxrolle erfolgt nur für öffentliche Ordner

Outlook XP/2003/2007/2010

2007/2003

Umleitung: Das Outlook Profil wird auf den korrekten Postfachserver umkonfiguriert.

RPC/HTTP

Outlook 2003/2007/2010

2010/2007/2003

Der angesprochene RPC-Proxy baut eine direkte Verbindung zum Mailbox Server auf den Port 6001-6004 auf. Auch über AD-Site-Grenzen hinweg und wenn in der Zielsite kein CAS-Server mit aktiviertem Outlook AnyWhere steht.

OWA

Browserunabhängig

2010

Direkt auf Postfachserver

Browserunabhängig

2007

Umleitung auf die externe URL des Exchange 2007 CAS in der jeweiligen AD-Site
Nur wenn der 2007CAS nicht in einer "Internet Facing AD-Site" ist, erfolgt ein Reverse Proxy. Dazu muss aber ein Exchange 2007 Verzeichnis auf den Exchange 2010-Server "kopiert" werden. Exchange 2010 mach aber keinen Reverse Proxy auf einen Exchange 2007 CAS in der gleichen AD-Site.

Browserunabhängig

2003

Laut http://technet.microsoft.com/de-de/library/bb310763.aspx würde der Zugriff als Reverse Proxy auf den Exchange 2003 Mailbox Server gehen, wenn der Client //Exchange" oder "/Public" eingegeben hat.
Alternativ kann man aber auch über die Konfiguration einer "LegacyURL" den Client auf den alten OWA-Zugang umleiten.

ActiveSync

WM6.1/6.5
(EAS-Version 12.1 und höher)

2010/2007

Autodiscover/Redirect
aber es geht auch Reverse Proxy auf Exchange 2007 CAS, aber nur, wenn der Exchange 2007 keine External URL hat, ansonsten erfolgt eine Umleitung

WM6.0 und älter, Nokia, Android, iPhone
(EAS Clientversion 12.0 und älter

2010

Direkt

WM6.0 und älter, Nokia, Android, iPhone
(EAS Clientversion 12.0 und älter

2007

Reverse Proxy auf Exchange 2007 CAS
Aber nur, wenn der Exchange 2007 keine External URL hat, ansonsten erfolgt eine Umleitung

any

2003

Reverse Proxy auf Exchange 2003 Backend Server (Auf dem virtuellen Verzeichnis "/Microsoft-Server-ActiveSync" muss integrierte Anmeldung aktiv sein !)

OAB

Outlook 2007/2010

2010/2007/2003

Direkt

Autodiscover

Outlook 2007/2010

2010/2007/2003

Direkt
Hinweis: Autodiscover muss über 2010 laufen, da ein Exchange 2007 CAS den neueren 2010 CAS zurückgibt.

EWS

Outlook 2007/2010

2010/2007/2003

Wird per Autodiscover ermittelt

POP3
IMAP4

Beliebiger Client

2010

Direkt

Beliebiger Client

2007

Reverse Proxy zum Exchange 2007 CAS

Beliebiger Client

2003

Direkt

Authentifizierung = NTLM

Damit ein CAS in einer "Internet Facing Site" auf einen anderen CAS in einer anderen nicht direkt erreichbaren Site erreicht, muss auf dem Zielserver die integrierte Anmeldung aktiv sein. Es reicht aber, wenn eine WebSeite diese Anmeldung anführt. Die CAS-Server schauen im Active Directory nach, welche Webseite im anderen Standort genutzt werden.

Seit Exchange 2010 funktioniert dies mit dem "new-OWAVirtualDirectory" commandlet. Vergessen Sie danach nicht ,den IIS mit einem "IISRESET /noforce" durchzustarten.

Auf dem Internet zugewandten Server können Sie natürlich weiter per Formular eine Anmeldung durchführen.

ExternalURL und Redirect

Exchange 2007 und höher nutzen die Konfiguration von "ExternalURL", um allen Servern bekannt zu geben, welcher Server wie extern zu erreichen ist. S kann ein Exchange Server, der von einem Client erreicht wird, schnell seine Zuständigkeit klären. Der Server prüft also, ob es zum Postfach des Benutzers vielleicht einen "besseren CAS" gibt. Dazu nutzt Exchange die Active Directory Standorte und Dienste. Gibt es z.B. eine CAS-Server, der in der gleichen AD-Site wie das Postfach liegt oder die gleiche Exchange Version wie der Postfachserver hat, dann wird der Client auf dessen ExternalURL umgeleitet.

So erreicht Exchange in großen Umgebungen, dass ein Client immer den "besten" Server verwendet, auch wenn er beim erste Kontakte den "falschen" CAS erwischt. Umgekehrt kann ein Administrator so natürlich auch steuern, welcher CAS direkt vom Client angesprochen wird und welcher im Rahmen der Möglichkeiten durch den ersten als Proxy erreicht wird.

"LegacyURL"

Wie sie auf der Tabelle ersehen können, kann die Exchange 2010 CAS-Rolle nicht mehr direkt einen Zugriff auf OWA für auf Exchange 2007 oder 2003 gewähren. Laut Microsoft wurde der erforderliche Code einfach nicht entwickelt. Statt dessen müssen Sie in einer gemischten Umgebung auf dem Exchange 2010 CAS konfigurieren, unter welcher URL die Anwender nun auf den Exchange 2007 OWA oder Exchange 2003 OWA zugreifen können. Greift ein Anwender dann auf den Exchange 2010 CAS-Server zu und meldet sich mit einem Postfach an, welche noch nicht auf Exchange 2010 migriert ist, dann erfolgt eine Umleitung auf dem Client (HTTP Redirect) auf eine neue URL.

Im Laufe der Migration müssen Sie also mehrere Schritte in der richtigen Reihenfolge durchlaufen

  • "Alter" OWA-Zugang mit einem neuen Namen und Zertifikat veröffentlichen
  • Diese URL in den Exchange 2010 CAS-Einstellungen hinterlegen
  • Die Exchange 2010 Server mit dem alten Namen veröffentlichen

Über diesen "Trick" müssen sich die Anwender keine neue URL merken, sondern greifen wie bisher auf ihre bekannte URL zu, aber sehen den "neuen" Anmeldeschirm. Sobald Sie sich aber mit einem "alten" Postfach (2003 oder 2007) anmelden, wird der Client auf die alte URL gesendet. Wenn Sie die "Formularbasierte Anmeldung" nutzen, dann muss der Anwender sich nicht einmal neu anmelden.

Kniffliger wird es, wenn Sie den OWA-Zugriff nicht direkt veröffentlicht haben, sondern z.B. ein Portal vorgeschaltet haben oder eine starke Authentifizierungslösung integriert haben, dann bedarf es zusätzlicher Schritte, um den Anwendern eine Doppelanmeldung zu ersparen.

Beim Zugriff auf OWA im internen LAN ist die Pflege der LegacyURL erst einmal nicht erforderlich, da intern der Exchange 2010 CAS die Client dann auf einen Exchange 2007 CAS-Server bzw. Exchange 2003 Postfachserver umleitet. Beim Zugriff aus dem Internet hingegen kommt es darauf an, ob sie direkt von Exchange 2003 nach Exchange 2010 migrieren oder vielleicht Postfächer auf 2010, 2007 und 2003 liegen.

Wenn Sie Exchange 2007 und 2003 parallel betreiben, dann wissen sie ja schon von CASProxy 2007, dass ein Exchange 2007 CAS-Server als Reverse Proxy auch einen Exchange 2003 OWA-Zugriff erlauben kann. Dazu muss der Exchange 2007 CAS aber auf den Exchange 2003 Backendserver per HTTP zugreifen können und der Server mit der Exchange 2007 CAS-Rolle darf keine Mailboxrolle betreiben. Dieses Problem ist aber nicht mit Exchange 2010 neu, sondern schon seit Exchange 2007 der Fall.

Für die Konfiguration der LegacyURL bedeutet dies aber:

  • Exchange 2010/2003 only
    Veröffentlichen Sie den bisherigen Exchange 2003 OWA-Zugang mit einem neuen Zertifikat und einer neuen URL
  • Exchange 2010/2007/2003
    Veröffentlichen Sie den bisherigen Exchange 2007 CAS-Server mit einem neuen Zertifikat und einer neuen URL.

Die LegacyURL sollte dann auf diesen zweiten Namen verweisen. Der Betrieb beider Zugänge mit dem gleichen Namen und der gleichen URL ist offiziell nicht möglich.

"LegacyURL" mit Single IP/Zertifikat

Nicht jede Firma kann eine zweite offizielle IP-Adresse bereit stellen und über die Firewalls veröffentlichen. Zudem ist für Anwender der Wechsel nicht immer einfach. Daher werden viele Administratoren nach einer alternativen Lösung suchen. Und es sind Lösungen denkbar, bei denen mit einer IP-Adresse oder vielleicht sogar mit einem Namen gearbeitet werden kann

SAN-Zertifikat

Eine offizielle Lösung ist der Einsatz von SAN-Zertifikaten für den OWA-Zugang. Exchange 2007 Administratoren können diesen Weg schon für die Veröffentlichung von OWA und Autodiscover. Über diesen Trick können sie von außen mehrere Namen auf die gleiche IP-Adresse veröffentlichen und trotz SSL mit dem Hostheader die Datenströme zu verschiedenen Diensten lenken.

Reverse Proxy für 2003/2010 ohne 2007 

Wer nur Exchange 2010 und Exchange 2003 betreibt, könnte eine Konfiguration finden, da Exchange 2010 für OWA nur die URL /"owa" verwendet und Exchange 2003 die URLs "/exchange", "/public" und "exchweb". Es könnte also möglich sein, dass ein vorgeschalteter Reverse-Proxy die URLs einfach an den richtigen internen Server weiter leitet oder dass ein ReverseProxy-Modul auf dem Exchange 2010-Server die Anfragen an die bislang nicht belegten URLs zum Exchange 2003-Server weiter gibt.

Leider konnte ich diese "Baselkonfiguration" noch nicht selbst testen, da meine Kunden lieber ein paar Euro für ein Zertifikat und eine LegacyURL investieren.

Reverse Proxy mit "Portalseite"

Eine ganz elegante Möglichkeit mehrere Exchange Versionen zu veröffentlichen ist der Umweg über ein Portal, wie es z.B. auch ein ISA/TMG bereit stellen kann. Die Anmeldung erfolgt dabei nicht mehr am Exchange Server sondern an am Portalsystem. Diese kann dann anhand des Benutzers einfach heraus finden, auf welchem System dieser liegt (z.B. HomeMDB oder RecipientType) um dann die Anfragen an den passenden CAS oder Frontend Server weiter zu leiten.

So eine Lösung hat oft noch den zweiten Vorteil, dass die einmal erfolgte Anmeldung auch für anderen Dienste genutzt werden kann und sogar starke Authentifizierungen elegant eingebunden werden können. Neben TMG/ISA gibt es natürlich auch andere Anbieter wie z.B. Checkpoint, Citrix Access Gateway und Juniper (SSL Gateway) und andere.

Weitere Links