Hallo,
ich habe eine Frage. Bei mir hat sich die Email Domain geändert (AD Domain hat sich nicht geändert). Das habe ich auch soweit geändert und alle Benutzer können über die neue akzeptierte Domain senden und empfangen, das klappt alles gut.
Doch ich möchte auch gern die Domain für OWA, aber auch für ECP, MAPI etc. ändern. Bisher haben wir z.B. owa.a-domain.de und jetzt soll das auf owa.b-domain.de geändert werden.
Ich würde das so lösen, das ich den Exchange 2016 auf 2019 migriere, da wir eh nach 2019 hin möchten. Der alte Server behält die alte Domain und der neue Server bekommt die neue Domain.
In meiner Testumgebung habe ich das nachgestellt und das funktioniert soweit. Alle Postfächer sind auf 2019 migriert. Doch jetzt komme ich zu meinem Problem. Wenn der Exchange 2016 jetzt abgeschaltet wird, kann Outlook keine Verbindung mehr aufbauen. Erst wenn ich ein neues Outlook Profil anlege funktioniert dies.
Ändere ich zum Beispiel die DNS Einträge für die alte Domain so ab, das diese einfach auf dem neuen Server zeigen, funktioniert dies, doch es kommt ein Zertifikatsfehler.
Solange ich kein neues Outlook Profil anlege, zeigt er weiterhin auf den Eintrag mapi.a-domain.de. Und der neue Server hat ja nur ein Zertifikat für mapi.b-domain.de.
Wie kann ich das Problem lösen, ohne das bei den Benutzern überall ein neues Outlook Profil angelegt werden muss und das auch kein Zertifikatsfehler kommt?
Die autodiscoverservice Uri zeigt wohin? Get-clientaccessservice.
Ich habe leider hier Probleme etwas im Forum zu schreiben. Es kommt immer "Moderation ausstehend".
Ich hatte noch weitere Tests durchgeführt und eine teilweise Lösung gefunden.
Aber erst mal zu deiner Frage. Der SCP bzw. AutoDiscoverServiceInternalUri stand auf folgende Werte:
alter Server Exchange 2016:
alte Domain (Leider kann ich das hier nich schreiben, weil sonst der Beitrag nicht gesendet werden kann.)
neuer Server Exchange 2019:
neue Domain (Leider kann ich das hier nich schreiben, weil sonst der Beitrag nicht gesendet werden kann.)
Ich habe dann den Wert für den alten Server dann später auch auf die neue Domain gelegt.
Solange beide Server aktiv sind, gibt es keine Probleme. Die Outlook Clients (ohne neues Profil zu erstellen) verbinden sich mal mit dem alten Server und mal mit dem neuen Server. Sind sie mit dem neuen Server als letztes verbunden und wird dann der alte Exchange 2016 abgeschaltet funktionieren diese ohne Probleme weiterhin. Also auch nach längerer Zeit, Neustart des Clients usw.
Waren diese mit dem alten Exchange 2016 verbunden, können sie sich nach der Abschaltung von diesem nicht mehr verbinden.
Deinstalliere ich den Exchange 2016 komplett, tritt das gleiche Verhalten auf. Ändere ich den alten MAPI Eintrag (mapi.a-domain.de) ab, sodass dieser auf dem neuen Server zeigt, können die Clients sich wieder verbinden, aber natürlich mit einer Zertifikatswarnung. Dabei werden beim ersten Start die Einträge aber so abgeändert, das er in Zukunft nur noch mit der neuen Domain verbindet (mapi.b-domain.de). Trotzdem kommt für autodiscover.a-domain.de weiterhin eine Zertifikatsfehlermeldung. Obwohl es in der AD darauf keinen Verweis mehr gibt. Doch hier reicht es einfach diesen DNS Eintrag im DNS zu löschen, danach gibt es keine Probleme mehr, dann läuft alles unter dem neuen Server. Das ist das Verhalten, wenn man kein neues Outlook Profil erstellt.
Jetzt ist nur noch die Frage, wenn beide Server noch aktiv sind, also der alte Exchange 2016 und der neue 2019, wie kann ich die Outlook Clients dazu bewegen, das diese sich nur noch mit dem neuen Server mit der neuen Domain (mapi.b-domain.de) verbinden? Ohne das ich das Outlook Profil neu erstellen muss. Sodass bei einer Abschaltung bzw. Deinstallation des alten Exchange 2016 keine Zertifikatsfehler mehr auftreten.
Nachtrag, grad gelesen:
Ich würde das so lösen, das ich den Exchange 2016 auf 2019 migriere, da wir eh nach 2019 hin möchten. Der alte Server behält die alte Domain und der neue Server bekommt die neue Domain.
bei dir ändert sich doch nur die SMTP Domain... daher bleib ich bei: Bau dir nen schönes SAN Zert mit allen relevanten Domains und allen relevanten Aliassen, dann klappt das auch. (Voraussetzung, interne CA, der die Clients alle vertrauen. Ansonsten eben mit SRV Records für autodiscover arbeiten und public Certs)
Hinweis, wenn sich die SMTP Domain dahingehend ändert, dass dies die neue prim. SMTP Domain für die User zum Versand ist, dann muss auch Autodiscover der neuen Domain intern auf den Exchange zeigen. Sprich, du brauchst alle DNS Eintrage im SAN Zert für beide Domains, damit sich die Clients nicht beschweren.
____________________________________________________________________________________________________________________________________________________________
so wie sich das liest, würde ich mir zuerst ein SAN Zert erstellen (interne CA?), was alle Namen inkl. diverser Standard Aliasse enthält.
Sprich
alter EX Server
neuer EX Server
alias für den Clientzugriff (bsp "exchange.domäne.tld")
Autodiscover
owa
webmail etc etc
!DNS Eintrag für Autodiscover muss zeitnah auf den neuen Server zeigen!
dieses Zert dann auf dem neuen Server installieren.
Hier auch bei der Zertzuweisung aufpassen, dass auch auf dem Backend das Zert zugewiesen wurde!
Daann die autodiscoverinternaluri umbiegen auf den Alias. + alle weiteren relevaten URL's
Dazu kannst du auch das Script von Frank super nehmen.
ggf musst du dann auf den Servern noch den AutodiscoverAppPool recyclen, bis es alle Clients merken.
Ab dann gehen die Clients gegen den neuen konfigurierten Wert. Der neue Server macht dann das "Proxying" für die Clientanfragen"
Funktioniert bei mir seit "Äonen von Jahren" :)
Gruß,
Ralf
Hi @bratak,
hat das SAN-Zertifikat dein Problem gelöst? Wenn keine internen CA's möglich sind, dann über eine echte Domain und mittels Lets-Encrypt erstellen.
Wie ging das bei dir aus oder ist das Thema noch offen bei dir?
lg Roman
Hallo Roman,
da noch ein anderes Thema dazwischen kam und auch durch Urlaub komme ich erst jetzt wieder zum Schreiben.
Die Idee von Ralf ist gut, ich glaube man kann es auch nur damit lösen, indem man ein Zertifikat hat, das beide Domains abdeckt.
In meinem Fall haben wir für die alte Domain ein Public Wildcard Zertifikat für die alte Domain und ein Public Wildcard Zertifikat für die neue Domain.
Ich habe das in meiner Testumgebung über Lets Encrypt realisiert und das hat dann funktioniert. Das Lets Encrypt Zertifikat dient praktisch nur als Übergangszertifikat, bis alle Clients die neue Domain verwenden. Danach kann man wieder das normale Zertifikat verwenden.