Beste Lösung Squire 261 Geschrieben 25. Januar 2023 Beste Lösung Melden Teilen Geschrieben 25. Januar 2023 Hallo, ich hatte gestern ein Phänomen, das ich mir nicht so ganz erklären kann ... Umgebung: AD, mehrere Domänen, eine Exchange Organisation (mehrere 2016er Server). Bei uns eine DAG (2 Server) hinter einem Kemp Päarchen. Hybrid Szenario für O365 (Mailboxen alle on Prem) Ziel: Dazu sollen jetzt zwei 2019er Exchange als DAG kommen. Die Mailboxen aus der 2016er DAG sollen auf die 2019er verschoben und die 16er dann zurückgebaut werden. Stand jetzt Ein 2019er wurde installiert, die virtuellen Verzeichnisse identisch zu den 2016ern gesetzt. SplitDNS ist im Einsatz. Das öffentliche Zertifikat, welches wir auf den 2016ern verwenden hab ich auch im 2019er drin. Der 2019er ist bisher noch in keinem Connector hinterlegt, ebenso wurde der 2019er nicht am Kemp bekannt gemacht. Die SCPs zeigen alle auf die virtuelle Adresse/Namen des Kemp Jetzt das, was ich nicht verstehe ... Outlook bringt eine Zertifikatswarnung, dass auf dem korrekten öffentlichen Zertifikat der interne Name nicht drauf ist. Sprich der Server meldet sich bei Outlook mit seinem internen Namen und mit dem korrekten externen Zertifikat. Wie kann das eigentlich sein? Outlook quatscht doch normal über den virtuellen Service auf den Kemp Loadbalancern zu den Exchangeservern. Wieso die Meldung des 2019ern? Mein Plan war die beiden 2019er fertig zu installieren, virtuelle Verzeichnisse zu setzen, Zertifikat einspielen, DAG erstellen, dann am Kemp bekannt machen (sollte hierzu ein neuer Service angelegt werden oder kann ich die bei den 2016ern mit hinzufügen?), Connectoren anpassen (Sendeconnectoren) ... Im Moment hab ich den 2019er wieder heruntergefahren, um die User durch die Zertifikatsfehler nicht zu irritieren. Frage: Passt mein Upgrade Weg? Warum kommt der Zertifikatsfehler? Zitieren Link zu diesem Kommentar
cj_berlin 1.315 Geschrieben 25. Januar 2023 Melden Teilen Geschrieben 25. Januar 2023 Moin, der Upgrade-Weg ist genau richtig, Vermutlich hat sich da zeitlich etwas überschnitten - oder Du hast einen der virtuellen Verzeichnisse auf dem neuen Server vergessen. Ein heruntergefahrener Exchange-Server sollte kein dauerhafter Zustand sein, das macht mehr Probleme als Zertifikatswarnungen bei Usern. Zitieren Link zu diesem Kommentar
Squire 261 Geschrieben 25. Januar 2023 Autor Melden Teilen Geschrieben 25. Januar 2023 @cj_berlin Guten Morgen Evgenij, ich hab die Verzeichnisse mit Frankys Script ausgelesen und gesetzt (Dieses hier) man muss ja das Rad nicht zweimal erfinden. Auf Dauer lass ich den Exchange eh nicht aus. Ich denk fast, dass ich die Geschichte erst am Wochenende weiter verfolge. Dann rufen nicht gleich irgendwelche User an und motzen ... Aber schön, dass Du meinen Weg bestätigst, hatte schon an mir zu zweifeln begonnen Noch eine Frage zu dem Hybrid Gedöns, das ist in der Tat für mich relativ neu ... muss ich da den Hybrid Wizard nochmal laufen lassen, oder genügt es die beiden neuen Exchange in den Connectoren hinzuzufügen? Zitieren Link zu diesem Kommentar
NorbertFe 2.034 Geschrieben 25. Januar 2023 Melden Teilen Geschrieben 25. Januar 2023 vor 16 Minuten schrieb cj_berlin: oder Du hast einen der virtuellen Verzeichnisse auf dem neuen Server vergessen. Die sind egal, wenn der scp auf die bisherigen Server zeigt. Aber meist ist es ein caching des iis, wenn man das nicht schnell genug ändert, und dann noch caching am Client. Muss man halt mal durch. ;) Zitieren Link zu diesem Kommentar
Squire 261 Geschrieben 25. Januar 2023 Autor Melden Teilen Geschrieben 25. Januar 2023 (bearbeitet) die SCPs zeigen alle auf die virtuellen Services am Kemp. Ja ist schon lustig ... mal ist man nicht schnell genug, mal muss man "ewig" warten, bis die Replikation durch ist ... was mich aber trotzdem interessiert ist, wie der Client den 2019er findet, wenn doch die SCPs auf den Kemp zeigen und der den auch noch nicht kennt... bearbeitet 25. Januar 2023 von Squire Zitieren Link zu diesem Kommentar
cj_berlin 1.315 Geschrieben 25. Januar 2023 Melden Teilen Geschrieben 25. Januar 2023 Darum haben Firmen, die ständig neue Exchange Server installieren, dafür eine separate Installations-Site im AD. Zitieren Link zu diesem Kommentar
NorbertFe 2.034 Geschrieben 25. Januar 2023 Melden Teilen Geschrieben 25. Januar 2023 Naja kommt halt drauf an, wie lang die Replikation dauert bei euch, wenn ihr mehrere exchangeserver habt, werden es wohl mehrere Standorte sein und damit eben genügend zeitliche Verzögerungen inklusive caching. ;) Gerade eben schrieb cj_berlin: Darum haben Firmen, die ständig neue Exchange Server installieren, dafür eine separate Installations-Site im AD. Ich wollt’s grad schreiben. ;) alternativ setzt man den scp eben bereits während des setups sobald er auftaucht. Klappt auch „meist“. 1 Zitieren Link zu diesem Kommentar
mikro 67 Geschrieben 25. Januar 2023 Melden Teilen Geschrieben 25. Januar 2023 HCW sollte neu ausgeführt werden, wie nach jedem anderen Update auch. vor 12 Minuten schrieb Squire: Noch eine Frage zu dem Hybrid Gedöns, das ist in der Tat für mich relativ neu ... muss ich da den Hybrid Wizard nochmal laufen lassen, oder genügt es die beiden neuen Exchange in den Connectoren hinzuzufügen Zitieren Link zu diesem Kommentar
Squire 261 Geschrieben 2. Februar 2023 Autor Melden Teilen Geschrieben 2. Februar 2023 Seit dem Wochenende sind beide 2019er aufgesetzt, DAG eingerichtet und keine Zertifikatsmeckereien am Montag ... Mein oben beschriebener Weg war genau richtig. Hat ja der Kollege @cj_berlin auch bestätigt. Jetzt müssen noch ein paar Anpassungen für die "Um-Systeme" [Mailarchivierung, MDM, Disclaimerlösung] vorgenommen werden ... dann geht das Mailboxschubsen an. Zitieren Link zu diesem Kommentar
Squire 261 Geschrieben 9. Mai 2023 Autor Melden Teilen Geschrieben 9. Mai 2023 Kleiner Nachtrag zur Zertifikatthematik ... nachdem ich nun mit dem Upgrade auf die 2019er durch bin ... Wenn man vor der Installation eines neuen Exchange 2019 ein internes passendes SAN Zertifikat in den Zertifikatstore des Servers packt, so nutzt Exchange 2019 dieses standardmäßig für seine Dienste. Bei den Clients poppt dann keine Zertifikatswarnung auf. Man kann dann in aller Ruhe die virtuellen Verzeichnisse setzen und ggf. ein öffentliches SAN Zertifikat setzen. (Bei uns für die Exchange Installationen in den Niederlassungen nicht notwendig, da der MX hier bei uns in der Zentrale liegt. Sprich die Clients kommen von Extern bei uns an und werden dann zu den Niederlassungs-Exchange weitergeleitet. Die URLs auf den Remote Exchange Servern zeigen intern auf eine andere Adresse) Zitieren Link zu diesem Kommentar
NorbertFe 2.034 Geschrieben 9. Mai 2023 Melden Teilen Geschrieben 9. Mai 2023 vor 54 Minuten schrieb Squire: da der MX hier bei uns in der Zentrale liegt. der mx hat aber mit dem Zugriff auf Exchange (https) gar nix zu tun. Oder ist das wieder so eine Abkürzung für Microsoft eXchange? ;) Zitieren Link zu diesem Kommentar
Squire 261 Geschrieben 9. Mai 2023 Autor Melden Teilen Geschrieben 9. Mai 2023 (bearbeitet) Richtig - ungenau ausgedrückt! Der "richtige" MX liegt bei uns auf einem NSP - gemeint waren die Microsoft Exchange "Endpoints" über die, die Outlook Clients unsere Exchange Org von außen kontaktieren bearbeitet 9. Mai 2023 von Squire Zitieren Link zu diesem Kommentar
NorbertFe 2.034 Geschrieben 9. Mai 2023 Melden Teilen Geschrieben 9. Mai 2023 Gibt also mehrere Möglichkeiten, die Zertifikatswarnungen zu vermeiden. Zitieren Link zu diesem Kommentar
Squire 261 Geschrieben 9. Mai 2023 Autor Melden Teilen Geschrieben 9. Mai 2023 (bearbeitet) ja - ich find diese hier am elegantesten und einfachsten. Vor allem, dass sich der 2019er da das vorhandene Zert schnappt ist gut - es muss halt den internen FQDN des Servers halten bearbeitet 9. Mai 2023 von Squire Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.