Troubleshooting: Fehlerbehebung mit Exchange

Anhand von Supportfällen aus meinem Praxisalltag möchte ich Ihnen verschiedene Möglichkeiten aufzeigen, in einer Exchange-Umgebung Fehler zu finden und zu beheben.

Szenario

Der Beispiel-Kunde Fabrikam hatte ursprünglich eine Exchange-2010-SP2-Umgebung mit mehreren Servern pro Rolle: 4 Mailbox Server in einer Database Availability Group, 4 Client Access Server in einem Array mit Loadbalancer, 2 Hub Transport und 2 Edge Transport Server. Neu sollten 4 Exchange 2013 Server mit konsolidierten Rollen zum Einsatz kommen. Die alten Server wurden mit SP3 auf den benötigten Softwarestand gebracht, das AD vorbereitet (Schema und Domänen) und die neuen Server installiert. Somit bot sich prinzipiell folgendes Bild: Die Mailboxen waren noch in der Exchange-2010-Umgebung und Autodiscover noch nicht angepasst für die Verwendung von Exchange 2013 CAS. Ich habe für die folgenden Screenshots die wichtigsten Komponenten in meinem Lab nachgebaut, allerdings beschränkt auf einen DC, je einen Exchange 2010 und 2013 Server und einen Client mit Outlook 2010. Statt des Loadbalancers kommen angepasste DNS-Einträge zum Zug. Die Mailbox des Testuser1 wurde migriert, diejenige des Testuser2 noch nicht.

Das Problem

Nach der Umstellung des Autodiscover DNS Records von der virtuellen IP des Exchange 2010 Arrays zu derjenigen des Exchange 2013 Arrays konnten die Benutzer, deren Mailboxen noch nicht migriert waren, Autodiscover nicht mehr Autodiscover. Dies fiel auf, weil der Abwesenheitsassistent nicht mehr funktionierte: Ausserdem war logischerweise auch die Frei/Gebucht-Anzeige nicht mehr verfügbar:

Microsoft Exchange Trainings Für mehr Informationen zu Exchange 2013 und 2016 besuchen Sie einen der folgenden Kurse. Zu allen Exchange-Server-Trainings

Für mehr Informationen zu Exchange 2013 und 2016 besuchen Sie einen der folgenden Kurse.

Zu allen Exchange-Server-Trainings

Die Outlook Web App (OWA) funktionierte hingegen tadellos, wie der nächste Screenshot zeigt. Die URL zeigte auf Exchange 2013 (cas.fabrikam.com), die Mailbox des Benutzers lag aber auf Exchange 2010. Der Zugriff wurde also nicht umgeleitet, sondern weitergeleitet. Umgekehrt funktioniert das natürlich nicht. Hier das zu erwartende Resultat mit der URL des Exchange 2010 (casarray.fabrikam.com) und der Mailbox des Benutzers Testuser1 auf Exchange 2013: Auch Frei/Gebucht und Abwesenheitsassistent funktionierten in OWA:

Fehlersuche

Abwesenheitsassistent und Frei/Gebucht-Informationen hängen von Autodiscover ab. Deshalb war der erste Schritt, festzustellen, ob Autodiscover überhaupt funktionierte. Dies geht am einfachsten mit Outlook und der Option «Test E-Mail AutoConfiguration…». Nicht vergessen CTRL zu drücken beim Aufrufen des Kontext-Menüs: Die Ausgabe des Tests zeigte sich wie folgt: Der Reiter «Log» gab auch nicht mehr Aufschluss: Allerdings sind hier die verschiedenen Methoden ersichtlich, mit denen nach Autodiscover gesucht wird: Service Connection Point in Active Directory, über DNS fabrikam.com und autodiscover.fabrikam.com. Der Eintrag autodiscover.fabrikam.com zeigte neu ja auf den Exchange 2013 Server und hätte somit funktionieren müssen. Für Testuser1 war das auch der Fall: HTTP-Status 500 in der Fehlermeldung des vorletzten Screenshots bedeutet «Internal Server Error», also war der nächste Schritt, die Logs auf dem Exchange 2013 zu konsultieren. Davon gibt es doch einige, weswegen die Gefahr besteht, dass man sich zu sehr darauf konzentriert, das richtige zu finden. Besser ist es, zuerst im Event Log nachzuschauen. Hier fand sich dann auch im Application Log der folgende Eintrag: Die Selbstüberwachung des Exchange 2013 hatte also den alten Server als ungesund taxiert und aus der Liste der zu kontaktierenden Server gestrichen. Das erklärte den «Internal Server Error». Warum konnte er aber den 2010-CAS nicht erreichen? «Operation timed out» konnte bedeuten, dass netzwerktechnisch etwas nicht in Ordnung war. Das Aufrufen der Autodiscover-URL vom neuen Server aus zeigte, dass die Kommunikation funktionierte: Da der Servername nicht im verwendeten Zertifikat ist, erscheint die Zertifikatswarnmeldung. Dies ist aber kein Problem, da sich die Exchange-Server einer Organisation vertrauen und die Zertifikate nur für die Verschlüsselung der Verbindung verwenden. Der Errorcode 600 ist auch normal, da Exchange anhand des Request Headers merkt, dass hier nicht Outlook die Anfrage stellt, sondern IE – deshalb «Invalid Request». Der nächste Schritt war die Suche nach einem Fehler auf Seite des Exchange 2010. Da hier das Event Log keine brauchbare Information lieferte, griff ich auf das Logfile des Webservers zurück: Es liessen sich keine Informationen finden zu den Abfragen für den Testbenutzer2, da ja Exchange 2013 die Requests gar nicht erst weiterleitete – für ihn war Exchange 2010 ja nicht funktionstüchtig. Aber es gab trotzdem Einträge im Log für Verkehr auf das Autodiscover virtual Directory: Quelle war der Exchange 2013 und aufgrund des Befehls «Head» eine Probe für die Überwachung. Der Statuscode war wie im Screenshot markiert 302. Also ein Redirect. Da dies nicht so sein sollte, überprüfte ich das Directory in der IIS-Management-Konsole und fand dies: Dies erklärte den unerwünschten Redirect. Darauf angesprochen erklärte der Kunde, den Redirect auf der Website konfiguriert zu haben, um eine Fehlfunktion eines anderen Produkts zu verhindern. Dieser wäre auf den Subdirectories nicht nötig gewesen, wurde aber automatisch vererbt. Ich konnte also den Eintrag für Autodiscover löschen, ohne zusätzliche Probleme in Kauf nehmen zu müssen: Danach funktionierte Autodiscover tadellos.