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.
  • IPv6
    Speziell Exchange 2003 unterstützt noch kein IPv6. Dennoch könnte es sein, dass die RPCProxy.DLL, welche ja von Windows kommt, per DNS den Server auf die IPv6-Adresse auflöst. Wer in so einer Umgebung z.B. IPv6 intern aktiviert, kann Outlook Anywhere mit Exchange 2003 stören.

REM Deaktivieren von IPv6 auf Windows 2003
REM Achtung: Bitte Abhängigkeiten prüfen
REM nicht als "Pauschallösung" ansehen

netsh int ipv6 uninstall

  • 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 auf dem Port 135 nicht mal ein RESET sendet, sondern einfach die Pakete ins Leere laufen lässt.

    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.
    Wenn Sie aber versuchen die DNS-Abfragen über einen anderen DNS-Server zu lenken, dann blockiert auch hier die Telekom, wie wieder ein Mitschnitt belegt:

    Eine Anfrage auf netatwork.de über einen DNS-Server eines anderen Providers (hier EGGENET) wurde von der 79.210.124.79 abgelehnt.
  • RPCPing
    Auf den meisten Systemen ist das RPCPING vorhanden, welches für einen Test ebenfalls verwendet werden kann
rpcping -t ncacn_http -s exchangeservername -o RpcProxy=rpc.example.com -P "User,domain,*" -H 2 -u 10 -a connect -F 3 -v 3 -E

 

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.