Hallo,

hört sich für mich nach DNS an. Welche DNS Einstellungen wurden an den Clients denn gemacht? Wenn da was anderes, als der interne DNS drinsteht kann es da immer wieder zu Problemen kommen. DNS Anfragen nach Extern sollten immer per Forward vom DNS Server gemacht werden, nicht vom Client.

Gruß

@carstengeh, an den Clients wurden keine Einstellungen verändert. Nur am Exchange wurden die DNS Zonen für autodiscover.contoso.com und outlook.contoso.com erstellt wie im Beitrag von Frank erläutert. Wenn ich das Zertifiakt in der Fehlermeldung anschaue, dann ist der Antragsteller unsere feste IP (also der Hoster). Die Clients sollten bei Abfrage von autodiscover... oder outlook... nur den lokalen Exchange server finden (funktioniert über nslookup bei den Clients immer) Ich verstehe nicht, warum die Clients das Zertifiakt des Hosters erhalten. Das Netzwerk wurde 2018 aufgesetzt und es gab bis ca. Anfang des Jahres diesen Fehler nicht. Der Fehler trat dann irgendwann immer wieder auf, ohne das in den Einstellungen etwas geändert wurde. Der Fehler tritt auf bei einem Client mit Outlook 2016 und bei einem Client mit Outlook 2019.

@tlutz

Auch wenn nichts geändert wurde schaue doch einfach mal was die DNS Einstellungen an den Clients sind. Ich sage das deswegen, weil ich bei unserem Server Upgrade vor ein paar Jahre genau das selbe Problem hatte und es lief am Ende auf falsche DNS Einstellungen hinaus. Natürlich kann es bei dir was Anderes sein, aber wie gesagt, hört sich halt sehr nach DNS an.

Damals bin ich der Sache nur mit Wireshark auf die Spur gekommen. Da konnte ich genau gesehen, dass die Clients den falschen DNS kontaktiert haben. Vielleicht hilft dir das auch weiter.

Gruß

@carstengeh

ich dachte auch an einen DNS-Fehler, da ich das Problem manchmal durhc Ipconfig /renew behebne kann. Allerdings sehe ich keinen Fehler in der Konfiguration. Am Client zeigt mir ipconfig wie auch nslookup immer den richtigen Server. Outlook.contoso.com findet immer den Exchange Server, aber Outlook selbst findet ihn anscheinend manchmal nicht. Hast Du einen Vorschlag was ich noch prüfen könnte? Wireshark habe ich noch nicht ausprobiert.

Grüße

Veröffentlicht von: @tlutz

@carstengeh

ich dachte auch an einen DNS-Fehler, da ich das Problem manchmal durhc Ipconfig /renew behebne kann. Allerdings sehe ich keinen Fehler in der Konfiguration.

Da ich leider immer noch nicht weiß, was deine Konfiguration ist, ist es schwer hier Ratschläge zu geben. Wireshark ist die Beste, die mir gerade einfällt. Für mehr bräuchte man wirklich mehr Infos zum Aufbau, Konfiguration etc.

Gruß 

@carstengeh

ich habe jetzt Wireshark mal laufen lassen- Da ist mir aufgefallen, dass der Client eine Anfrage an den DNS-Server stellt nach unserem alten Domainencontroller. Der neue Name ist XXXX01, der alte war YYYYY01. den server YYYYY01 gibt es schon seit 2 Jahren nicht mehr. Ich habe keine Ahnung, wo ich da suchen soll, um den Eintrag YYYYY01 zu löschen.

Ein nslookup auf den alten Server YYYYY01 zeigt mir den neuen Server XXXX01 und die korrekte IP. Da liegt wohl der erste Fehler, aber ich weiß nicht wo ich das einstellen kann

Gruß

Servus,

wie Carsten schon ganz richtig geschrieben hat, es liegt am DNS. Schau mal in das Autodiscover Whitepaper und zwar ganz konkret bei dem Punkt "Autodiscover Root Domain Abfrage":

https://www.frankysweb.de/exchange-2016-umfangreiches-whitepaper-zu-autodiscover/

Gruß,

Frank

Hi,

ggf liegt auch an einer ggf nicht sauber bereinigten AD Server Konfig (Sites & Services).
Hier darf es keine Verweise auf den alten DC mehr geben. Weiterhin gibt es ggf. auch noch einen Static DNS Record mit dem alten Servernamen des DC's

Wenn ihr O365 Lizenzen nutzt und ggf ADFS konfiguriert habt, kann es auch sein, dass der Client Autodiscover in die Cloud macht. Das war bei uns der Fall und wir mussten es per GPO deaktivieren.

Der Client macht Autodiscover eben nicht nur bei der Autoermittlung zur Einrichtung von Outlook, sondern auch regelmäßig im Hintergrund.

Prüf es auf einem Problemclient mit "Fiddler", sonst kannst du nicht in den SSL Traffic sehen.

Monthy

@monthy,

DC und Exchange server wurden vor einiger Zeit neu aufgesetzt. Ich finde keinerlei Hinweise auf den alten Exchange server. Per GPO habe ich am Client auch die Root Domain Abfrage deaktiviert. Ich erhalte immer noch sporadisch die Fehler. Habe jetzt Fiddler mal durchlaufen lassen. Die Abfragen gehen immer nach outlook.contoso.com und alles läuft prima (bzw. "Tunnel to outlook.contoso.com:443") CN ist dann autodiscover.contoso.com und "Subject Alt Names" ist outlook.contoso.com und autodiscover.contoso.com.

Beim Auftreten des Zertifikatsfehlers sehe ich "Tunnel to outlook.office365.com:443" CN ist dann outlook.com von Microsoft und die Liste der Subject Alt Names ist lang mit Einträgen wie outlook.com, office365.com...

Die Verbindung von meinem Outlook Client zum Server besteht momentan noch, wenn ich die Zertifikatswarnung wegklicke.

Keine Ahnung wo diese Office 365 Geschichte herkommt. Das haben wir nie eingesetzt. Könnte dies das Problem sein?

Thomas

Hallo,

ich habe weiter recherchiert und möglicherweise eine Lösung gefunden, die auch für Andere hilfreich sein könnte. Microsoft hat wohl das Autodiscover Verhalten geändert, wodurch Outlook versucht, ein Office365 Konto zu finden. Beschreibung und Lösungsansatz Siehe hier: https://wissen.qualityhosting.de/s/article/geaendertes-autodiscover-verhalten-in-outlook

Ich habe den Registry Eintrag entsprechend der Anleitung geändert, aber das Verhalten von Outlook blieb gleich. Dann habe ich das Profil neu erstellt. Jetzt läuft der Problem-Client seit ca. 48h, ohne dass dieses Problem auftritt. Ich beobachte weiter, aber dies könnte die Lösung sein

Thomas