Outlook Anywhere - Fehlersuche
Sollte RPC over HTTP dann jedoch immer noch nicht funktionieren, dann ist eine weitere Analyse erforderlich. Hier sind zuerst folgende Punkte zu prüfen:
- Erreicht der Client den Server ?
Hier spielen die Namensauflösung, Firewalls etc. eine Rolle. Versuchen Sie einfach mal OWA zu nutzen. Damit können Sie schon fast sicher sein, dass die Namensauflösung und zumindest HTTP durch kommt.
Eine gute Kontrolle ist der Verbindungsstatus. Dazu müssen Sie bei gedrückter "STRG"-Taste mit der rechten Maustaste auf das Outlook Icon in der Taskleiste drücken. Dann können Sie im Kontextmenü den Verbindungsstatus aufrufen.
- RPC auf dem Server
Kontrollieren Sie im Eventlog den Start er RCP over HTTP Funktion und im IIS Manager die Existenz des virtuellen Verzeichnisses RPC. - SSL aktiv und gültig
Versuchen Sie einen Zugriff auf die RPC-URL über HTTPS und prüfen Sie, ob der Browser das SSL-Zertifikat ohne Warnungen annimmt. Eine Fehlermeldung wird dann natürlich kommen, da kein Browser "RPC" spricht. aber das "SSL-Schloss" muss geschlossen sein. - Basic Authentication
RPC muss die Benutzerdaten und Anmeldung des Benutzers im "Klartext" erhalten, damit es mit diesen Anmeldedaten per RPC an den Exchange Server zugreifen kann. Daher muss "Basic-Auth" auf dem Verzeichnis RPC aktiviert sein. - IIS-LogFiles
Jeder Zugriff auf den IIS wird in den entsprechenden Protokolldateien niedergeschrieben. Die Einträge können z.B.: ähnlich aussehen:
2004-05-19 14:13:30 192.168.0.1 RPC_IN_DATA /rpc/rpcproxy.dll
srv01.msxfaq.local:6001 80 - 192.168.100.12 MSRPC 401 2 2148074254
2004-05-19 14:13:30 192.168.0.1 RPC_OUT_DATA /rpc/rpcproxy.dll
srv01.msxfaq.local:6001 80 - 192.168.100.12 MSRPC 401 2 2148074254
- C:\WINDOWS\system32\LogFiles\HTTPERR\
In diesem Verzeichnis liegen per Default die Fehlermeldungen, die RPC over HTTP produziert.
2005-03-06 00:03:22 192.168.0.12 39393 192.168.0.10 443
HTTP/1.1 RPC_IN_DATA /rpc/rpcproxy.dll?srv01.msxfaq.local:6004 400 1
BadRequest
2005-03-06 00:03:28 192.168.0.12 39397 192.168.0.10 443 HTTP/1.1
RPC_IN_DATA /rpc/rpcproxy.dll?SRV01:6004 400 1 BadRequest
- Firewall/URLSCAN
Wenn das weiter nichts hilft, dann könnte es noch ein Problem der Firewall oder eine Einstellung von URLSCAN sein, die gezielt die URl "/RPC/*" blockieren - DNS-Tricks
Besonders negativ ist hier die Telekom "Navigationshilfe", die auf DSL-Anschlüssen oftmals "aktiv" ist. Fragt ein Client nach einem Namen, den es nicht gibt, dann antwortet der DNS-Server des Telekom mit einer IP-Adresse für eine Webseite der Telekom.
Das ist ungeschickt, da Outlook bei "schnellen" Verbindungen erst eine Verbindung per RPC versucht. Löst hier der interne Name des CAS-Array aber auf eine IP auf, geht Outlook davon aus, dass er "intern" ist und versucht es per RPC, also TCP Port 135 zum Telekom Webserver. Im Netmon sieht man aber, dass die Telekom
Es dauert einige Timeouts, bis Outlook aufgibt und dann doch RPC/HTTP macht. Leider scheint die Telekom diesen "Service" per Default für alle Kunden aktiviert zu haben und muss von jedem Anschlussinhaber individuell im Kundencenter abgeschaltet werden. Es könnte also ein Workaround sein, den CASARRAY-Namen im Internet zu pflegen und auf eine IP-Adresse zu lenken, die auf den Verbindungsversuch 135/TCP schnell mit einem "RESET" antwortet.
Versuchen Sie z.B. RPC over HTTP einfach erst einmal von intern ohne Firewall, Router, NAT und andere möglichen Problemen. Auch ein zweiter PCs kann hilfreich sein, wenn nur eine Unstimmigkeit auf dem einzigen Testsystem Sie auf die falsche Fährte schickt.
