Heute geht es um die Client Seite und welche Möglichkeiten es gibt die RPCoverHTTPS Verbindung zu untersuchen.
Eine der besten und einfachsten Anlaufstellen ist der Remote Connectivity Analyzer von Microsoft. Der RCA liefert eine erste schnelle Übersicht ob Outlook Anywhere funktioniert, oder wo es hakt. Leider mag der RCA selbst erstellte Zertifikat nicht, auch nicht wenn Sie von einer internen CA stammen:
Mit einem Zertifikat einer öffentlichen CA funktioniert das schon besser:
Auch Exchange verfügt für ein CMDlet mit dem sich die Verbindung grundlegend testen lässt
Test-OutlookConnectivity -Protocol TCP
Zusätzlich lässt sich in Outlook der Debug Modus einschalten, Outlook erzeugt dann Logfiles in folgendem Verzeichnis:
c:\Users\%username%\AppData\Local\Temp
Leider ist das wohl wichtigste Logfile nicht lesbar: OLKRPCLOG_Datum_Zeit.etl
Man kann das Logfile zwar mit der Ereignisanzeige öffnen oder mittels Tracedmp.exe in eine CSV Datei konvertieren, aber lesbar wird es dadurch trotzdem nicht:
Verbindungsprobleme vom Client zum Exchange Server lassen sich aber auch recht gut mit dem Microsoft Network Monitor untersuchen. Hier mal ein kleines Beispiel.
Im Screenshot oben sieht man das die Quelle (172.20.10.2) eine Verbindung zum Ziel 79.197.156.15 aufbauen möchte. Hier handelt es sich um einen Outlook Anywhere Verbindungsaufbau. 10 Sekunden später antwortet aber plötzlich eine ganz andere IP auf die Anfragen (81.169.145.164). Dieses Problem tritt üblicherweise auf, wenn Outlook Anywhere über DynDNS Dienste betrieben wird. Hier war der die IP-Adresse zu dem DNS Eintrag nicht aktuell.
Ein erfolgreicher Verbindungsaufbau sieht in etwa so aus:
Man sieht also, das Troubleshooting von der Clientseite wird schwierig. Daher versuche ich wenn möglich immer alle Exchange Webservices unter der gleichen Adresse erreichbar zu machen. In diesem Beispiel ist OWA ebenfalls unter der Adresse oa.frankysweb.org zu erreichen. Das macht es bei der Fehlerdiagnose etwas einfacher. Gerade in folgenden Punkten:
im Browser eingetippt liefert eine Zertifikatswarnung? Dann hat auch Outlook Anywhere ein Problem mit dem Zertifikat, hier ist schnell klar wo gesucht werden muss. Oder zeigt gar nichts an, dann passt vieleicht der DNS Eintrag nicht, oder eine Firewall blockt die Verbindung.
Wenn man sicher ist, das keine Firewall die Verbindung blockiert, kann man vom Client aus noch einen RPCPing versuchen:
rpcping.exe -t ncacn_http -o RpcProxy=oa.frankysweb.org -u 9 -a connect -v 3 -P "Benutzername,DomainName,Passwort" -H 1 -F 3
Hier eine erfolgreiche Verbindung:
Und hier mit falschem Kennwort:
Eine Doku zu RPCPing gibt es hier:
http://support.microsoft.com/kb/831051/en-us
Hi,
ich habe leider das gleiche Problem !
Gegeben ist:
ein selbst signiertes Zertifikat. Bei der Verbindung über Outlook an den Server wird auch das richtige Zertifikat angemeckert (habs auf dem REchner installiert) und dann sagt mir der REchner die gleiche Fehlermeldunge: Anmeldung nicht möglich, kann Name nicht auflösen, keine Verbindung, etc.
scheinbar komme ich bis zur Abfrage des Zertifikates und dann .. nichts …
IPhone und IPad können im übrigen an den Exchange heran(aber die nutzen ja nicht Outlook anywhere) kommunizieren aber Outlook macht zicken !
haben Sie noch eine Idee ?
Hallo,
vielen lieben Dank für diese Tutorials. Leider bekomme ich immer noch die Fehlermeldung
„Die Aktion kann nicht abgeschlossen werden. Es steht keine Verbindung mit Microsoft Exchange zur Verfügung. Outlook muss im Onlinemodus oder verbunden sein, um diesen Vorgang abzuschließen.“
SAN Zertifikat wurde erstellt. Weiterleitung beim Provider auf die feste IP eingestellt. Owa funktioniert übers Netz wobei da auch zuerst eine Zertifikatsmeldung kommt. rpcping sihet auch gut aus. Der Remote Connectivity Analyzer gibt die erwarteten Meldungen bei selbst signierter CA aus.
Ich verzweifle hier noch :/
LG
Hallo,
wenn Outlook Anywhere und OWA die gleiche Adresse nutzen und Sie schon bei OWA ein Zertifikatsfehler bekommen, wird Outlook Anywhere nicht funktionieren. Sie haben also noch immer ein Problem mit den Zertifikaten, der gängigste Fehler sind falsche Namen oder der fehlende Import des Stammzertifikats an Nicht-Domain-Rechner.
Gruß,
Frank
Hmm, das Zertifikat habe ich jetzt bestimmt schon 10x überprüft. Dort scheint alles OK zu sein. Die externen Clients sind nicht in der Domäne. Das Zertifikat wurde in den Speicher lokaler Computer und vertrauenswürdiger Hersteller importiert.
Wenn alles OK wäre, würde keine Warnung angezeigt werden. Einen Speicher für „Vertrauenswürdige Hersteller“ gibt es übrigens nicht.
deswegen verzweifle ich ja gerade auch…. irgendwo wird schon ein trennet sein den ich halt nicht sehen :/
… vertrauenswürdige Herausgeber war gemeint…
LG :)