6
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.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 302021
Url: https://administrator.de/contentid/302021
Ausgedruckt am: 22.11.2024 um 17:11 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
Also https://testconnectivity.microsoft.com/ spuckt aus:
Connectivity Test Successful with Warnings
Bei den einzelnen Punkten gibt es nur eine Warnung, klar weil die Domain ohne autodiscover nicht funktioniert:
Du hast recht, das Zertifikat ist erstmal gültig. Aber bevor nicht alles richtig geht, habe ich mit Letsencrypt ein 3 Monats-zertifikat erzeugt habe, was zu meinem Erstaunen problemlos geht. Die virtuellen Verzeichnisse hatte ich bereits im Webinterface geändert. Das mit dem Mapi hatte ich schon im verdacht.
Eine Exchangeänderung mit dem verlinkten Skript habe ich durchgeführt, leider auch nach Serverneustart ohne Erfolg. Bzw gleiches Ergebnis: Outlook 2013 problemlos, 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:
'C:\path\set-exchange-urls.ps1' -ExchangeServer EXSRV2013.domain.local -InternalFQDN "mail.contoso.com" -ExternalFQDN "owa.contoso.com"
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, denn dann bräuchte man den Internen oder externen Namen nicht. Dafür gehts nun auch mit Outlook 2016.
Für andere Ideen bin ich gerne offen. Ende des Monats erscheint von Thomas Joos das Buch Microsoft Exchange Server 2016 - Das Handbuch: Von der Einrichtung bis zum reibungslosen Betrieb. Vielleicht löst das noch einige Rätsel.
Connectivity Test Successful with Warnings
Bei den einzelnen Punkten gibt es nur eine Warnung, klar weil die Domain ohne autodiscover nicht funktioniert:
- Autodiscover was successfully tested for Exchange ActiveSync.
- The Autodiscover service was tested successfully.
- Attempting to test potential Autodiscover URL https://externedomain.com:443/Autodiscover/Autodiscover.xml : Testing of this potential Autodiscover URL failed.
- Attempting to test potential Autodiscover URL https://autodiscover.externedomain.com:443/Autodiscover/Autodiscover.xml : Testing of the Autodiscover URL was successful.
Du hast recht, das Zertifikat ist erstmal gültig. Aber bevor nicht alles richtig geht, habe ich mit Letsencrypt ein 3 Monats-zertifikat erzeugt habe, was zu meinem Erstaunen problemlos geht. Die virtuellen Verzeichnisse hatte ich bereits im Webinterface geändert. Das mit dem Mapi hatte ich schon im verdacht.
Eine Exchangeänderung mit dem verlinkten Skript habe ich durchgeführt, leider auch nach Serverneustart ohne Erfolg. Bzw gleiches Ergebnis: Outlook 2013 problemlos, 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:
'C:\path\set-exchange-urls.ps1' -ExchangeServer EXSRV2013.domain.local -InternalFQDN "mail.contoso.com" -ExternalFQDN "owa.contoso.com"
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, denn dann bräuchte man den Internen oder externen Namen nicht. Dafür gehts nun auch mit Outlook 2016.
Für andere Ideen bin ich gerne offen. Ende des Monats erscheint von Thomas Joos das Buch Microsoft Exchange Server 2016 - Das Handbuch: Von der Einrichtung bis zum reibungslosen Betrieb. Vielleicht löst das noch einige Rätsel.
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
Das im Webinterface nicht alle URLs änderbar sind wusste ich, da du schon weiter oben das geschrieben hast. Ich war mir nur nicht sicher, ob ich die Mapieinstellung bereits geändert habe. Solche Hinweise sind schon hilfreich, wenn man solche Probleme hat.
Meine Anmerkung ist dennoch, das Microsoft entgegen ihrer eigenen Dokumentation, trotzdem erst die TLD abfragt, 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.
Daher viel am eigenen Server testen, bevor man wichtiges zerstört. Exchange ist schon ein mächtiges Stück, da gebe ich den Gegnern auch Recht.
Nur bleibt weiterhin für mich unklar, ob, wie und wann Outlook zwischen Interne uns Extern umschaltet, oder nur bei der Einrichtung definiert wird. Wahrscheinlich sollte ich mir darüber nicht den Kopf zerbrechen. Wie gesagt es funktioniert ja nun soweit, dank dem SplitDNS.
Danke.
Dann Profil löschen und neues anlegen, und Windows Profil ebenso neu anlegen. Outlook neigt dazu alle möglichen Dinge im Profil zu cachen.
Das stimmt, bewirkt leider gar nichts. Wenn jemand das System nach getrennter interner und externer Domain (wie ich es beschrieben habe) einrichtet und kein SplitDNS des externen Domainnamen verwendet, wird mit Outlook 2016 keine Chance haben. Und das sehe ich nicht als Konfigurationsfehler, sondern als Bug. Und es geht in meinem Fall immer um die Einrichtung eines externen Rechners, der weder in der Domäne noch im gleichen Netzwerk ist. Intern ist ja alles prima. Aber gut, ich werde da selbst nichts ändern können und kenne zumindest die Stelle die anpacken muss.Das Zertiikat muss alle DNS Namen enthalten die verwendet werden...
Ich denke wer mit dieser Aussage nichts anzufangen weiß, darf in dieser Situation keinen Exchange benutzen und muss ich Grundlagen aneignen. Zertifikate sind essentiell und das ist bei dem Produkt ja nicht neu. Klar, ihr versucht mir zu helfen, da man ja vom dümmsten/simpelsten Fall ausgehen muss. Den Domainnamen für den externen Aufruf, habe ich wir in ersten Artikel beschieben mit einer Sub-Domain gemacht. Daher ist im Zertifikat xchange.externedomain.com und autodiscover.externedomain.com enthalten.Meine Anmerkung ist dennoch, das Microsoft entgegen ihrer eigenen Dokumentation, trotzdem erst die TLD abfragt, 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.
Er ist halt kein Spielzeug den man mal ebenso ohne jegliches Grundlagen-Wissen auf Klicki-Bunti Admins loslassen sollte.
Da gebe ich dir vollkommen recht. Daher habe ich mich schon lange mit dem Thema auseinandergesetzt. Zugegeben ist es für unsere Firma Spielerei, aber da das Produkt immer komplizierter wird und viele Kunden gezwungen werden sind sich speziell Exchange anzuschaffen (wegen Branchensoftware, DMS, usw.), wäre es schon blöd du hast überhaupt keine Ahnung. Wenn man Kunden schon länger betreut, und dann wegen sowas aus dem Rennen ist wäre schon schade.Daher viel am eigenen Server testen, bevor man wichtiges zerstört. Exchange ist schon ein mächtiges Stück, da gebe ich den Gegnern auch Recht.
Nur bleibt weiterhin für mich unklar, ob, wie und wann Outlook zwischen Interne uns Extern umschaltet, oder nur bei der Einrichtung definiert wird. Wahrscheinlich sollte ich mir darüber nicht den Kopf zerbrechen. Wie gesagt es funktioniert ja nun soweit, dank dem SplitDNS.
Danke.
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
1
