Hallo zusammen,
folgende Umgebung:
Domäne: org.local
Exchange 2010 -> EX01, hostet aktuell noch die Public Folder die parallel in eine andere Archivlösung übertragen werden.
Exchange 2016 -> EX02, beherbergt alle User Mailboxen etc. VirtualDirectories sind nicht einheitlich und vollständig konfiguriert, kein SplitDNS.
Exchange 2016 -> EX03, neu aufgesetzt (CU22 + latest KB). Ziel ist es, diesen als lokalen Exchange für eine Hybrid Umgebung zu verwenden.
Problembeschreibung:
EX03 installiert, frisch angelegten SCP danach direkt geändert um auf EX02 zeigen zu lassen damit kein Client sofort gegen den neu installierten Exchange 2016 spricht.
DB und Logs auf die richtigen Laufwerke verschoben
Pfade im EX03 konfiguriert
-> owa.domäne.de
-> autodiscover.domäne.de
autodiscover.domäne.de zeigt intern noch auf EX02.
owa.domäne.de existiert intern nicht.
Danach poppten in manchen Outlook Clients schon Zertifikatswarnungen hoch.
Client bezog seinen Exchange via SCP und zeigte auch den Eintrag an, dass er autodiscover von EX02 beziehen will.
Workaround hier war nun ein schnelles einpflegen eines selbst erstellten Zertifikats, dass alle *.domänen der Umgebung abdeckt.
Plan ist aber in Zukunft alles über
-> owa.domäne.de
-> autodiscover.domäne.de
laufen zu lassen.
Meine Frage: wieso versuchen die Clients mit dem neuen Exchange zu kommunizieren? Wieso teilt der "alte" EX02 den Clients (offenbar) direkt mit, dass diese den EX03 kontaktieren sollen?
Selbe Situation würde mir in jedem Unternehmen unterkommen, welche nach Zeit X feststellt, dass eine DAG benötigt wird.
Wie sollte man hier am besten vorgehen? Bei einer Migration zu einer neuen Exchange Version (2010 auf 2016, oder 2016 auf 2019) ist mir dieses Verhalten so noch nicht untergekommen.
Leider sind vor allem die VirtualDirectories und das SplitDNS auch heute noch nicht bei allen Umgebungen auf dem Stand, wie man es für Hybrid Exchange benötigt.
Vorab schon mal vielen Dank fürs drüber Nachdenken :)
wieso versuchen die Clients mit dem neuen Exchange zu kommunizieren?
Weil der SCP im AD steht und du ihn nicht korrigiert hast. ;)
Wieso teilt der "alte" EX02 den Clients (offenbar) direkt mit, dass diese den EX03 kontaktieren sollen?
Tut er nicht. Die Clients fragen die verfügbaren SCPs ab und da steht halt der neue Server drin. Paßt du den an auf den alten Wert (mittels set-clientaccessservice) wird der alte Wert von beiden geliefert.
Bei einer Migration zu einer neuen Exchange Version (2010 auf 2016, oder 2016 auf 2019) ist mir dieses Verhalten so noch nicht untergekommen.
Doch. Das passiert bei jeder Exchangemigration, da immer beim Setup der neue SCP ins AD geschrieben wird. Je nach Größe der Umgebung tritt der FEhler eben mehr oder weniger heftig auf.
Leider sind vor allem die VirtualDirectories und das SplitDNS auch heute noch nicht bei allen Umgebungen auf dem Stand, wie man es für Hybrid Exchange benötigt.
Das könnte man ja bevor man anfängt kontrollieren und ggf. korrigieren. ;)
Hi Norbert,
leider hatte ich den SCP direkt noch während dem vorletzten Installationschritt angepasst.
EX03 installiert, frisch angelegten SCP danach direkt geändert um auf EX02 zeigen zu lassen damit kein Client sofort gegen den neu installierten Exchange 2016 spricht.
Grüße
Manuel
leider
Wieso leider? Das wäre doch korrekt. Und wo ist jetzt das Problem?
@norbertfe weil dadurch deine Erklärung "SCP" nicht zutrifft.
Ich kenne Reihenfolgen im Autodiscover beim Outlook Client und wie der Client an seine Infos kommt ganz gut.
SCP zeigte definitiv auf EX02.
Wir haben nun Nägel mit Köpfen gemacht und alles auf
-> owa.domäne.de -> EX03
-> autodiscover.domäne.de -> EX03
umgestellt, auch auf dem EX02.
Nun scheint wieder Ruhe einzukehren.
Die Frage die sich mir aber weiterhin stellt ist, wieso der EX02 Adressen an die Clients weitergab, die nur auf dem EX03 konfiguriert waren (welche dann auf den EX03 zeigen).
Da kommt ggf. aber noch das Caching am Client und am Server/IIS dazu. Aber wenns jetzt wieder ruhig ist, dann ist ja alles gut. ;) Deine letzte Frage (ohne Fragezeichen), beantwortet das Caching dann ggf. ebenfalls.
ich würde immer das fertige Zertifikat auf dem neuen Server installieren, bevor ich anfange, Exchange zu installieren. Per Autodiscover bekommen die Clients sehr schnell mit, dass es einen neuen Exchange Server in der Org gibt und fragen den auch an. Wenn das neue Zert dann alle relevanten Namen (alter und neuer Server + alle Aliase) enthält, passiert nix.
Zur Sicherheit müsste man dann ggf. noch die Autodiscover Pools recyclen, wenn man mit der Config der virt. Verzeichnise fertig ist.
Restart-WebAppPool MSExchangeAutodiscoverAppPool Restart-WebAppPool MSExchangeRpcProxyFrontEndAppPool Restart-WebAppPool MSExchangeRpcProxyAppPool
Gruß,
Ralf