Neuer Exchange 2016 Probleme mit Outlook 2016 Autodiscoverdomäne falsch
Ich versuche seit einiger Zeit einen Exchange Server 2016 zu installieren, der dann auch noch mit Outlook 2016 von "intern" und "extern" funktionieren soll. Soweit ich alles aus Informationen zusammentragen konnte und mir das Exchange 2013 Buch half, kriege ich keine Verbindung mit Outlook hin. Jedes Mobilgerät geht, nur Outlook nicht. Es geht hierbei um ein einen Remotenutzer der keine Domänenmitgliedschaft hat.
Wie ist der Aufbau? Im entfernten Rechenzentrum ist ein Testaufbau. Dort sind zwei VMs wo einer DC ist und der anderer Exchange. Da eine statische IP anliegt ist der HTTPS Port an den Exchange durchgereicht. Die Statische IP habe ich mit zwei DNS Einträgen verpasst: xchange.externedomain.com, autodiscover.externedomain.com. In der Verwaltungsoberfläche von Exchange habe ich dann alle Internen und Externen URLs angepasst. Diese URLs kann man von Extern aufrufen ohne Probleme.
Erst hatte ich im Exchange Testnutzer angelegt natürlich mit der internen Emailadresse verbunden sind z.B.: benutzer1@contoso.int. Der Microsoft Remote Connectivity Analyzer funktionierte nur mit manueller Serverangabe richtig, Autoermittlung geht auf Grund einer internen Domain natürlich nicht. Also dachte ich, dass ich erstmal die externe Domain angeben muss. So habe ich im ECP unter Nachrichtenfluss->Akzeptierte Domänen, die Externe Domäne hinzugefügt. Der Benutzeranmeldename ist weiterhin der interne Name. Im AD steht bei der Emailadresse benutzer1@externedomain.com, genauso wie im ECP im Benutzerpostfach. Unter "Active Directoy Domänen und Vertrauensstellungen" habe ich noch den alternativen Benutzerprinzipialnamen externedomain.com hinzugefügt. Eigentlich wollte ich so ein Gefrickel vermeiden.
Ab diesem Zeitpunkt funktionierte dann der Microsoft Remote Connectivity Analyzer und hat einen "Grünen Haken" für Verbindungstests für Microsoft Exchange ActiveSync. Hierbei funktioniert es mit und ohne ActiveSync-AutoErmittlung. Auch Verbindungstests für Microsoft Office Outlook funktionierten ab diesem Zeitpunkt auch.
So nun dachte ich, Daten einfach im Outlook eintragen und gut ist. Tja leider verstehe ich die Logik der Software nicht. Ich konnte soweit nachvollziehen, dass
Warum xchange.contoso.int, wenn ihm doch die anderen Daten mitgeteilt wurden? Er müsste doch die ExternalDomain nehmen?
Ich habe keine Ahnung wo ich noch suchen kann. Es sind alles legale Programme aus dem MSActionPack. Zum Vergleich geht genau die gleiche Sache mit Outlook 2013 wieder problemlos.
Wie ist der Aufbau? Im entfernten Rechenzentrum ist ein Testaufbau. Dort sind zwei VMs wo einer DC ist und der anderer Exchange. Da eine statische IP anliegt ist der HTTPS Port an den Exchange durchgereicht. Die Statische IP habe ich mit zwei DNS Einträgen verpasst: xchange.externedomain.com, autodiscover.externedomain.com. In der Verwaltungsoberfläche von Exchange habe ich dann alle Internen und Externen URLs angepasst. Diese URLs kann man von Extern aufrufen ohne Probleme.
Erst hatte ich im Exchange Testnutzer angelegt natürlich mit der internen Emailadresse verbunden sind z.B.: benutzer1@contoso.int. Der Microsoft Remote Connectivity Analyzer funktionierte nur mit manueller Serverangabe richtig, Autoermittlung geht auf Grund einer internen Domain natürlich nicht. Also dachte ich, dass ich erstmal die externe Domain angeben muss. So habe ich im ECP unter Nachrichtenfluss->Akzeptierte Domänen, die Externe Domäne hinzugefügt. Der Benutzeranmeldename ist weiterhin der interne Name. Im AD steht bei der Emailadresse benutzer1@externedomain.com, genauso wie im ECP im Benutzerpostfach. Unter "Active Directoy Domänen und Vertrauensstellungen" habe ich noch den alternativen Benutzerprinzipialnamen externedomain.com hinzugefügt. Eigentlich wollte ich so ein Gefrickel vermeiden.
Ab diesem Zeitpunkt funktionierte dann der Microsoft Remote Connectivity Analyzer und hat einen "Grünen Haken" für Verbindungstests für Microsoft Exchange ActiveSync. Hierbei funktioniert es mit und ohne ActiveSync-AutoErmittlung. Auch Verbindungstests für Microsoft Office Outlook funktionierten ab diesem Zeitpunkt auch.
So nun dachte ich, Daten einfach im Outlook eintragen und gut ist. Tja leider verstehe ich die Logik der Software nicht. Ich konnte soweit nachvollziehen, dass
- SCP Lookup: geht nicht, da außerhalb der Domäne (könnte man über ExcludeScpLookup ausschalten)
- DNS Anfrage: externedomain.com
- Autodiscover Test: https://externedomain.com/autodiscover/autodiscover.xml (geht natürlich nicht, hierfür dann ExcludeHttpsRootDomain auf 1 in der Registry setzen)
- DNS Anfrage: autodiscover.externedomain.com
- Autodiscover Test: https://autodiscover.externedomain.com/autodiscover/autodiscover.xml (lokale Anmeldedaten eingeben, dann geht es) Rückmeldung: ein XML File, mit Daten wie z.B. InternalUrl und ExternalUrl für MAPI, OWA, EXHTTP
- Outlook meldet: "Herzlichen Glückwunsch! Das E-Mail-Konto wurde erfolgreich konfiguriert und kann jetzt verwendet werden."
- Beim Outlook Neustart: Outlook funktioniert nicht und bleibt beim Ladelogo hängen. Grund: mehrfache Verbindungsaufbauversuche auf xchange.contoso.int, mit Abbruchmeldung keine Verbindung zum Exchangeserver. Die xchange.externedomain.com interessiert ihm gar nicht.
Warum xchange.contoso.int, wenn ihm doch die anderen Daten mitgeteilt wurden? Er müsste doch die ExternalDomain nehmen?
Ich habe keine Ahnung wo ich noch suchen kann. Es sind alles legale Programme aus dem MSActionPack. Zum Vergleich geht genau die gleiche Sache mit Outlook 2013 wieder problemlos.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 302021
Url: https://administrator.de/forum/neuer-exchange-2016-probleme-mit-outlook-2016-autodiscoverdomaene-falsch-302021.html
Ausgedruckt am: 23.12.2024 um 04:12 Uhr
6 Kommentare
Neuester Kommentar
Moin,
was spuckt https://testconnectivity.microsoft.com/ GENAU aus, wenn du den Outlook Autodiscover test machst und auch den ganzen Baum öffnest? Ich gehe davon aus, dass du die Pfade der virtuellen Verzeichnisse im Exchange angepasst hast und auch ein öffentliches Zertifikat nutzt, wo alle SAN eingetragen sind.
Dein MAPI over HTTP Verzeichnis steht wahrscheinlich auf "xchange.contoso.int". Das musst du über die Exchange PowerShell anpassen. Kannst du glaube ich mit dem Befehl Get-MapiVirtualDirectory -Server DEINSERVER auslesen.
Wo du wie ich finde auch eine gute Übersicht über AutoDiscover Einträge bekommst: Mit gedrückter Strg Taste einen rechtsklick auf das gestartete Outlook Symbol in der Taskleiste unten rechts und dann Autokonfiguration testen. Hier dann Mail + PW eintragen. Solltest du von dem PC testen, der extern steht und nicht in der Domäne hängt.
Weil sich Outlook Standardmäßig über MAPI versucht zu verbinden. Das umstellen des virtuellen Verzeichnisses wird dann gerne vergessen. Die Haken werden zwar alle Grün, nach einem Outlook Neustart geht aber gar nichts mehr.
was spuckt https://testconnectivity.microsoft.com/ GENAU aus, wenn du den Outlook Autodiscover test machst und auch den ganzen Baum öffnest? Ich gehe davon aus, dass du die Pfade der virtuellen Verzeichnisse im Exchange angepasst hast und auch ein öffentliches Zertifikat nutzt, wo alle SAN eingetragen sind.
Dein MAPI over HTTP Verzeichnis steht wahrscheinlich auf "xchange.contoso.int". Das musst du über die Exchange PowerShell anpassen. Kannst du glaube ich mit dem Befehl Get-MapiVirtualDirectory -Server DEINSERVER auslesen.
Wo du wie ich finde auch eine gute Übersicht über AutoDiscover Einträge bekommst: Mit gedrückter Strg Taste einen rechtsklick auf das gestartete Outlook Symbol in der Taskleiste unten rechts und dann Autokonfiguration testen. Hier dann Mail + PW eintragen. Solltest du von dem PC testen, der extern steht und nicht in der Domäne hängt.
Zitat von @hronny:
Warum xchange.contoso.int, wenn ihm doch die anderen Daten mitgeteilt wurden? Er müsste doch die ExternalDomain nehmen?
Warum xchange.contoso.int, wenn ihm doch die anderen Daten mitgeteilt wurden? Er müsste doch die ExternalDomain nehmen?
Weil sich Outlook Standardmäßig über MAPI versucht zu verbinden. Das umstellen des virtuellen Verzeichnisses wird dann gerne vergessen. Die Haken werden zwar alle Grün, nach einem Outlook Neustart geht aber gar nichts mehr.
Und für die die sich die komplette URL-Config von einem Skript abnehmen lassen wollen, habe ich da was auf Lager welches auch MAPI over HTTP berücksichtigt, das ist nämlich eine gern gesehene Falle die übersehen wird. Ein aktuelles Outlook 2016 weigert sich dann hartnäckig wenn es auf dem EX2016 nicht richtig konfiguriert/eingerichtet ist.
Powershell: Konfigurieren der internen und externen URLs von Exchange Server 2013, 2016
Grüße Uwe
Powershell: Konfigurieren der internen und externen URLs von Exchange Server 2013, 2016
Grüße Uwe
Im Webinterface sind jedoch nicht alle URLs änderbar...
2016 versucht immer die lokale autodiscover Domain zu holen.
Dann Profil löschen und neues anlegen, und Windows Profil ebenso neu anlegen. Outlook neigt dazu alle möglichen Dinge im Profil zu cachen.
Mache ich persönlich inzwischen immer so, da inzwischen in öffentlichen Zertifikaten keine internen TLDs mehr enthalten sein dürfen.
Intern verwende ich dann meist eine Subdomain des externen verwendeten DNS-Namespaces.
Outlook 2016 verzeit keinerlei Fehler mehr in der Exchange-Config, und das ist meiner Meinung nach auch gut so und schon längst überfällig, denn so werden die Admins endlich gezwungen Ihren Exchange ordentlich einzurichten. Er ist halt kein Spielzeug den man mal ebenso ohne jegliches Grundlagen-Wissen auf Klicki-Bunti Admins loslassen sollte.
Mit mehr Log-Posts aus deinem Exchange und dem Autodiscover-Prozess am Client (s. Kommentar von MasterPhil) können wir mehr sagen was bei dir eventuell schief läuft.
Grüße Uwe
2016 versucht immer die lokale autodiscover Domain zu holen.
Interessant ist, dass in der Hilfe vom Skript auch die interne Domain keine *.local ist, sondern auch contoso.com:
Das sind alles nur Demo-Namen, diese haben keine Bedeutung.An sich ist es ja egal, ich habe nun den internen und externen Namen gleich gesetzt und im lokalen DNS den Namen auf den Exchange gesetzt. Ich glaube nicht, dass es so gedacht ist,
Doch, das ist allgemein gebräuchlich und nennt sich Split-Brain-DNS.Mache ich persönlich inzwischen immer so, da inzwischen in öffentlichen Zertifikaten keine internen TLDs mehr enthalten sein dürfen.
Intern verwende ich dann meist eine Subdomain des externen verwendeten DNS-Namespaces.
denn dann bräuchte man den Internen oder externen Namen nicht. Dafür gehts nun auch mit Outlook 2016.
Das Zertiikat muss alle DNS Namen enthalten die verwendet werden, also auch die Autodiscover Sub-Domain. Ist das nicht der Fall kann es in OL2016 durchaus ohne Zertifikatsfehlermeldung zum Abbruch kommen.Outlook 2016 verzeit keinerlei Fehler mehr in der Exchange-Config, und das ist meiner Meinung nach auch gut so und schon längst überfällig, denn so werden die Admins endlich gezwungen Ihren Exchange ordentlich einzurichten. Er ist halt kein Spielzeug den man mal ebenso ohne jegliches Grundlagen-Wissen auf Klicki-Bunti Admins loslassen sollte.
Mit mehr Log-Posts aus deinem Exchange und dem Autodiscover-Prozess am Client (s. Kommentar von MasterPhil) können wir mehr sagen was bei dir eventuell schief läuft.
Grüße Uwe
Moin,
Würde er die Subdomain auch nicht finden macht er beim _SRV-Record im DNS weiter und zum Schluss würde die IIS-Umleitung geprüft. Das vorherige Prüfungen fehlschlagen ist absolut OK solange eine Prüfung erfolgreich ist.
An der Stelle musste ich noch nie schrauben, und ich habe jetzt schon bestimmt 30 EX2016 aufgesetzt und mit OL2016 auch keine dieser Probleme gehabt, egal ob der Client innerhalb oder außerhalb der Domain war.
D.h. irgendwas muss bei dir anders laufen als normal. Aber ohne weitere Info aus den Logs wird das hier zum Glaskugel-Bowling...
Gruß jodel32
Meine Anmerkung ist dennoch, das Microsoft entgegen ihrer eigenen Dokumentation, trotzdem erst die TLD abfragt,
Das ist vollkommen normal.und dann die autodiscover Domain testet. Den Nutzer stört es nicht, der Admin verzweifelt. Daher Stichwort ExcludeHttpsRootDomain. Sonst verzweifelt man am Autodiscovertest von Outlook.
Das ist der normale Autodiscover-Prozess und stört in keinster Weise die Funktion von Outlook so lange dort keine Autodiscover.xml hinterlegt ist.Würde er die Subdomain auch nicht finden macht er beim _SRV-Record im DNS weiter und zum Schluss würde die IIS-Umleitung geprüft. Das vorherige Prüfungen fehlschlagen ist absolut OK solange eine Prüfung erfolgreich ist.
An der Stelle musste ich noch nie schrauben, und ich habe jetzt schon bestimmt 30 EX2016 aufgesetzt und mit OL2016 auch keine dieser Probleme gehabt, egal ob der Client innerhalb oder außerhalb der Domain war.
D.h. irgendwas muss bei dir anders laufen als normal. Aber ohne weitere Info aus den Logs wird das hier zum Glaskugel-Bowling...
Gruß jodel32