Migration vom Exchange Server 2016 nach Office365
Liebe ITlerInnen,
wir würden gerne unsere Postfächer/Kalender/Kontakte/Notizen... vom Exchange 2016 ins Office365 migrieren.
Mit Protokollübersicht und Status.
Es soll Daten synchronisieren und beim Produktiv Umschalten nur mehr die Deltas übertragen.
Damit die Umstellung an einem Wochenende passieren kann.
Der Plan ist, das man nicht vom Exchange Server .pst File exportiert und dann im Office365 importiert.
Grund 1: Es gibt keine richtige Protokollierung
Grund 2: Die Übertragung ist nicht Transparent
Grund 3: Die Downtime wäre zu lange
Es gibt über 140 Postfächer die Übertragen gehört und viele Freigegebene Postfächer ..
Die Exchange Datenbank ist knapp 1,5TB groß.
Ich habe mir die Software CodeTwo angesehen.
Wirkt sehr gut, aber bei näherer Information vom Support sind folgende Dinge aufgefallen:
- es werden keine Berechtigungen übertragen
- Sprache und Zeitzone wird nicht übertragen
Das wäre noch verkraftbar, aber wenn man denn Job mal gestartet hat,
gibt es einen Rescan um die Deltas zu übertragen.
Damit man 1 Woche vorher alles überträgt und kurz vorm Umstellen die Deltas überträgt.
ABER:
Daten die während Erst Scan und Rescan gelöscht werden oder geändert,
werden nicht übertragen (Laut Support)
Und das ist schon ein großes Problem.
Kennt Ihr andere Produkte, die Änderungen synchronisieren können ?
Wie habt Ihr vom Exchange ins Office365 übertragen ?
LG K
wir würden gerne unsere Postfächer/Kalender/Kontakte/Notizen... vom Exchange 2016 ins Office365 migrieren.
Mit Protokollübersicht und Status.
Es soll Daten synchronisieren und beim Produktiv Umschalten nur mehr die Deltas übertragen.
Damit die Umstellung an einem Wochenende passieren kann.
Der Plan ist, das man nicht vom Exchange Server .pst File exportiert und dann im Office365 importiert.
Grund 1: Es gibt keine richtige Protokollierung
Grund 2: Die Übertragung ist nicht Transparent
Grund 3: Die Downtime wäre zu lange
Es gibt über 140 Postfächer die Übertragen gehört und viele Freigegebene Postfächer ..
Die Exchange Datenbank ist knapp 1,5TB groß.
Ich habe mir die Software CodeTwo angesehen.
Wirkt sehr gut, aber bei näherer Information vom Support sind folgende Dinge aufgefallen:
- es werden keine Berechtigungen übertragen
- Sprache und Zeitzone wird nicht übertragen
Das wäre noch verkraftbar, aber wenn man denn Job mal gestartet hat,
gibt es einen Rescan um die Deltas zu übertragen.
Damit man 1 Woche vorher alles überträgt und kurz vorm Umstellen die Deltas überträgt.
ABER:
Daten die während Erst Scan und Rescan gelöscht werden oder geändert,
werden nicht übertragen (Laut Support)
Und das ist schon ein großes Problem.
Kennt Ihr andere Produkte, die Änderungen synchronisieren können ?
Wie habt Ihr vom Exchange ins Office365 übertragen ?
LG K
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 556173
Url: https://administrator.de/forum/migration-vom-exchange-server-2016-nach-office365-556173.html
Ausgedruckt am: 22.12.2024 um 21:12 Uhr
12 Kommentare
Neuester Kommentar
Warum willst du denn mit Deltas arbeiten?
Vielleicht kannst du ja die Migration anders "designen"?
um wie viele Postfächer handelt es sich denn?
Edit: Vergiss die letzte Frage habs gesehen.
Bei 140 Postfächern ist das schon einiges Holz. Aber vielleicht lohnt sich das Vorgehen ja für dich.
Ich hab das früher als ich noch Kunden migrierte wie folgt gemacht:
1. TLD bei Microsoft registriert, MX aber noch nicht umgeschaltet.
2. Postfächer am hostedExchange angelegt mit der onMicrosoft-Adresse als Alias angelegt.
3. Weiterleitung beim Hoster der jeweiligen Mails auf die entsprechende onmicrosoft-Adresse.
Dadurch können die User im Endeffekt mit der neuen Mailadresse arbeiten und Mails ab Zeitpunkt X werden über die Umleitung auf den neuen Exchange zugestellt.
Dann vom lokalen Exchange die Migration mit CodeTwo durchgeführt. So musste man nur einmal migrieren und das "Delta" war schon am Zielserver.
Waren in der Regel aber auch immer nur Kleinstmigrationen bis ca. 20 User.
Ahja und wenn eine Archivierungssoftware vorhanden ist, vorher vielleicht mal die Postfächer etwas ausdünnen.
und wichtig. Bei CodeTwo ist glaub ich ein Öffentlicher Ordner wie 10 Einzelpostfächer von der Lizenz her.
Vielleicht kannst du ja die Migration anders "designen"?
um wie viele Postfächer handelt es sich denn?
Edit: Vergiss die letzte Frage habs gesehen.
Bei 140 Postfächern ist das schon einiges Holz. Aber vielleicht lohnt sich das Vorgehen ja für dich.
Ich hab das früher als ich noch Kunden migrierte wie folgt gemacht:
1. TLD bei Microsoft registriert, MX aber noch nicht umgeschaltet.
2. Postfächer am hostedExchange angelegt mit der onMicrosoft-Adresse als Alias angelegt.
3. Weiterleitung beim Hoster der jeweiligen Mails auf die entsprechende onmicrosoft-Adresse.
Dadurch können die User im Endeffekt mit der neuen Mailadresse arbeiten und Mails ab Zeitpunkt X werden über die Umleitung auf den neuen Exchange zugestellt.
Dann vom lokalen Exchange die Migration mit CodeTwo durchgeführt. So musste man nur einmal migrieren und das "Delta" war schon am Zielserver.
Waren in der Regel aber auch immer nur Kleinstmigrationen bis ca. 20 User.
Ahja und wenn eine Archivierungssoftware vorhanden ist, vorher vielleicht mal die Postfächer etwas ausdünnen.
und wichtig. Bei CodeTwo ist glaub ich ein Öffentlicher Ordner wie 10 Einzelpostfächer von der Lizenz her.
Ich würde halt umstellen. Den Usern sagen die nächsten 5 bis 6 Tage bekommt ihr nur neue Mails, die alten kommen in den nächsten Tagen nach.
Vielleicht schaffen es ja einige User auch den Kalender für 5 Tage im voraus mal analog old school in Schriftform zu führen...
Klar hat auch seine Nachteile aber das Delta wärst du so los. Sobald umgestellt ist (mailweiterleitung) gibts nur noch hostedExchange für User.
Soviel zu meinem Vorschlag.
Aber gerade 2016/2019 Exchange kannst du doch auch in Hybrider Konstellation betreiben. D.h. hostedExchange und onpremise parallel und Postfächer dazwischen hin und her schieben. Somit könntest du ja auch Postfach für Postfach migrieren und den onpremise dann abschalten.
Vielleicht schaffen es ja einige User auch den Kalender für 5 Tage im voraus mal analog old school in Schriftform zu führen...
Klar hat auch seine Nachteile aber das Delta wärst du so los. Sobald umgestellt ist (mailweiterleitung) gibts nur noch hostedExchange für User.
Soviel zu meinem Vorschlag.
Aber gerade 2016/2019 Exchange kannst du doch auch in Hybrider Konstellation betreiben. D.h. hostedExchange und onpremise parallel und Postfächer dazwischen hin und her schieben. Somit könntest du ja auch Postfach für Postfach migrieren und den onpremise dann abschalten.
Prost Mahlzeit ...
Hybrid ist das einzige was wirklich Sinn machen würde, und das wurde abgelehnt?
Wenn Hybrid abgelehnt wird, lass es sein ....
Durch eine Exchange zu Exchange Migration, sind die Postfächer jederzeit nutzbar, auch während einer Migration, da die Postfächer durch den Hybrid einfach synchron gehalten werden.
Auch werden die Berechtigungen transferiert, sowie die Spracheinstellungen.
Alles andere ist in meinen Augen unnötige Bastelrei
Nutz ihr eigentlich auch einen Azure AD Sync?
AvePoint Fly verwende ich für Fileserver zu SharePoint, als auch SharePoint zu SharePoint Migrationen.
Funktioniert gut.
Beachte, dass wenn das Konto was migriert MFA-aktiv hat, dass du ein App-PW erstellen musst, da AvePoint kein MFA beherscht.
Und außerdem ist ein weiterer beliebter Fallstrick: Wenn du im Connection Manager irgendwas an den Settings ändert, kannst du alle Jobs, welche du vor der Änderung erstellt hast, nicht nochmal z.B. inkrementell laufen lassen.
Die Jobs ziehen sich zum Zeitpunkt der Erstellung die Config. aus dem Connection Manager, fragen diese aber danach nie wieder ab.
Funktioniert gut.
Beachte, dass wenn das Konto was migriert MFA-aktiv hat, dass du ein App-PW erstellen musst, da AvePoint kein MFA beherscht.
Und außerdem ist ein weiterer beliebter Fallstrick: Wenn du im Connection Manager irgendwas an den Settings ändert, kannst du alle Jobs, welche du vor der Änderung erstellt hast, nicht nochmal z.B. inkrementell laufen lassen.
Die Jobs ziehen sich zum Zeitpunkt der Erstellung die Config. aus dem Connection Manager, fragen diese aber danach nie wieder ab.