Migration Exchange 2010 > 2016

[stevenki 1]

Hallo zusammen,

 

eins vorab, es ist meine erste Exchange Migration und ja ich weiß, dass das hätte schon lange passieren müssen, aber leider ist die Personaldecke eben sehr sehr dünn.

Ich habe unsere Umgebung auf einem Testserver wiederhergestellt um dort entsprechend mit der Liveumgebung bauen zu können.

 

Unsere Liveumgebung besteht aus mehreren Standorten, 15 DCs und 1 Exchange.

Der Exchange hat eine DB Größe von ca. 3 TB (aufgeteilt auf 5 DBs) und ca. 2000 Postfächer und ca. 20 Domains.

(Ja ich weiß, 1 Exchange ist deutlich zu wenig für eine gewisse Verfügbarkeit, allerdings auch hier siehe mein Eingangstext  )

 

Ich hab den DC, der am selben Standort wie der Exchange steht und Inhaber sämtlicher Rollen ist im Testsystem wiederhergestellt, sämtliche anderen DCs sauber entfernt (NTDSUTIL,...), Standorte gelöscht usw.

Desweiteren habe ich den Exchange wiederhergestellt und mir noch 2 Clients Windows 10 mit Office 2016 installiert.

 

Dann habe ich in der Testumgebung einen weiteren Server installiert (Server 2016) und den Exchange (aktuellster Patchstand) installiert und mich in soweit an dieser Anleitung orientiert:

https://www.frankysweb.de/migration-von-exchange-2010-zu-exchange-2016-teil-1/

 

Leider habe ich jedoch ein großes Problem mit der Outlook Konnektivität.

Wenn ich den DNS auf den alten Exchange zeigen lasse, kann ich Outlook mit Benutzern nutzen, dessen Postfächer noch auf dem alten Exchange liegen.

Ändere ich den DNS auf den neuen Exchange, funktioniert dies jedoch nicht mehr. Beim Start erhalte ich dann nur die Fehlermeldung, das die OST Datei beschädigt ist und die Ordnergruppe nicht erweitert werden kann (an der OST kann es nicht liegen, das betrifft auch neue Profile).

Andersrum ist es genauso. Lasse ich den DNS Eintrag auf den alten Exchange zeigen, bekomme ich die gleiche Meldung von Benutzern, deren Postfächer schon auf den neuen Server migriert wurden.

Ändere ich die DNS Einträge auf den neuen Exchange, funktionieren eben diese Postfächer.

 

Ich kann also immer nur die Postfächer nutzen, die auf dem Exchange Server liegen, auf den der DNS auch zeigt.

(ich rede hier natürlich von autodiscover Einträgen und und den entsprechend konfigurierten URLs, in unseren Fall mail.domain.tld)

Konfiguriert ist Split DNS.

 

Ansonsten was funktioniert:

Zeigt der DNS auf den neuen Exchange, kann ich über die URL auf das OWA zugreifen. Hier funktioniert beides, ein Postfach, welches auf dem neuen Exchange liegt, wird mir nach Anmeldung im neuen OWA angezeigt. Ein Postfach, welches auf dem alten Exchange liegt, wird mir nach erfolgreicher Anmeldung im alten OWA angezeigt.

Auch der Mailfluss funktioniert auf beiden Exchange Servern ein- sowie ausgehend und auch zwischen Postfächern untereinander. (habe eine zusätzliche Domain auf dem Testsystem konfiguriert, welche im Echtsystem nicht existiert - daher kann ich auch Ein- und Ausgehend Extern Testen)

 

Vielleicht könnt ihr mir ein Denkanstoss geben, wie ich das Problem lösen könnte.

Sollten noch Infos fehlen, liefere ich die natürlich gerne nach.

 

Vielen Dank an euch

[NilsK 2.789]

Moin,

 

ich kann nicht recht nachvollziehen, was du da eigentlich machst. Es klingt allerdings nicht zielführend. 

 

Wenn ihr so wenig Personal habt und keine Erfahrung mit Exchange-Migrationen, warum macht ihr das dann selbst ohne externe Unterstützung? Und warum fängst du dann damit an, eure sehr komplexe Umgebung nachzubauen - in einer Form, die dann gar nicht mehr aussagekräftig ist?

 

Das Risiko, vor dem euer Unternehmen steht, ist enorm. Ich würde das an deiner Stelle nicht selbst und schon gar nicht allein machen. Das "gesparte" Geld wiegt die möglichen Schäden nicht auf.

 

Gruß, Nils

 

[NorbertFe 1.810]

Kann ich Nils nur zustimmen. Ich würde mir jemanden holen, der sowas regelmässig durchführt und der auch entsprechend viele größere und kleinere Stolpersteine kennt und weiß wie er damit umzugehen hat. Dein Ansatz das jetzt im Alleingang mit einer wenig aussagekräftigen Testumgebung nachzuspielen, ist zwar grundsätzlich in Ordnung, es hilft dir aber nix wenn Probleme in der Produktionsumgebung auftreten und wenn schon im Test jetzt Probleme auftreten, mit denen du nicht umgehen kannst, wirds ja nicht leichter.

 

In der Zeit die du in der Testumgebung verbringst, könnte vermutlich jemand mit mehr Erfahrung die MIgration einfach produktiv durchführen.

 

Viel Erfolg.

Norbert

[stevenki 1]

Hallo,

 

vielen Dank erstmal für eure Antworten.

Leider kann ich die Kritik teilweise nicht ganz verstehen - warum eine Umgebung nachbauen, die nicht aussagekräftig ist? Es ist doch ein 1:1 Abbild der original Umgebung, wenn diese Testumgebung nicht aussagekräftig ist, welche dann?

 

Warum wir das selber machen steht leider in der Form nicht zur Diskussion, auch wenn ich eure Argumente verstehe. Aber das entscheide ja nicht ich.

Und an sich finde ich unsere Exchange Umgebung ja auch nicht wirklich komplex, es ist keine DAG vorhanden oder die Rollen auf unterschiedlichen Servern verteilt sondern ein Single-Server. Und es ist auch nicht so , dass ich Exchange vorher noch nie gesehen habe, es ist halt meine erste Migration, die ihr ja auch irgendwann mal als erstes gemacht habt.

 

Könnt ihr mir den Tips geben, wo ich ansätzen könnte? 

Die DNS Einträge (Split-DNS) sehen folgend aus:

autodiscover.domain1.de -> interne IP Exchange 2010

autodiscover.domain2.de -> interne IP Exchange 2010

autodiscover.domain3.de -> interne IP Exchange 2010

usw.

mail.hauptdomain.de -> sämtliche URLs auf dem Exchange 2010 sowie auf dem 2016. -> zeigt auf den 2010er.

Je nachdem, wo ich diese Einträge hinlenke, dieser Exchange funktioniert dann in Bezug auf Outlook Konnektivität ... 

Die Proxyfunktion fürs OWA funktioniert wiederrum ohne Probleme wenn die DNS Einträge auf den 2016er zeigen und ich mich im "neuen" OWA anmelde

 

 

[testperson 1.539]

Hi,

 

ein Schuss ins Blaue: Ambiguous URLs and their effect on Exchange 2010 to Exchange 2013 Migrations - Microsoft Community Hub (weitere Infos dazu: Demystifying the CAS Array Object - Part 1 - Microsoft Community Hub / Demystifying the CAS Array Object - Part 2 - Microsoft Community Hub)

 

Alles andere ist ja gesagt und da schließe ich mich an.

 

Gruß

Jan

[NilsK 2.789]

Moin,

 

vor 4 Stunden schrieb stevenki:

warum eine Umgebung nachbauen, die nicht aussagekräftig ist? Es ist doch ein 1:1 Abbild der original Umgebung

 

nun ...

 

vor 5 Stunden schrieb stevenki:

Ich hab den DC, der am selben Standort wie der Exchange steht und Inhaber sämtlicher Rollen ist im Testsystem wiederhergestellt, sämtliche anderen DCs sauber entfernt (NTDSUTIL,...), Standorte gelöscht usw.

 

Das ergibt evtl. eine Umgebung, die ähnlich ist, aber 1:1 ist das ganz sicher nicht. Ob du beispielsweise die DNS-Probleme "in echt" auch hättest - oder ganz andere ... das kann niemand einschätzen. Also wäre zu fragen, warum du das überhaupt machst. Das grundlegende Verfahren als solches ist ja bekannt und dokumentiert. Um das einfach zu üben, musst du kein Backup der Realumgebung im Labor wiederherstellen (was ich, nebenbei gesagt, auch aus anderen Gründen selten für eine gute Idee halte). Das kannst du viel einfacher haben und weißt dann, wie es funktionieren sollte. Nicht ganz unwichtiges Wissen.

 

Stattdessen schlägst du dich mit Problemen rum, die du nicht einschätzen kannst. Was könnten also die Ziele des Aufwands sein?

 

vor 4 Stunden schrieb stevenki:

Warum wir das selber machen steht leider in der Form nicht zur Diskussion

Weil die Arbeitszeit, die du für deine Versuche aufbringst, nichts kostet? Weil du das in deiner Magic Time machst, also deiner Firma die Arbeit schenkst? Weil man das Risiko liebt?

 

vor 4 Stunden schrieb stevenki:

Aber das entscheide ja nicht ich.

Kann sein, aber du kannst dich sicher dazu äußern, ob du die Verantwortung übernehmen willst, wenn es mangels Erfahrung eben nicht klappt. 2000 User sind keine kleine Umgebung. Und nur weil ihr bislang fahrlässigerweise nur mit einem Einzelserver arbeitet, ist die Umgebung noch lange nicht unkomplex.

 

Es geht nicht darum, dich bloßzustellen. Niemand kann von einem Admin erwarten, dass er sich einfach so mit einer großen Exchange-Migration auskennt. Es geht darum, dir einen sinnvollen Weg aufzuzeigen. Das gehört für die meisten hier zur Professionalität dazu.

 

Gruß, Nils