Häufig bekomme ich per Mail oder hier im Blog fragen zu Problemen mit Outlook Anywhere (RPCoverHTTPS) gestellt. Die Ursachen warum Outlook Anywhere nicht funktionieren will oder nicht wie erwartet funktioniert, können allerdings sehr unterschiedlich sein. Daher gibt es hier jetzt einen etwas tieferen Einblick in die Konfiguration und die Fehleranalyse von Outlook Anywhere. Ich habe dazu eine Demo Umgebung installiert, die man gerade bei kleineren Installationen häufig vorfindet:
Es gibt einen Domain Controller (DC1) und einen Exchange Server (EX1) auf dem alle Exchange Rollen installiert sind. Im Netzwerk gibt es einen Router für den Internetzugang und irgendwo im Home Office gibt es einen PC der sich via Outlook Anywhere mit Exchange verbinden soll. Das Active Directory hört auf den Namen „frankysweb.local“. Soweit zur internen Netzwerkstruktur.
Jetzt zur Öffentlichen Struktur: Ich benutze für diesen Artikel die Domain „frankysweb.org“. Die bei einem Webhoster (in meinem Fall Strato) gehostet wird. Bei bem Home Office PC handelt es sich um ein Notebook welches für diesen Artikel per UMTS Internetzugriff erhält. Das Notebook ist Mitglied der Domain „frankysweb.local“.
Auf meinen Exchange 2010 Server EX1 ist bisher kein Outlook Anywhere konfiguriert, daher beschreibe ich Einrichtung und verursache bewusst Fehler, um zu zeigen welche Auswirkungen es nach sich zieht.
Da Outlook Anywhere bisher nicht aktiviert ist, befindet sich in meinem Outlook Profil aktuell nur der interne Servername:
Outlook Anywhere ist im Profil deaktiviert:
Um Outlook Anywhere nutzen zu können, muss es aktiviert werden, allerdings sind ein paar Vorarbeiten nötig:
- DNS Einträge beim Provider anlegen
- Portforward einrichten
- Zertifikat erneuern
Los geht es mit der Einrichtung der DNS Einträge. Ich möchte Outlook Anywhere unter dem Namen oa.frankysweb.org im Internet veröffentlichen. Daher muss ich bei meinem Provider zwei Subdomains anlegen die beide auf meine öffentliche IP zeigen:
oa.frankysweb.org
autodiscover.frankysweb.org
Ein Test mit NSLOOKUP sollte dann für beide Einträge die öffentliche IP wiedergeben:
Weiter geht es mit dem Portforward. Für Outlook Anywhere wird ausschließlich Port 443 (HTTPS) verwendet. Es muss also nur Port 443 bzw. das Protokoll HTTPS vom Router/Firewall auf den Exchange Server weitergeleitet werden. Hier das Beispiel anhand von Sophos UTM:
Je nach Router wird also eine DNAT-Regel benötigt, die alle Verbindungen die am WAN-Anschluss auf Port 443 (HTTPS) ankommen an den Exchange Server (in meinem Fall EX1 192.168.100.251) weiterleitet.
Hier kommt die erste Falltür: Zwar wird für Outlook Anywhere HTTPS als Grundlage der Verbindung genutzt, dennoch handelt es sich hier nicht um das HTTP Protokoll, welches über SSL gesichert wird. Outlook Anywhere nutzt im Prinzip nur das Protokoll HTTPS bzw. den Port 443 und tunnelt über diese Verbindung das RPC Protokoll. Einige Firewalls und Reverse Proxys haben damit ein Problem, denn sie erwarten das standardisierte HTTPS Protokoll und können mit RPC getunnelt über HTTPS nicht umgehen.
Eigentlich müsste ich jetzt das Zertifikat anpassen, aber ich lasse den Schritt jetzt bewusst aus, um einen der häufigsten Fehler zu produzieren: Zertifikatswarnungen!
Also aktiviere ich jetzt Outlook Anywhere
Die nächste Meldung zeigt bereits an, dass es bis zu 15 Minuten dauern kann, bis Outlook Anywhere aktiviert ist.
Nach einer Weile sollten sich dann Im Anwendungsprotokoll Ereignisse mit der ID 30XX finden lassen
Da Outlook Anywhere eine HTTPS Verbindung benutzt, nimmt IIS die Verbindungen entgegen. Outlook Anywhere benutzt dazu das Verzeichnis RPC im IIS:
Über die HTTPS Verbindung wird dann das RPC Protokoll getunnelt, diese Aufgabe übernimmt das Feature „RPC-über-HTTP-Proxy“ welches Bestandteil des Betriebssystems ist
Die Konfiguration zu Outlook Anywhere wird durch den „RpcHttpConfigurator“ durchgeführt, dieser Prozess ist Teil des Dienstes „Microsoft Exchange-Diensthost“. Dieser Prozess läuft in der Standardeinstellung alle 15 Minuten. Daher kann es auch bis zu 15 Minuten dauern, bis Outlook Anywhere aktiviert oder Konfigurationsänderungen übernommen werden. Das Intervall kann in der Registry angepasst werden
Der Dienst „RpcHttpConfigurator“ schreibt dann die Outlook Anywhere Einstellungen aus dem Active Directory in die IIS Konfiguration, dabei werden vorherige Werte im IIS überschrieben. Daher bringt es nichts Einstellungen zu Authentifizierung oder SSL im IIS zu ändern. Diese Werte werden nach 15 Minuten überschrieben. Hier ein Screenshot der Einstellungen aus dem Active Directory:
Soweit so gut, im dritten Screenshot von oben ist allerdings zu sehen, das Outlook Anywhere auf dem Client bisher nicht eingeschaltet ist. Das Outlook Profil muss also noch angepasst werden, damit Outlook Anywhere genutzt werden kann. Für die Anpassung der Einstellungen ist Autodiscover zuständig.
Hier gibt es die zweite Falltür. Auch nachdem Outlook Anywhere eingeschaltet wurde, aktualisiert sich das Outlook Profil nicht. Im nächsten Screenshot wird es deutlich, gleiches Outlook Profil, Outlook Anywhere wurde nachträglich aktiviert, aber Outlook übernimmt die Einstellungen nicht:
Zum Vergleich der gleiche Benutzer, aber mit neu eingerichtetem Outlook Profil nachdem Outlook Anywhere aktiviert wurde:
Neue Outlook Profile erhalten die aktuellen Einstellungen also sofort, bestehende Profile aber nicht. Das gleiche Verhalten tritt auch auf, wenn ein CAS-Array nachträglich eingerichtet wird. Dieses Verhalten wurde aber mit den aktuellen Service Packs für Office und mit den Update Rollups für Exchange 2010 stark verbessert. Ein aktuelles Outlook in Verbindung mit einem aktuellen Exchange 2010 Server übernimmt die Einstellungen normalerweise binnen 2 Stunden. Diese kleine Falltür kann also umgangen werden, indem sichergestellt wird, das Outlook und Exchange auf einem aktuellen Patchstand sind.
Kurze Zusammenfassung:
- Outlook Anywhere Einstellungen werden durch den Dienst „Microsoft Exchange-Diensthost“ aus dem Active Directory an den IIS übertragen
- Autodiscover verteilt die geänderten Einstellungen an die Outlook Clients
- Outlook Anywhere Verbindungen werden über eine HTTPS Verbindung an den Exchange Server getunnelt
In Teil 2 geht es dann ein wenig in die Tiefe und wir schauen uns an, warum das Zertifikat so wichtig ist.
Hi, danke für deinen tollen Artikel, die haben mir bereits das ein oder andere Mal geholfen. Mein Problem mit Anywhere wird oben leider nicht erwähnt. Meine Umgebung sieht ziemlich genau aus wie deine obige beschriebene und funktioniert wunderbar. Ein paar Clients allerdings versuchen sich aus dem internen Netz heraus über Anywhere zu verbinden. Hast du dazu eine Idee?
Schönen Grüße,
lenny
großer gott, das rettet gerade mein leben!