Exchange 2016 nach Einbindung SSL Zertifikat funktioniert AutoDiscover nicht mehr

Guten Morgen liebes Forum,

nachdem ich bei einem Kunden mit Exchange Server 2016 gestern den Exchange so angepasst habe, dass die URLs passen und das passende SSL Zertifikat eingebunden habe funktioniert nun das Outlook AutoDiscover nicht mehr richtig.
Ich mache das nicht zum 1. Mal und habe sogar gestern das exakt selbe Prozedere bei 2 anderen Kunden durchgeführt OHNE Probleme.

interne und externe URLs im Exchange gesetzt mit folgendem Script:

Powershell: Konfigurieren der internen und externen URLs von Exchange Server 2013, 2016

Domain ist "email.DOMAIN.TLD"

AutoDiscover Domain über Powershell angepasst NACH dem Script auf:

Set-ClientAccessService EXCHSRV01 -AutoDiscoverServiceInternalUri "https://autodiscover.DOMAIN.TLD/Autodiscover/Autodiscover.xml"

Domain ist "autodiscover.DOMAIN.TLD"

Outlook Anywhere URLs in der ECP geprüft

SSL Zertifikat eingespielt

Das Zertifikat hat die beiden SANs "email.DOMAIN.TLD" und "autodiscover.DOMAIN.TLD"

iisreset durchgeführt bzw. sogar den Server neugestartet.

Zugriff und Zertifikat über Browser sowohl intern als auch extern getestet mit Zugriff auf
https://email.DOMAIN.TLD/OWA

Funktioniert und auch ohne Zertifikatswarnung.

Anschließender Test mit dem Microsoft Remote Connectivity Analyzer, sieht auch gut aus:

Nun zum Problem:
Sobald ich intern ein Outlook starte (im Beispiel Outlook 2010) und das Konto mittels AutoDisover eingerichtet werden soll passiert folgendes:

Er hängt sich dort auf und macht nicht weiter.
Richte ich das Konto allerdings manuell ein über MAPI-over-HTTP, dann funktioniert das Konto einwandfrei. Sowohl intern als auch extern.

PS.: Ich habe im internen DNS 2 primäre Forward-Lookup-Zonen angelegt, einmal "autodiscover.DOMAIN.TLD" und einmal "email.DOMAIN.TLD" und jeweils einen leeren Host-A Eintrag dort gesetzt auf die interne IP des Exchange-Servers.

Für jede Hilfe bin ich dankbar!

Liebe Grüße,
Dennis

Please also mark the comments that contributed to the solution of the article

Content-Key: 325014

Url: https://administrator.de/contentid/325014

Printed on: April 19, 2024 at 14:04 o'clock

3 Comments

Latest comment

Moin,

PS.: Ich habe im internen DNS 2 primäre Forward-Lookup-Zonen angelegt, einmal "autodiscover.DOMAIN.TLD" und einmal "email.DOMAIN.TLD" und jeweils einen leeren Host-A Eintrag dort gesetzt auf die interne IP des Exchange-Servers.

hmm... so habe ich das noch nie versucht. Ich kenne es bisher nur so, dass eine Zone mit domain.tld angelegt wird und dort die beiden Hosts. Kann natürlich dazu führen, dass du alle DNS-Einträge die für die Domain existieren in diese Zone ebenfalls einpflegen musst. Unabhängig davon würde ich Wireshark mitlaufen lassen um zu sehen, wo er hängen bleibt.

Hast du bei einem Benutzer, bei dem Outlook problemlos funktioniert, das E-Mail AutoKonfiguration testen durchgeführt?

Gruß,
Dani

Zitat von @Dani:
hmm... so habe ich das noch nie versucht. Ich kenne es bisher nur so, dass eine Zone mit domain.tld angelegt wird und dort die beiden Hosts. Kann natürlich dazu führen, dass du alle DNS-Einträge die für die Domain existieren in diese Zone ebenfalls einpflegen musst. Unabhängig davon würde ich Wireshark mitlaufen lassen um zu sehen, wo er hängen bleibt.

Ich habe die Lösung mittlerweile gefunden (durch laaaanges laaaanges suchen..)

--> Nachdem ich erstmal den Server 2016 geupdatet habe und das CU4 für Exchange 2016 installiert habe und es immer noch keine Verbesserung gab habe ich mir noch einmal aufs genauste die virtuellen Verzeichnisse angeschaut. Und zwar dort NICHT nur die URLs, sondern auch die Berechtigungen. Und genau da war auch der Fehler. Beim virtuellen Verzeichnis der MAPI war KEINE Authentifizierungsmethode mehr ausgewählt, alle deaktiviert. Dies war wohl mal ein Bug in CU2/CU3, der erst mit CU4 behoben wurde, habe ich aber leider auch erst im Nachhinein gelesen..