Hallo zusammen,
leider nutzen wir noch einen Exchange 2013, den wir nun endlich zu 2019 migrieren möchten. Ich hab alles auch schon in einer Testumgebung aufgebaut, jetzt ergeben sich aber ein paar Fragen.
Da am Exchange 2013 sehr viele Postfächer liegen, werden die beiden Exchange eine ganze Weile koexistieren müssen. Nun heisst es aber in Frankys Beitrag, dass man gleich als erstes die URLs vom EX13 auf den EX19 schreiben soll. Wenn ich das tue, dann haben die User, deren Postfächer auf den EX19 umgezogen wurden, keinen Zugriff mehr über Outlook auf das Postfach. Was auch Sinn ergibt, da Outlook das Postfach auf der URL vom alten EX13 sucht, es dort aber nicht findet. Oder übersehe ich bei Frankys Vorschlag irgendwas? Wie gesagt, beide Server müssen für Wochen parallel existieren, darum kann ich jetzt auch noch nicht mit DNS abändern arbeiten.
Weiter heisst es im Blogeintrag, man sollte das Zertifikat vom EX13 gleich auf den EX19 übernehmen. Warum? Da ist doch eine Zertifikatswarnung vorprogrammiert, weil das Zert. für den alten Hostnamen ausgestellt wurde. Vermutlich wird das dann auch per DNS gelöst, ist aber während der Migration noch nicht möglich.
Wahrscheinlich übersehe ich den entscheidenden Hinweis, ich wäre dankbar, wenn mir jemand in den Arsch tritt :-)
Danke!
Normalerweise sollten sich die beiden Exchanges "sehen" können, d.h. in der EAC von dem neuen EX2019 siehst du unter "Server" auch den EX2013. Der EX2019 trägt sich bei der Installation im AD entsprechend als "Ziel" für Outlook ein und fungiert anschließend als Client Access Proxy für die Postfächer, die noch auf dem alten Server liegen. Die Clients verbinden sich also mit dem neuen Server und der reicht die Anfragen wenn nötig an den alten weiter. Somit können die beiden auch problemlos länger koexistieren. Lediglich andere Clients müssen ggfls. angepasst werden bzw. wir hatten seinerzeit im DNS einen Alias, den haben wir auf den neuen Servernamen geändert, somit haben auch die Mobile Devices den korrekt gefunden. Das Management machst du ab dann aber nur noch über den neuen Server.
Was das Zertifikat angeht: Hier werden die URLs von den virtuellen Verzeichnissen angesteuert, sofern die also auf beiden gleich sind klappt das Ganze dann auch ohne Zertifikatwarnung im Outlook.
Ich habe das damals bei unserer Migration von Exchange 2013 zu 2019 auch nach Frankys Anleitung gemacht und wir hatten auch beide Server mehrere Wochen parallel laufen, bis alle Postfächer migriert waren. Ging relativ problemlos.
Hallo dartzen,
ja, die Server sehen sich, und sind auch beide über EAC verwaltbar. Allerdings ist es bei uns so, dass die User, deren Postfächer schon auf den EX19 umgezogen wurden, sich nicht mehr per Outlook verbinden können, wenn ich am EX19 die URLs des EX13 setze. Die "alten" User, deren Postfächer noch nicht migriert wurden, haben kein Problem. Dann scheint es ja so, als würde einer der Exchange bei uns nicht Proxy spielen. Kann ich das irgendwo prüfen?
Weiter heisst es im Blogeintrag, man sollte das Zertifikat vom EX13 gleich auf den EX19 übernehmen. Warum? Da ist doch eine Zertifikatswarnung vorprogrammiert, weil das Zert. für den alten Hostnamen ausgestellt wurde. Vermutlich wird das dann auch per DNS gelöst, ist aber während der Migration noch nicht möglich.
Weil man normalerweise keinen Hostnamen im Zertifikat stehen hat, sondern einen Alias wie bspw. mail.deinedomain.tld oder outlook.deinedomain.tld usw.
Stehen denn deine Exchange Server in der identischen Active Directory Umgebung? Falls ja, dann ist das kein Problem in Summe und man müßte als erstes für deine 2013er Umgebung erstmal die Zertifikate so gerade ziehen, dass eben bei der Migration keine Probleme auftauchen. ist alles kein Hexenwerk, aber sollte eben geplant und sauber konfiguriert werden. Es hilft, wenn man sich die Zeit nimmt, oder ggf. einen externen Dienstleister hinzuzieht, der sowas schon gemacht hat.
Grundsätzlich sollte afair aber auch der Zugriff von 2013 nach 2019 laufen (macht man nur nicht, weils andersrum praktischer ist).
Bye
Norbert
Hallo Norbert, ja, die Aliase sind natürlich vorhanden und das ist nun auch verstanden und sollte nicht das Problem sein.
Mein Problem ist wie gesagt die fehlende Konnektivität von Outlook, sobald die URLs umgezogen werden.
Verhalten aktuell:
EX19 hat urls ex19.domaene.de eingetragen--> sowohl Postfächer von EX13 als auch EX19 können sich verbinden
EX19 hat urls ex13.domaene.de eingetragen --> die Postfächer vom EX19 können sich nicht mehr per Outlook verbinden, die EX-13-Postfächer haben nach wie vor kein Problem.
Und es wurmt mich, dass ich den Fehler nicht finde, weil es vermutlich nur eine Kleinigkeit ist. Zeit nehme ich mir, darum bin ich ja in der Testumgebung :-)
Hab nochmal getestet: sobald ich am ex19 die MAPI-URL des ex13 eintrage, kann Outlook keine Verbindung mehr herstellen. Betrifft nur Postfächer, die schon am ex19 liegen.
Der ex19 kann keine Verbindung zu mapi am ex13 herstellen? Hat dazu jemand noch einen Tipp für mich, was ich prüfen könnte?
Ich versteh dein Problem nicht. Du hast Alias Namen und der sollte natürlich bei allen Servern einer Site im Normalfall identisch sein. Sprich bei Exchange 2013 und 2019 steht in internal/external URL immer das gleiche drin. Wenn du dann den Zugriff per DNS auf den 2019 schickst, sollten alle Clients ganz normal weiterarbeiten können, egal ob sich ihr Postfach auf 2019 oder 2013 befindet. Das kann man dann ja mittels hosts Datei auf ein paar Clients mal testen. Auf welchem OS läuft der 2013? Ist da TLS 1.2 aktiv? (Wobei es TLS 1.2 nicht sein kann, weil du ja sagst, dass der Zugriff funktioniert, wenn du ex19.domain.tld einträgst und dann sowohl Postfächer 2013 als auch 2019 aufgerufen werden können.)
Ich versteh dein Problem nicht. Du hast Alias Namen und der sollte natürlich bei allen Servern einer Site im Normalfall identisch sein. Sprich bei Exchange 2013 und 2019 steht in internal/external URL immer das gleiche drin. Wenn du dann den Zugriff per DNS auf den 2019 schickst, sollten alle Clients ganz normal weiterarbeiten können, egal ob sich ihr Postfach auf 2019 oder 2013 befindet.
Hallo Norbert, normalerweise sollte das so sein, bei uns leider nicht :-)
Sobald ich am ex19 die mapi-url vom ex13 eintrage, klappt der Outlook-Aufruf nicht mehr, für Postfächer am ex19. Selbst wenn ich den Client per Hosts-Datei auf den ex19 zwinge, kann keine Verbindung aufgebaut werden.
Der 2013er läuft auf einem 2012R2. TLS 1.2 ist enabled. Wenn der ex19 sich selbst bei der mapi-url eingetragen hat, dann funktioniert der Zugriff für alle Postfächer. Am ex13 habe ich bei den URLs nichts geändert.
Schwer zu sagen im Forum. Ohne genauere Infos und evtl. Eventlog-Meldungen wirds schwierig.
Ich stell gerne alle Infos bereit, bin nur grad ratlos, wo man ansetzen kann. Was ich gerade noch getestet habe: User, dessen Postfach auf den ex19 verschoben wurde, kann sich auch nicht mehr an der owa des ex13 anmelden. Nach Eingabe der Anmeldedaten passiert gar nichts. Was dann auch Sinn (oder auch nicht) ergibt, dass der selbe User keine Verbindung per Outlook aufbauen kann. Das würde ja bedeuten, dass der ex13 die Anfragen nicht zum neuen ex19 weiterreicht, was er doch eigentlich tun sollte.
Klappt das denn andersherum? Also verbinden mit dem Exchange 2019, wenn das Postfach auf dem 2013er liegt? Immer natürlich unter der Voraussetzung, dass die virtuellen Verzeichnisse gleich heißen und die Einträge auf den 2019er zeigen. Weil das ging damals bei uns definitiv, andersherum habe ich das nie getestet, ob das geht bzw. gehen soll.
Was mir noch einfällt: Mal am 2019er testweise die Extended Protection deaktiviert? Die wird ja mit CU14 standardmäßig eingeschaltet und wenn das am 2013er aus ist (weiß nicht mehr, ob der das noch bekommen hatte und wenn ja mit welchem CU, musste man aber immer manuell einschalten) kann das eventuell auch zu Problemen führen.
Hallelujah! Vielen Vielen Dank für die vielen Tipps, und Herzlichen Dank an dich, dartzen! Die Extended Protection war das Problem. Disabled, und schon läuft es so, wie es soll. Oh Mann, das hat mich viele Stunden Fehlersuche gekostet. Zum Glück nur in der Testumgebung. Danke nochmal...
Ich würd sie ja eher am 2013 aktivieren. ;) Sonst vergißt du das am Ende in der Produktivumgebung am 2019er.
Stimmt, aber vorher muss ich die Public Folder vom ex13 wegmigrieren :-) sonst lauf ich ins nächste Problem
Stimmt, aber das is ja auch nur ne Mailbox die man verschieben kann (oder mehrere ;))
So, 6 Wochen später sind endlich alle Postfächer migriert, DNS-Einträge etc. umgestellt, jetzt würd ich gern aufräumen, d.h. den alten EX13 deinstallieren.
Was mich noch ein wenig zaudern lässt: ich habe alle DNS-Einträge umgebogen, und auch für den EX13 einen Alias erstellt, damit er auf den neuen EX19 zeigt. Sprich ein Ping auf den EX13 landet auf dem EX19. Soll ja auch so sein. Aber: die Deinstallationsroutine vom EX13 frägt ja auch im AD nach, und entfernt dann den alten Server aus den Gruppen. Ich hoffe doch, dass dies über die ObjectGUID passiert, und nicht einfach über den DNS? Denn sonst hätte ich ein Problem, und der Deinstaller entfernt mir meinen EX19 :-)
Den CNAME kannst du doch einfach löschen. Mit dem Ex13 sollte kein normaler User oder sonstiges zu tun haben und wenn, ist es besser den Fehler auf der Seite des Clients zu beheben als so eine DNS Krücke beizubehalten.
Den Cname brauch ich, weil ich am neuen Ex die URLs vom alten Ex übernommen habe. D.h. ja, meine Clients hätten ein Problem, wenn der Cname weg wäre. Oder hab ich einen Denkfehler?
Ja hast du. Man definiert nicht den Hostname als zugriffspunkt, weil man genau das Problem dann hat, welches du jetzt versuchst zu umschiffen. Und außerdem kann man das jederzeit ändern, denn genau dafür ist ja autodiscover da. Ich würde empfehlen das zu ändern. Neuer Name (generisch sowas wie Outlook.deinedomain.tld) und dann wird das auch sauber machbar. Das was du da versuchst ist nur Pfusch. ;)
Normalerweise arbeitet man hier mit einem separaten Alias im DNS, den man dann nach belieben auf den passenden Server schwenkt. Dieser Alias wird dann auch für die URLs im Exchange und in dem Zertifikat verwendet. Die Clients kennen dann nur diesen Alias und nicht mehr den eigentlichen Servernamen. Dann gibt's bei Migrationen in der Regel keine Probleme mit den Clients.
Edit: Norbert war schneller.