Troubleshooting: Fehlerbehebung mit Exchange
Am Beispiel einer fiktiven Firma zeigt unser Kursleiter Markus Hengstler auf, welche Probleme nach der Installation von Exchange Server 2013 entstehen können. In diesem Fall treten Probleme mit der Outlook Web App auf. Lies jetzt die Tipps zur Fehlersuche.
Anhand von Supportfällen aus meinem Alltag zeige ich dir verschiedene Wege, wie du in einer Exchange-Umgebung Fehler findest und behebst.
Szenario
Der Beispielkunde Fabrikam nutzte ursprünglich eine Exchange-2010-SP2-Umgebung mit mehreren Servern pro Rolle: vier Mailbox-Server in einer Database Availability Group, vier Client-Access-Server in einem Array mit Loadbalancer, zwei Hub-Transport- und zwei Edge-Transport-Server.
Neu sollten vier Exchange-2013-Server mit kombinierten Rollen eingesetzt werden. Die alten Server wurden mit SP3 aktualisiert, das Active Directory vorbereitet (Schema und Domänen) und die neuen Server installiert.
So ergab sich folgendes Bild: 
Die Mailboxen befanden sich noch in der Exchange-2010-Umgebung. Autodiscover war noch nicht für Exchange 2013 CAS angepasst.
Für die Screenshots habe ich die wichtigsten Komponenten in meinem Lab nachgebaut: einen Domain Controller, je einen Exchange-2010- und 2013-Server sowie einen Client mit Outlook 2010. Statt des Loadbalancers nutzte ich angepasste DNS-Einträge. Die Mailbox des Testusers 1 war migriert, diejenige von Testuser 2 noch nicht.
Das Problem
Nach der Umstellung des Autodiscover-DNS-Records von der virtuellen IP des Exchange-2010-Arrays auf jene des Exchange-2013-Arrays konnten Benutzerinnen und Benutzer mit nicht migrierten Mailboxen Autodiscover nicht mehr verwenden.
Das zeigte sich zuerst am Abwesenheitsassistenten: 
Auch die Frei/Gebucht-Anzeige war nicht mehr verfügbar: 
Die Outlook Web App (OWA) funktionierte dagegen problemlos. Die URL zeigte auf Exchange 2013 (cas.fabrikam.com), die Mailbox lag aber noch auf Exchange 2010. Der Zugriff wurde also nicht umgeleitet, sondern weitergeleitet: 
In umgekehrter Richtung funktionierte es nicht. Hier das erwartete Resultat mit der URL des Exchange 2010 (casarray.fabrikam.com) und der Mailbox von Testuser 1 auf Exchange 2013: 
Auch Frei/Gebucht und der Abwesenheitsassistent funktionierten in OWA: 
Fehlersuche
Abwesenheitsassistent und Frei/Gebucht-Informationen hängen von Autodiscover ab. Deshalb prüfte ich zuerst, ob Autodiscover funktionierte.
Am einfachsten geht das in Outlook über «Test E-Mail AutoConfiguration…». Halte CTRL gedrückt, um das Kontextmenü zu öffnen: 
Das Testergebnis sah so aus: 
Der Reiter «Log» brachte ebenfalls keine weiteren Hinweise: 
Hier sind die verschiedenen Methoden zu sehen, über die Autodiscover gesucht wird: Service Connection Point in Active Directory, DNS fabrikam.com und autodiscover.fabrikam.com.
Der Eintrag autodiscover.fabrikam.com zeigte auf den Exchange-2013-Server und sollte funktionieren. Für Testuser 1 war das auch so: 
HTTP-Status 500 bedeutet «Internal Server Error». Nächster Schritt: Logs auf dem Exchange 2013 prüfen.
Im Application Log fand sich folgender Eintrag: 
Die Selbstüberwachung des Exchange 2013 hatte den alten Server als fehlerhaft erkannt und aus der Liste der erreichbaren Server entfernt. Das erklärte den «Internal Server Error».
Warum konnte er den 2010-CAS nicht erreichen? «Operation timed out» deutete auf ein Netzwerkproblem hin.
Der Test der Autodiscover-URL vom neuen Server aus zeigte jedoch, dass die Verbindung funktionierte: 
Da der Servername nicht im Zertifikat enthalten war, erschien eine Warnmeldung – kein Problem, da sich die Server gegenseitig vertrauen. Der Errorcode 600 ist ebenfalls normal: Exchange erkennt anhand des Request-Headers, dass der Aufruf nicht von Outlook, sondern vom Internet Explorer kommt – daher «Invalid Request».
Als Nächstes suchte ich den Fehler auf Seite des Exchange 2010. Im Event Log fand ich nichts Brauchbares, also prüfte ich das Webserver-Log: 
Da Exchange 2013 die Requests nicht weiterleitete, fehlten Einträge für Testuser 2. Trotzdem gab es Logeinträge für das Autodiscover-Verzeichnis: 
Die Quelle war Exchange 2013, der Befehl «Head» diente der Überwachung. Der Statuscode 302 zeigte einen Redirect an.
In der IIS-Management-Konsole fand ich den Grund: 
Der Redirect war auf der Website konfiguriert worden, um ein anderes Produktproblem zu vermeiden. Diese Einstellung wurde jedoch auf Unterverzeichnisse vererbt.
Ich konnte den Eintrag für Autodiscover löschen, ohne weitere Probleme zu verursachen: 
Danach funktionierte Autodiscover wieder einwandfrei: 