Exchange: Outlook Autodiscover Troubleshooting

Outlook erkennt die Konfiguration des Exchange Postfaches anhand des Autodiscover Mechanismus automatisch. Somit muss der Benutzer nur die E-Mail Adresse, Benutzernamen und Passwort eingeben, die restliche Konfiguration bezieht Outlook selbstständig. Es kann allerdings in einigen Fällen zu Problemen kommen und eine kleine Auswahl jener, möchte ich anhand der nächsten Posts näher beleuchten.

• Exchange: Autodiscover verbindet sich mit Office365
• Exchange: Autodiscover benötigt sehr lange
• Exchange: Outlook funktioniert nach Migration nicht mehr

Wie funktioniert der Autodiscover

Doch um die grundlegende Problematik zu verstehen, sollte man sich zuerst anschauen, wie der Autodiscover Mechanismus eigentlich funktioniert. Outlook kennt insgesamt 5 Methoden, wie es zu einer erfolgreichen Konfiguration eines Exchange Postfaches kommen kann. Diese werden sequentiell abgearbeitet, führt einer der Anfragen zum Erfolg, werden die restlichen nicht mehr beachtet.

SCP – Service Connector Point

Installiert man im Active Directory einen Exchange, wird auch automatisch ein Autodiscover-SCP gesetzt. Alle Clients innerhalb der Domäne können mittels LDAP den Service Connector Point abfragen und bekommen die URL eines Exchange CAS (Client Access Servers) zurück geliefert. Den Wert kann man entweder über die ADSI.msc oder direkt über die Exchange Management Shell auslesen:

[PS] C:Windowssystem32>Get-ClientAccessService | select Name, *autodiscover*

Name                           : EX2016
AutoDiscoverServiceCN          : ex2016
AutoDiscoverServiceClassName   : ms-Exchange-AutoDiscover-Service
AutoDiscoverServiceInternalUri : https://exchange.domain.com/Autodiscover/Autodiscover.xml
AutoDiscoverServiceGuid        : 77378f46-2c46-4aa9-a6a6-3e7a41b19596
AutoDiscoverSiteScope          : {Vienna}

Wie man anhand des Beispiels schon erkennen kann, speichert der Exchange nicht nur jene URL, unter der man ihn intern erreichen kann, sondern auch den „AutodiscoverSiteScope“. Besitzt man bei größeren Umgebungen mehrere Exchanges und auch mehrere Sites, wäre es nicht klug, wenn der Client aus Amerika den Exchange in Österreich nach der Autodiscover Konfiguration fragt, wenn in Amerika ein eigener Exchange steht. Anhand der Sites Zuordnung findet der Client immer den nächstmöglichen CAS. Die Abfrage über das SCP funktioniert allerdings nur mit Clients innerhalb der gleichen Domäne.

Autoermittlung über Root Domain

Befindet sich der gewünschte Endpunkt nicht in der Domäne, ist die Abfrage der Root Domain über die URL „https://deinedomain.com/Autodiscover/Autodiscover.xml“ die erste Wahl von Outlook. Da der Exchange häufig unter einer Subdomain erreichbar ist, ist diese Methode relativ selten und Bedarf einer manuellen Weiterleitung am Host. Ein gültiges SSL Zertifikat wird zwingend benötigt.

Autoermittlung über Autodiscover Domain

Die Autoermittlung über die die Subdomain „https://autodiscover.deinedomain.com/Autodiscover/Autodiscover.xml“ ist wohl unter anderem die gängigste Methode für kleinere Exchange Server, welche nur unter einer primären Domain erreichbar sind. Besitzt ein Exchange mehrere Accepted Domains, ist diese Methode nicht unbedingt brauchbar. Denn auch hier wird ein gültiges SSL Zertifikat benötigt. Doch warum könnte es dabei zu Problemen kommen? Beispiel:

• Exchange: exchange.deinedomain.com
• Autodiscover: autodiscover.deinedomain.com
• Postfach 1: benutzername@deinedomain.com
• Postfach 2: benutzername@meinedomain.at

Möchte der Benutzer das Postfach 1 einrichten, wird der Client die Abfrage an „https://autodiscover.deinedomain.com/Autodiscover/Autodiscover.xml“ richten – da der Exchange auf diese Domain konfiguriert wurde und auch ein gültiges Zertifikat dafür besitzt, wird er die Anfrage erfolgreich bedienen können. Jetzt kommen wir allerdings zum Problem: Beim Einrichten des zweiten Postfaches wird die Anfrage an „https://autodiscover.meinedomain.at/Autodiscover/Autodiscover.xml“ gerichtet. Auch wenn in der DNS Zone ein entsprechender CNAME auf die autodiscover.deinedomain.com gesetzt wurde, würde der Exchange Server das „falsche“ Zertifikat ausliefern. Der Client würde ein Zertifikat für autodiscover.meinedomain.at erwarten, bekommt allerdings eines für autodiscover.deinedomain.com zurück geliefert.

Zwar würde die Einrichtung trotzdem funktionieren, allerdings bekommt der Client eine Zertifikatswarnung. Um dem Abhilfe zu schaffen, kommen wir zu den nächsten zwei Optionen.

Autoermittlung über Autodiscover Redirection

Bei dieser Methode richtet der Client die Anfrage gezielt an Port 80 „http://autodiscover.meinedomain.at/Autodiscover/Autodiscover.xml“ und erwartet sich eine Weiterleitung (um genau zu seinen einen Redirect 302) auf den Exchange. In unserem Fall müsste der Host die Anfrage also per Redirect an „https://autodiscover.deinedomain.com/Autodisocver/Autodiscover.xml“ weiterleiten. Somit wird das korrekte Zertifikat ausgeliefert und das Postfach kann ohne Warnung eingebunden werden.

Diese Methode findet vor allem bei größeren Exchange Umgebungen mit unterschiedlichen primären SMTP Adressen anklang. Auch bei einem Hosted Exchange (Multi Tenant Exchange) wäre das die richtige Vorgehensweise. Office365 mit Exchange Online geht hier genau so vor. Es ist allerdings essentiell, dass unter der Domain autodiscover.meinedomain.at ausschließlich ein Dienst auf Port 80 antwortet. Würde der Host beispielsweise auch auf Port 443 antworten, würde der dritte Autodiscover-Mechanismus bereits zuvor reagieren.

Autoermittlung über SRV Record

Die letzte Chance die korrekte Konfiguration zu beziehen, bildet der SRV-Record. Allerdings ist diese Methode nicht weit verbreitet, demnach wird sie auch nicht von jedem Client unterstützt. Hierbei fragt der Client den SRV Record der Subdomain „_autodiscover._tcp.deinedomain.com“ ab und erwartet sich eine entsprechende Weiterleitung auf den Exchange. Der große Vorteil dabei ist, dass sich diese Variante auch problemlos auf mehrere, primären SMTP Adressen abbilden lässt, da die in Punkt 4 genannte Weiterleitung automatisch passiert. Somit läuft man dabei nicht in Gefahr, fehlerhafte Zertifikate an den Client auszuliefern. Möchte man also nicht einen extra vHost mit Redirect 302 einrichten, wäre das die einfachste Lösung.

Sollte keiner der 5 möglichen Optionen zum Erfolg führen, wird der Prozess abgebrochen und das Postfach kann nicht eingebunden werden. Bei Outlook 2010 konnte man beispielsweise das Exchange Postfach noch manuell mit der entsprechenden Serveradresse einrichten. Das ist allerdings ab Outlook 2016 nicht mehr möglich. Ein funktionierender Autodiscover ist hier also eine Voraussetzung, um ein Exchange Postfach mittels MAPI einzurichten.