Outlook über HTTP und ExternalURL

Diese Seite bezieht sie primär auf die Nutzung von Outlook AnyWhere mit Exchange 2010. Aber da diese Funktion bei einer Migration nach Exchange 2013/2016 erforderlich ist, ist die Seite immer noch aktuell.

Exchange 2013 und Exchange 2016 unterscheiden für Outook AnyWhere den Zugriff von Intern und Extern. Exchange 2010 allerdings nicht.

Outlook kann sich zukünftig nur noch MAPI/HTTP verbinden. Seit Exchange 2013 ist eine Verbindung per MAPI/TCP oder RPC/TCP nicht mehr möglich und nur noch RPC/HTTP oder MAPI/HTTP möglich. Auch der Zugriff per RPC/HTTP ist bereits abgekündigt, so dass zukünftig nur noch MAPI/HTTP übrig bleibt. Aber auch in Migrationsszenarien, bei denen z.B. von Exchange 2010 auf Exchange 2013/2016 migriert wird, ist der Wechsel weg von MAPI/TCP (=RPC/TCP) vorgezeichnet. Die neuen Exchange 2013/2016 CAS-Zugangspunkte unterstützen dieses Protokolle nicht nur für eigene Postfächer sondern auch als Reverse Proxy auf noch nicht migrierte Postfächer nicht mehr. Wer also über einen Exchange 2013/2016 Server auf sein Exchange 2010-Postfach zugreifen will, muss "Outlook AnyWhere" dort aktivieren.

Ehe der erste Client über einen Exchange 2013 oder neuer Server auf bestehende Exchange 2010 Systeme zugreifen will, müssen Sie dieses Thema gelöst haben.

..., in order to allow your Exchange 2013 Client Access Server to proxy connections to your Exchange 2007/2010 servers, you must enable and configure Outlook Anywhere on all of the Exchange 2007/2010 CAS in your organization.
Quelle: Outlook Anywhere Deploying Outlook Anywhere https://technet.microsoft.com/en-us/library/bb123741%28v=exchg.150%29.aspx

 

Also sollten sich alle Administratoren Gedanken machen, wie sie Exchange umkonfigurieren. Schließlich möchten Sie nicht erst mit der Migration des Postfachs feststellen, wenn etwas nicht mehr geht, weil die Konfiguration nicht passt. Da kann aber doch so einiges schief geben, wenn Sie MAPI/HTTP oder RPC/HTTP mal eben aktivieren wollen.

Ausgangssituation

Wenn Sie einen Exchange 2010 Server oder früher einsetzen und nichts im Bereich "Outlook Anywhere" gemacht haben, dann ist auch nichts aktiv. Das können Sie schon am Clients über die Autodiscover-Abfragen sehen:

<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
  <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
    <User>
      <DisplayName>Carius, Frank</DisplayName>
      <LegacyDN>/o=msxfaqEX01/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Carius Frank4dd</LegacyDN>
      <AutoDiscoverSMTPAddress>frank.carius.ext@msxfaq.de</AutoDiscoverSMTPAddress>
      <DeploymentId>xxxxxxxx-xxxx-xxxx-xxxxxe</DeploymentId>
    </User>
    <Account>
      <AccountType>email</AccountType>
      <Action>settings</Action>
      <Protocol>
        <Type>EXCH</Type>
        <Server>casarray.msxfaq.net</Server>
        <ServerDN>/o=msxfaqEX01/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=casarray.msxfaq.net</ServerDN>
        <ServerVersion>7383807B</ServerVersion>
        <MdbDN>/o=msxfaqEX01/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=casarray.msxfaq.net/cn=Microsoft Private MDB</MdbDN>
        <AD>dc01.com.msxfaq.net</AD>
        <ASUrl>https://casarray.msxfaq.net/EWS/Exchange.asmx</ASUrl>
        <EwsUrl>https://casarray.msxfaq.net/EWS/Exchange.asmx</EwsUrl>
        <EcpUrl>https://casarray.msxfaq.net/ecp/</EcpUrl>
        <EcpUrl-um>?p=customize/voicemail.aspx&amp;exsvurl=1</EcpUrl-um>
        <EcpUrl-aggr>?p=personalsettings/EmailSubscriptions.slab&amp;exsvurl=1</EcpUrl-aggr>
        <EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?exsvurl=1&amp;IsOWA=&lt;IsOWA&gt;&amp;MsgID=&lt;MsgID&gt;&amp;Mbx=&lt;Mbx&gt;</EcpUrl-mt>
        <EcpUrl-ret>?p=organize/retentionpolicytags.slab&amp;exsvurl=1</EcpUrl-ret>
        <EcpUrl-sms>?p=sms/textmessaging.slab&amp;exsvurl=1</EcpUrl-sms>
        <OOFUrl>https://casarray.msxfaq.net/EWS/Exchange.asmx</OOFUrl>
        <UMUrl>https://casarray.msxfaq.net/EWS/UM2007Legacy.asmx</UMUrl>
        <OABUrl>http://casarray.msxfaq.net/OAB/c9cdca9c-c307-4a54-8542-eb79515031e5/</OABUrl>
      </Protocol>
      <Protocol>
        <Type>WEB</Type>
        <Internal>
          <OWAUrl AuthenticationMethod="Basic, Ntlm, WindowsIntegrated">https://casarray.msxfaq.net/owa/</OWAUrl>
          <Protocol>
            <Type>EXCH</Type>
            <ASUrl>https://casarray.msxfaq.net/EWS/Exchange.asmx</ASUrl>
          </Protocol>
        </Internal>
        <External>
          <OWAUrl AuthenticationMethod="Fba">https://owa.msxfaq.com/owa/</OWAUrl>
          <OWAUrl AuthenticationMethod="Fba">https://owa.msxfaq.de/owa/</OWAUrl>
          <Protocol>
            <Type>EXPR</Type>
            <ASUrl>https://owa.msxfaq.com/EWS/Exchange.asmx</ASUrl>
          </Protocol>
        </External>
      </Protocol>
      <AlternativeMailbox>
        <Type>Delegate</Type>
        <DisplayName>room1</DisplayName>
        <SmtpAddress>room1@msxfaq.de</SmtpAddress>
        <OwnerSmtpAddress>room1@msxfaq.de</OwnerSmtpAddress>
      </AlternativeMailbox>
    </Account>
  </Response>
</Autodiscover>

Das einzige vom Exchange Server angebotene Protokoll ist "EXCH". Entsprechend findet sich in der Exchange Management Console auch ein "False" in der Spalte Outlook Anywhere.

Ehe Sie hier kein "Enable Outlook Anywhere" machen, können Sie natürlich auch keine Eigenschaften bearbeiten. Aber Sie können hier schon sehen dass Sie später einen "External Hostname" brauchen und dem Client eine Authentifizierung mitgeben können.

Weitere Einstellungen sind natürlich über die PowerShell möglich.

Wenn Sie in solch einer Umgebung Exchange 2013 oder Exchange 2016 installieren, dann wird dennoch Outlook Anywhere nicht aktiviert. Ein Client in einer "Mischumgebung", bei denen die Server kein MAPI/RPC mehr unterstützen, bieten von sich aus weder Outlook Anywhere noch MAPI/HTTP an.

Ehe sie nun aber mal schnell mit einem Mausklick "Outlook Anywhere" aktivieren, sollten Sie sich der Tragweite bewusst sein.

Falle: ExternalURL

Alle Clients, die sich per Outlook Anywhere oder MAPI/HTTP verbinden, nutzen weiterhin die Exchange WebServices für Funktionen wie:

  • OAB Download
  • Free/Busy-Abfragen
  • OOF-Einstellungen setzen
  • UM-Zugriffe

Seit Exchange 2007 werden für die entsprechenden virtuellen Verzeichnisse nach "InternalURL" und "ExternalURL" unterschieden. Die meisten Administratoren betrachten diese URLs nur für die Serververöffentlichung, also dass ein Server "kennt", welcher andere Server von extern erreichbar sind um die Clients dann ggfls. dorthin umzuleiten. Diese Daten werden aber auch vom Autodiscover-Dienst genutzt, um den Client den Weg zu weisen. Und hier sollten Sie wissen, dass die "InternalURL" nur für das Protokoll MAPI/TCP (EXPR) ausgeliefert wird. Für RPC/HTTP als auch MAPI/HTTP werden aber generell die ExternalURLs ausgeliefert, selbst wenn die Clients intern sind.

Das hat umfangreiche Auswirkungen auf ihre Umgebung, z.B. wenn Sie intern einen ganz anderen Namensraum, verwenden und die externen URLs von innen gar nicht auflösbar sind oder "ungünstig" über Proxy-Server und Firewalls geroutet werden.

Eine Lösung wäre natürlich, die Hostnamen der externen URLs auch intern über SpliDNS oder PinpointDNS DNS-Zonen auf die internen Server zu verweisen. Allerdings sollten sie vorher natürlich sicherstellen, dass die Zertifikate auf den Servern auch den Namen erhalten.

Durch die DNS-Einträge bekommen nun aber auch andere Clients per Autodiscover nicht nur diese Urls, sondern versuchen diese auch intern zu erreichen. Das muss ja nicht immer ein Windows PC in der Domäne sein, der automatisch ihrer AD-Integrierten Zertifizierungsstelle vertraut. Damit könnten also Zertifikatswarnungen bei diesen Clients erscheinen, die nun per DNS direkt beim internen Server landen.

Ich bin schon länger ein Verfechter von  "Split-DNS", bei der ein Dienst immer den gleichen Namen bzw. URL hat und der Ort des Clients und der Weg des Zugriffs nicht relevant ist. In dem Fall haben Sie diese Herausforderungen schon gelöst.

Outlook Anywhere Hostname

Anders als bei der Konfiguration für die virtuellen Verzeichnisse gibt es beim Outlook Anywhere Hostname keine Unterscheidung nach "Intern" und "extern". Es wird einfach "der Name" durch Autodiscover an die Clients gegeben. Spätestens hier ist klar, dass natürlich dieser Name nicht nur extern, sondern auch extern, sondern auch intern auflösbar und erreichbar sein muss.

Wenn Sie sich nicht alle Optionen verbauen wollen, heute oder in Zukunft einmal auch auch aus dem Internet ohne VPN mit MAPI/HTTP oder RPC/HTTP zu arbeiten, sollten Sie hier unbedingt einen "öffentlichen Namen" verwenden. Aber auch hier gibt es einige Dinge zu berücksichtigen.

  • Zertifikat
    Auch weil Sie für so einen Namen natürlich auch ein passendes öffentliches Zertifikat bekommen können.
  • Internet Zoneneinstellungen
    Der Internet Explorer und andere Windows Programme unterscheiden schon, ob eine URL in der "Intranet-Zone" oder im Internet ist. Wenn ihr Forest aber z.B. "msxfaq.intern" heißt aber der RPC-Server nun "rpc.msxfaq.net" nutzt, dann ist das für den Client erst mal ein "Externer Rechner" an den er vielleicht nicht mal eben so seine Anmeldedaten sendet.
  • Kerberos und SPN
    In die gleiche Richtung geht die Anmeldung mit Kerberos. Solange das CASARRAY kein SPN für den FQDN hat, kann der Client kein Kerberos-Ticket für den Server erhalten. Der Windows Server hat nämlich nur seinen internen FQDN, z.B. "HOST/ex2016.msxfaq.intern" registriert. Wenn Sie also Kerberos nutzen wollen, müssen sich auch hier mitarbeiten
  • HTTP-Proxy
    Exchange ist zwar ein RPC-Proxy, aber auf dem Weg von Outlook zu Exchange RPC-Proxy wird HTTPS genutzt und wenn auf dem Client hier ein "Surf-Proxy" eintragen ist, dann kann auch Outlook gezwungen sein, über diesen Proxy den Weg zum Exchange zu suchen. Das kann "ungünstig" sein.
  • RPC/Proxy ist nicht mit Erreichbarkeit aus dem Internet gleichzusetzen
    Nur weil sie ihre Exchange Server per Outlook Anywhere mit einem öffentlichen Namen konfigurieren ist das nicht mit einer externen Erreichbarkeit gleichzusetzen. Davor steht natürlich immer die Firewall oder ein Reverse Proxy. Wenn der Dienst auf dem Internet nicht erreichbar ist, d.h. die haben den Service nicht veröffentlicht, dann besteht keine "Gefahr". Wer den Zugriff nur für "Trusted Clients" zulassen will, kann dies über VPNs, DirectAccess oder IPSec erreichen.

Und das sind noch nicht alle Dinge, wie ich an einigen "Fallen" sichtbar machen möchte.

Falle: Erster RPC/HTTP-Host und Multi Site

Ein Server ist immer der der erste in der Reihe. Das bedeutet aber auch, dass mit der Aktivierung des ersten "Outlook AnyWhere"-Servers in einer Topologie mit mehreren Servern alle anderen Server noch keine solche Funktion haben. Das hindert Autodiscover aber nicht daran, diesen neuen Zugang auch allen anderen Clients anzubieten. Wenn sie mehrere Exchange Server in unterschiedlichen Standorten stehen haben, dann kann es passieren, dass ein Mitarbeiter in Asien über den ersten Server in Deutschland versucht auf sein Postfach in Asien zuzugreifen.

Das ist der "normale Weg", wen Sie wirklich nur genau einen Übergang in das Internet mit einer Exchange Veröffentlichung hätten. Nun werden Sie kontern, dass dies ja nur für "externe Clients" gilt aber die internen Clients ja pro problemlos weiter per MAPI/TCP arbeiten können. Natürlich können die Anwender so arbeiten aber sind Sie sicher, dass es auch "stabil" möglich ist?. Outlook ist in der Hinsicht etwas empfindlich und wenn die Verbindung per TCP zum Exchange Server nicht möglich ist, dann versucht er es eben über HTTPS. Das ist aus seiner Sicht sowieso das "bessere" Protokoll.

Und tatsächlich habe ich es schon oft erlebt, dass ein interner Client über "Outlook AnyWhere" arbeitet, obwohl er eigentlich intern auch problemlos per TCP direkt mit seinem Server kommunizieren konnte. Der häufigste Trigger für solch ein Fehlverhalten war eine temporäre Unterbrechung der bestehenden TCP-Verbindung, die Outlook zum Wechsel auf HTTP veranlasst hat. Und das passiert speziell mit WLAN gar nicht mal selten

  • LAN zu WLAN Wechsel
    Der Anteil an Notebooks nimmt von Tag zu Tag zu und für den Einsatz im Büro gibt es Docking-Units, über die Strom, Tastatur, Bildschirm aber auch Netzwerk bereitgestellt wird. Um den Notebook mit zu nehmen drückt der Anwender einen Knopf und nimmt den Computer mit. Die LAN-Verbindung bricht ab (vergleichbar zu Stecker gezogen) und das Notebook wechselt in das WLAN. Für Outlook ist dies aber ein "Verlust" seiner geliebten TCP-Verbindung. Also versucht er es per HTTP. Irgendwann hat er wieder Verbindung und kommt per HTTP an den Server ran. Es gibt keinen Grund für Outlook wieder zurück zu schwenken.
  • WLAN-Wechsel
    Gerade die "ultradünnen Tablets" (z.B. Microsoft Surface) haben gar keinen RJ45-Netzwerkstecker mehr und wer kein Dock hat, wird die WLAN-Verbindung sogar als reguläre Netzwerkverbindung nutzen. Auch ein WLAN ist nicht immer verfügbar. Funkzellenwechsel durch den Standortwechsel sind ja noch erklärbar aber selbst am gleichen Ort kann eine Verbindung auch einmal unterbrochen werden, z.B. weil eine Funkzelle einfach überlastet ist oder Energiesparfunktionen zuschlagen.

Outlook recht es, wenn die bestehende TCP-Verbindung zu einem Exchange Server gekappt wird, um MAPI/TCP zu verlassen. Es loht sich also schon einmal die IISLogs auszuwerten, welche internen Clients hier auftauchen und ggfls. diesen internen zugriff zu unterbinden. Das ist aber gar nicht so einfach da über 443 natürlich auch legitime Zugriffe auf /EWWS, /OAB etc. erfolgen. Eine Lösung sieht so aus, dass der Outlook AnyWhere-Hostname auf eine andere IP-Adresse verweist, die letztlich beim gleichen Server oder Loadbalancer landet. So können Sie aber anhand der Ziel-IP sehr einfach Zugriffe erkennen (Stichwort NetFlow) und sogar blockieren ohne dass Sie gleich beim Loadbalancer ein Layer7-Proxying mit URL-Inspektion umsetzen müssen.

Gehen Sie daher davon aus, dass durch die Aktivierung von HTTP als Zugangsprotokoll eine gewisse Anzahl an Clients diesen Weg wählen, auch wenn TCP möglich wäre.

Falle: viele RPC/HTTP-Host und Multi Site

Wenn Sie aber schon mehrere Server an unterschiedlichen Standorten betreiben, dann sollten Sie je Standort natürlich auch den Zugriff per HTTP (sei es RPC/HTTP oder MAPI/HTTP) mit einem eigenen Namen erlauben. Der eigene Namen ist wichtig, damit die Clients möglich direkt einen Zugriffspunkt in der Site finden, in der auch das Postfach liegt. Hier gibt es durchaus eine Affinität. Es wäre sehr ungeschickt wenn alle Zugangspunkte den gleichen Namen hätten und per DNS Round Robin ein Client in Asien auf eine FE-Rolle in Europe zugreift, der im Hintergrund die Anfrage dann wieder nach Asien als Proxy weiter gibt.

Es loht sich also schon einmal die IISLogs auszuwerten, welche internen Clients aus welcher Site bei den jeweiligen Servern auftauchen.

Das bedeutet im Falle von RPC/HTTP dann aber auch, dass all diese Namen natürlich auch aus dem Internet auflösbar und erreichbar sein müssen, zumindest wenn Sie diesen Anwendern einen Zugriff auf ihr Postfach aus dem Internet und ohne VPN erlauben wollen. Berücksichtigen Sie dies bei der Planung von Reverse Proxy Server und Internetübergängen.

Es ist aber nicht zwingend erforderlich, dass nun jeder Standort mit einem Exchange Server auch aus dem Internet erreichbar sein muss. Die Exchange Server arbeiten durchaus als Proxyserver und geben Anfragen die irrtümlich bei ihnen gelandet sind, auch entsprechend weiter. Sie können also intern pro Standort sehr wohl unterschiedliche Namen verwenden und von extern all diese Namen auf einen Reverse Proxy leiten, der die Daten dann intern über ihr eigenen WAN weiter gibt. Richtig sinnvoll ist das aber nicht, da Sie damit Umwege und längere Latenzzeiten provozieren.

In jedem Standort mit Exchange Servern sollte es daher auch möglich sein, diese über Firewalls und Reverse Proxy zu veröffentlichen. Wenn dies nicht möglich ist, dann frage ich etwas provokativ ob dieser Standort dann überhaupt einen eigenen Exchange Server betreiben sollte oder nicht besser die Postfächer in der Zentrale oder gleich in der Cloud liegen sollten.

Falle: Authentifizierung und Zoneneinstellungen

Wenn wir einmal Exchange 2003 ignorieren, bei dem Sie gemäß OA Server erst noch den RPC Proxy mit installieren mussten, dann ist bei Exchange 2007/2010 diese Komponente in der Regel schon vorhanden aber per Default erst einmal nicht aktiv. Sie aktivieren RPC/HTTP einfach per Mausklick oder PowerShell und im IIS wird das Verzeichnis /RPC entsprechende konfiguriert. Hier müssen Sie nun zwischen der Authentifizierung unterscheiden, die Autodiscover dem Client mitteilt und die vom IIS in einer 403.1-Antwort (Access denied - bitte Anmeldedaten senden) an den Client gemeldet wird.

Bei einem Zugriff aus dem Internet wird "Kerberos" natürlich nicht funktionieren und selbst NTLM ist nicht unbedingt zuverlässig, wenn Proxy-Server dazwischen den Header verändern. (Siehe auch OA Proxy u.a.) Insofern kann hier "Basic-Auth" erforderlich sein. Es hängt dann vom Reverse-Proxy davor ab, welche Authentifizierung dieser vom Client abverlangt.

Internet aber funktioniert natürlich NTLM und bei richtiger Konfiguration auch Kerberos, d.h. der Server bietet es an und könnte auch entsprechende Tokens oder NTLM-Credentials annehmen. Dazu müsste der Client diese aber erst mal senden. Solange Sie "Split-DNS" nutzen und das interne Active Directory den gleichen DNS-Domänennamen hat wie ihre Outlook AnyWhere oder MAPI/HTTP-URL, dann wird der Client auch die Anmeldedaten automatisch versenden. Das liegt daran, dass der DNS-Name des Active Directory im Browser als "Intranet" zählt.

Interessanter wird es, wenn ihr Active Directory z.B. "firma.local" heißt und sie den Outlook AnyWhere-Namen auf eine externe offizielle Domäne konfigurieren. Dann versucht der Client natürlich auch von Intern beim Verlust seiner TCP-Connection auf diesen Namen zuzugreifen. Per Default unterscheidet sich dieser Name aber überhaupt nicht von jedem anderen Namen einer gültigen Internet-Domäne. Ein "sicherer" Browser wird aber niemals die lokalen Anmeldedaten einfach so an eine "unbekannte Webseite" senden und das gilt auch für Outlook, welches den gleichen Stack verwendet. Sie müssen daher entsprechende Vorkehrungen treffen, dass die URL für RPC/http und auch MAPI/http entsprechend in den Zoneneinstellungen hinterlegt wird. Gruppenrichtlinien sind hier ein effektiver Weg diese Liste der "Intranet-Domains" auf allen Clients und Servern zu pflegen.

Falle: HTTP Proxy und PAC-Datei

Da der Zugriff über HTTP erfolgt, könnte natürlich noch eine Einstellung bezüglich der Verbindung eine Veränderung erforderlich machen. Auch hier ist dies meist dann der Fall, wenn sich die DNS-Domain des internen Active Directory von dem öffentlichen Namen unterscheidet, d.h. kein Split-DNS genutzt wird. Der Client und damit auch Outlook erkennt die Domäne nicht als "intern" und wird den konfigurierten Proxy-Server nutzen, um die Adresse zu erreichen. Outlook AnyWhere kann also fehlschlagen weil...

  • ... der Proxy die Authentifizierung blockiert
    Nicht jeder Proxy kann mit NTLM oder Kerberos umgehen
  • ... der Proxy die Anfrage immer "nach draußen" sendet und nicht wieder nach intern weiter gibt
    Meist fragen Proxy-Server entsprechende DNS-Server im Internet oder nutzten sogar einen "Cloud Proxy" und kommen damit gar nicht mehr nach intern. Auch Firewalls verhindern oft diesen Weg aus einer DMZ nach intern, da er per Definition ja nicht erwartet wird. Ein interner Client sollte ja interne Services direkt ansprechen.
  • ... die Clients einen Cloud-Proxy nutzen
    Wer keinen eigenen Proxy mehr betreiben will, kann diese "Dienstleistung" auch nach extern vergeben.
  • ... der Client den Proxy nicht nutzen darf
    Es gibt durchaus Firmen, in denen der Internet-Zugriff reglementiert wird. Das kann Missbrauch erschweren oder z.B. dem Jugendschutz geschuldet sein.

Aber selbst wenn der Proxy-Server alles richtig macht, möchten sie vielleicht verhindern, dass aller Outlook-Verkehr erst durch den Proxy wieder nach intern auf die Exchange Server geht. Das führt ansonsten zu höheren Belastungen des Proxy-Servers, zusätzlichen Authentifizierungsabfragen und vor allem ineffiziente Umwege der Pakete.

Falle: HTTP statt TCP

Der Wechsel von TPC auf HTTP hat noch an anderer Stelle Auswirkungen, die bei einer Umstellung an anderer Stelle zu Problemen führen könnten. Zwar kann Outlook auch den MAPI/TCP-Verkehr verschlüsselt aber die Nutzung von HTTP sorgt natürlich auch bei der Lastverteilung und bei WAN-Optimierern für eine veränderte Belastung. Beim Einsatz von MAPI/TCP haben die Exchange Administratoren in der Regel einige Ports (MSExchangeIS = 53590, MSExchangeDS = 53591) statisch festgelegt. Bei der Nutzung von HTTPS (Port 443) können die beiden Lasten nicht mehr getrennt werden. Das bedeutet

  • NetFlow-Analysen
    Die Auswertung von Datenströmen kann nicht mehr über die Ports erfolgen, sondern muss anhand der Ziel-Adressen erfolgen
  • QoS-Steuerungen
    Auch Gruppenrichtlinien, Porteinstellungen zur Klassifizierung und Router-Einstellungen zur Priorisierung von Outlook-Paketen müssen vom statischen Port auf die Ziel-IP-Adressen umgestellt werden
  • WAN-Optimierer
    System wir Riverbed etc. optimieren Netzwerkpakete um Bandbreite zu schonen. Neuere und andere Protokolle erfordern oft ein Update der Firmware aber manchmal auch neue Lizenzen. Damit solche Systeme überhaupt in den SSL-Datenstrom schauen und optimieren können, ist es erforderlich den privaten Schlüssel dort zu hinterlegen. Ansonsten werden deutlich schlechtere Optimierungsergebnisse erreicht.
  • TCP-Connection Pooling
    Neuere Outlook-Versionen sind "Cloud-Aware" und im Internet sind Laufzeiten von Paketen (Roundtrip) eher lang. Daher werden meist mehrere TCP-Verbindungen nebeneinander aufgemacht um parallel Elemente zu übertragen oder auf unterschiedliche Postfächer zuzugreifen. Das führt zu höheren "Verbindungen pro Client", was ebenfalls auswirkungen auf Zwischenstationen haben kann.

Auf dem Client einschalten

Allein die Konfiguration auf dem Server bringt den Client natürlich noch nichts, wenn der Client sich weiterhin per MAPI/TCP verbinden kann. Mit Exchange 2013 funktioniert das natürlich nicht mehr und so wird der Client bei der Migration des Postfachs natürlich auf die harte Tour lernen, dass der alte Server keinen Zugriff mehr erlaubt und der letztlich über eine neue "Autodiscover"-Anfrage den neuen Weg findet. Wenn das dann ein Exchange 2013 oder höher ist, dann wird EXPR gar nicht mehr als Protokoll angeboten.

Bis Exchange 2010 gibt es noch ein Powershell-Commandlet, um die aktuellen Verbindungen anzuzeigen-

In Exchange 2013 gibt es den Befehl leider nicht mehr. Dafür wandern immer mehr Dienste in Logdateien

Wenn Sie aber schon vorher die Clients auf RPC/HTTP umstellen wollen, dann ist eine Gruppenrichtlinie aus meiner Sicht der erste Schritt. So können Sie ausgewählte Clients schon auf RPC/HTTP umstellen und die Funktion verifizieren, ehe Sie dann alle umstellen.

Bislang habe ich noch nicht den Weg gewählt, MAPI/TCP auf den Servern aktiv zu blockieren, um die Clients auf RPC/HTTP zu zwingen. Bei Exchange 2010 geht das aber recht einfach, da hier ein CASARRAY für den Zugriff über MAPI/TCP genutzt werden kann und dieses dann auf einen Loadbalancer läuft. Wer hier einfach die Veröffentlichung stoppt. sperrt die Clients aus. Ein Loadbalancer ist hier natürlich auch eine Kontrolle, wie viele denn noch MAPI/TCP nutzen.

Download des "Article-961112.adm package"
http://download.microsoft.com/download/F/B/C/FBC43645-89EA-4FB4-828C-DFE27C360233/article-961112.adm

Ich beschränke den Einsatz von Gruppenrichtlinien aber nur auf die Steuerung der Protokolloptionen. Ich trage per GPO aber nur sehr ungern z.B. das Authentifizierungsverfahren oder den RPCProxy-Hostname ein. Das überlasse ich besser Autodiscover.

Weitere Links