https://gpsearch.azurewebsites.net/#12629
Deaktivier mal last known good in Autodiscover.
Habe ich jetzt gemacht, entsprechend in der Registry kontrolliert, ob es nach einem gpupdate /force auch durchgeführt wurde. Der Wert ist gesetzt, aber leider kein Erfolg. Beim Outlook Neustart kommt nach ca. 10 Sekunden die Warnmeldung.
gpupdate /force
Tut nix zu Sache, aber /force ist in diesem Fall und vielen anderen Fällen einfach nur überflüssig. ;)
Tja, ansonsten gehen mir inzwischen etwas die Ideen aus. Ich würde mich mental mal auf 100 neue Outlook Profile vorbereiten. Theoretisch kann man ein Outlook Profil mittels GPP und Registry Delete entfernen lassen und das neue kommt dann per Autodiscover. Bliebe halt ggf. das Problem, dass diverse Einstellungen der Nutzer natürlich dann weg sind.
Bye
Norbert
Ich habe es schon befürchtet. Ich danke dir trotzdem für deine Hilfe und Ansätze.
Falls noch sonst wer schlaue Ideen hat bin ich wie gesagt offen dafür-
Ich wollte nur noch mal eine Rückmeldung hier geben, weil sich die Situation für mich aktuell etwas seltsam darstellt. Nachdem ich jetzt das öffentliche Zertifikat seit ca. 1 Woche aktiv habe und bei den Nutzern noch keine neuen Profile erstellt habe zeigen sich hier 3 unterschiedliche Verhaltensweisen. Die Nutzer hatte ich vorab per Mail informiert, dass die Meldung kommen könnte, daher habe ich nur von wenigen bisher Rückmeldung erhalten.
Variante 1: Nutzer hat keinerlei Warnmeldungen bekommen (Gewünschtes bzw. erwartetes Verhalten)
Variante 2: Nutzer hat eine Zeit lang die Warnmeldung bekommen und mit "Ja" einfach bestätigt, bekommt aber jetzt seit gestern keine Meldung mehr. Das trifft z.Bsp. auf mich selbst zu(kann ich auch mit leben)
Variante 3: Nutzer bekommt die Warnung, kann aber problemlos mit "Ja" bestätigen und dann weiter arbeiten.
Ich verstehe nicht, wie diese unterschiedlichen Verhalten zu Stande kommen, aber ich werde jetzt einfach noch mal eine Zeit abwarten, vielleicht pendelt sich das bei den Nutzern die Variante 3 haben auch noch ein. Ansonsten werde ich für die halt neue Outlook-Profile erstellen, das sind dann hoffentlich nur wenige.
Ein „ist halt so“ stellt sich vermutlich nicht zufrieden, kommt aber der Realität meiner Erfahrung nach am nähesten. ;)
@dartzen hast Du denn das Problem irgendwie lösen können?
Ich habe aktuell genau das gleiche Verhalten eines einzelnen Exchange 2016 Servers. Auch die drei Varianten des Verhaltens der Client Outlooks, die Du in Deinem letzten Beitrag beschreibst sehe ich bei mir hier.
Bei den meisten Clients hat sich das Problem nach einiger Zeit von selbst gelöst, wobei das Verhalten wie geschrieben auch nie alle Clients hatten. Die 2-3 Stück, die partout nicht wollten haben ein neues Outlook Profil bekommen, damit trat das Problem dann nicht mehr auf. Keine Ahnung, was das verursacht hatte, ich hoffe halt nur, dass das beim nächsten erneuern des Zertifikats im April nicht wieder auftritt.
Danke für die schnelle Antwort. Eine Sache, die mir eben durch Zufall aufgefallen ist: Wenn man bei der Zertifikatswarnung "Möchten Sie den Vorgang fortsetzen?" mit "Nein" antwortet, dann funktioniert Outlook weiterhin normal UND die Warnung erscheint nicht mehr. Das hat bisher bei 5 Benutzern so funktioniert.
Weiß jemand was geschieht, wenn man die Warnung mit "Nein" ablehnt? Ich nahm an es kommt dann keine Verbindung zustande und die Warnung erscheint beim nächsten Start einfach wieder.
Weiß jemand was geschieht, wenn man die Warnung mit "Nein" ablehnt? Ich nahm an es kommt dann keine Verbindung zustande und die Warnung erscheint beim nächsten Start einfach wieder.
Sollte so sein, ja. Outlook vertraut ja dann der Gegenseite nicht und somit dann auch keine Verbindung zum Exchange herstellen können. Wenn der Cache-Modus an ist sollte es aber möglich sein, bereits vorhandene Mails zu lesen. Die Meldung kommt beim nächsten Starten wieder, es sei denn das bis dahin wie bei mir die "Wunderheilung" eingesetzt hat.
Sagen wir mal so: Ich scheine aktuell mit dem "Nein"-Klicken die Wunderheilung reproduzierbar anstoßen zu können. Outlook bleibt defintiv mit dem Exchange Server verbunden und beim Outlook-Neustart kommt danach keine Zertifikatswarnung mehr.
Und was passiert, wenn du auf ja klickst? ;) Dürfte den selben Effekt bringen.
Nein, gibt eben nicht genau den gleichen Effekt. Da die User standardmäßig mit "Ja" antworten, habe ich das nicht explizit erwähnt ;-) Also:
- Zertifikatswarnung mit "Ja" beantworten: Outlook verbindet sich, Zertifikatswarnung erscheint beim nächsten Start wieder.
- Zertifikatswarnung mit "Nein" beantworten: Outlook verbindet sich, Zertifikatswarnung erscheint beim nächsten Start NICHT mehr.
- Zertifikatswarnung mit "Ja" beantworten: Outlook verbindet sich, Zertifikatswarnung erscheint beim nächsten Start wieder.
OK, merkwürdig, aber dann stellt sich eben die Frage, wenn da eine Zertifikatswarnung kommt, welches Zertifikat wird dir präsentiert? Aber solange es mit "Nein" lösbar ist, vermutlich auch nicht so interessant, oder?
Sorry für die lange Funkstille. Naja, interessant finde ich es durchaus was da geschieht - nur verstanden habe ich es noch nicht ganz. Ich habe jetzt hier z.B. einen Client, der schön über 3 Wochen immer die Meldung mit "Ja" bestätigt hat und bei dem die Meldung bei jedem Start von Outlook erneut kam. Jetzt hat er gestern auf "Nein" geklickt und seither kommt die Meldung nicht mehr und es funktioniert alles.
Im Anhang nochmal die Fehlermeldung. Es wird das richtige Zertifikat ausgliefert (Let's Encrypt Zertifikat, das auf den extrenen Hostnamen lautet). Split DNS ist wie gesagt ebenfalls richtig eingerichtet, ich sehe überall wo es laut Anleitungen sein sollte nur den externen Hostnamen in Exchange. Auch Frankys Scripts zeigen nur den externen Hostnamen.
Dennoch scheint sich Exchange gegenüber Outlook Clients im internen Netz noch mit dem internen Hostnamen zu melden - bzw scheint das Problem ja eher auf der Clientseite zu liegen.