3rd Party Migration mit Fly

Es gibt immer wieder Fälle, in denen eine Migration mit Exchange Bordmitteln nicht möglich ist. Ich nutze ein reales Projekt um einmal verkürzt meine Überlegungen und Abwägungen zu beschreiben.

Wichtig: Die ist keine vollumfängliche Beschreibung meiner Abwägungen und erst recht kein Vergleich der genannten Produkte. Die Seite soll aber Denkanstöße gebe, wenn Sie vor einer ähnlichen Fragestellung stehen. Es ist nun mal nicht alles einfach zu beantworten.

Demo-Umgebung

Wir gehen einfach mal davon aus, dass eine Firma A  eine Tochter-Firma B und C in ihren Exchange Online Tenant integrieren will. Das ist eine gar nicht so seltene Herausforderungen, da es immer Firmen gibt, die historisch relativ eigenständige Landesgesellschaften haben oder andere Firmen zugekauft haben. Um es aber nicht allzu einfach zu machen, habe ich ein paar Fallstricke eingebaut:

• Firma A nutzt Microsoft 356 mit lokalen AD und ADSync
  Exchange ist schon komplett in der Cloud und lokal kann man mit de Exchange Management Shell die Empfänger verwalten
• Firma B hat ca. 100 Postfächer bei einem anderen Exchange Hoster
  Ein Zugriff per Impersonation oder FullAccess ist für eine Migration möglich.
• Es gibt keine WAN-Verbindung zwischen Firma A und B
  Der ADSync von Firma A kann also nicht auf das AD mit den Benutzern von Firma B zugreifen
  Daher sind die Benutzer aus Firma B schon als CloudOnly-User im Tenant von Firma A vorhanden, damit Sie mit Teams zusammenarbeiten können
• Firma C hat ein paar Postfächer bei einem IMAP4-Provider
  Auch die Anwender von Firma C sind schon "CloudOnly"-Benutzer im Tenant von Firma A

Als Zielumgebung gibt es nur noch Exchange Online im Office 365 Tenant. Die Benutzer lassen wir unverändert. Sie können die Migration also darauf reduzieren, dass wir eigentlich nur die Postfachinhalte und SMTP-Domains (MX-Record) umziehen müssen. Die bisherigen Domains von Firma B und Firma C sind noch nicht irgendwie in Office 365 in Verwendung.

Wenn Sie etwas knobeln wollen, dann skizzieren sie jetzt einmal, wie sie mit ihrem aktuellen Wissen diese Anforderungen angehen wollen, ehe ich meine Überlegungen beschreibe.

Bordmittel gehen nicht

Das Ziel ist Exchange Online und Microsoft bietet diverse Bordmittel zur Migration an. Gehen wir diese doch einmal durch:

• Cutover
  Kann generell nicht genutzt, werden, da das Ziel schon ADSync nutzt und damit die Funktion von Microsoft blockiert ist. (Siehe Cutover und ADSync)
• Staging
  Kann für Firma B nicht genutzt werden, da die Quelle neuer als Exchange 2007 ist.
• Remote Move mit Hybrid
  Zum einen kommt ADSync nicht an den Forest von Firma B und zum zweiten hat der Hoster die MRS-Proxy-Funktion aus verständlichen Gründen nicht erlaubt. Impersonation oder Full-Access reichen nicht für einen RemoteMoveRequest (Siehe auch Remote Move Request - Kurzfassung und RemoteMoveRequest ohne Hybrid)
• IMAP4-Migration
  Das wäre tatsächlich ein Weg aber der Verzicht auf Termine, Kontakte, Aufgaben etc. wiegt zu schwer, wenn die Quelle ein Exchange System ist. Es ist aber eine legitime Option für Quelle, die eh nur IMAP4 nutzen. (Siehe IMAP4 Migration mit Exchange Online)
• PST-Migration
  Wollen Sie wirklich für jeden Benutzer die Mails per PST Export und PST Import übertragen. Wenn die Quelle keinen PST-Export anbietet, dann ist der Weg eh verbaut
• Outlook-Migration
  Theoretisch könnten Sie ihre Anwender bitte, mit Outlook und zwei Verbindungen zu beiden Exchange Umgebungen die Elemente von Hand zu verschieben. Den Weg würde ich aber auch verwerfen.

Also bleibt nur die Suche nach einer 3rd Party Lösung, die Mails aus der Quelle per EWS mit Impersonation bzw. Full-Access ausliest und in das Ziel importiert.

Migrationsplanung

Dazu müssen natürlich ein paar Vorarbeiten erfolgen. Das kann die ein oder andere 3rd Party Software vielleicht schon alleine oder Sie führen die Vorarbeiten manuell aus. Ich bin fast eher ein Freud das selbst zu machen und nicht auf eine "Magie" einer Software zu vertrauen, die dazu auch viele Rechte braucht

• Domain registrieren
  In meinem Fall sind die Domain noch nicht in einem anderen Tenant aktiv und können problemlos auf den Zieltenant eingetragen werden. Damit wird auch verhindert, dass mitten in den Arbeiten die Domain plötzlich noch in einem anderen Tenant erscheint. Ich darf zwar den SPF/DKIM-Record erweitern aber noch nicht den MX-Record umtragen.
• User anlegen
  Sofern noch nicht erfolgt, lege ich nun jeden Empfänger der Quelle im Ziel schon mit an. Das sind nicht nur Benutzer sondern auch Gruppen. Später sollen ja die Personen aus Firma B und C im Tenant der Firma A arbeiten und brauchen ihre Verteiler und Kontakte
• Postfach mit Umleitung aktivieren
  Damit eine Software die Inhalte in den Tenant übertragen kann, müssen die Postfächer im Ziel samt Lizenz vorhanden sein. Sobald ich aber Postfächer anlege, landen zumindest Mails vom Absender des Tenants in diesen Postfächern. Daher ist es wichtig, dass ich möglichst zeitgleich auch eine "RemoteRoutingAddress" im Postfach eintrage, damit Mails an diese Postfächer noch zur Quelle übertragen werden. Zudem sollte ich auch alle sekundären Adressen mit addieren.

Damit ist das Ziel vorbereitet und dennoch kein Risiko für die Quelle, dass z.B. keine Mails mehr ankommen. Aber das stimmt nicht ganz, denn achten Sie u.a. auf folgende Dinge

• Kalender in Teams
  Ein Benutzer aus Firma B kann in Firma A mit Teams arbeiten und hat nun mit dem Postfach plötzlich doch einen Kalender, der aber leer ist und in dem erst einmal keine Termine landen.
• Keine Stellvertretungen!
  Vermeiden Sie hier auch die Einrichtung von Stellvertretungen, damit nicht Mitarbeiter von Firma A
• Autodiscover und Office
  Denken Sie auch daran, dass Outlook 365 per Default auch eine Anfrage an Exchange Online stellt und sich nicht nur an den Service Connection Point oder Autodiscover.<domain> nutzt.
• Teams und Exchange OnPrem
  Diese Funktion ist in meinem Beispiel aber nicht relevant, da ich keinen Hybrid-Mode habe.

Die Liste ist sicher nicht komplett. Sie sollten also schnell anfangen, die Inhalte zu synchronisieren. Auch hier gibt es zwei Herangehensweisen:

• Option1:
  Übertragen von allen Elementen bis zu "heute -14 Tage"
  Umschalten der Anwender (Umleitung umdrehen, MX-Record/AutoDiscover ändern, Clients umstellen)
  Nachmigration der letzten 14 Tage
• Option2:
  Umschalten der Benutzer auf die leere Zielumgebung
  Migration der Elemente von der Quelle. Termine, Kontakte und neueste Elemente zuerst

Ich bin ein Freund von Option1: weil ich dann vorab schon sicher bin, dass zumindest 95% der Elemente im Ziel sind und die Geschwindigkeit ggfls. gedrosselt werden kann oder durch Throttling-Policies serverseitig gedrosselt wird. Das ist umso wichtiger, wenn der Export von einem lokalen Server erfolgt und das Migrationssystem die Mails über die WAN-Leitung übertragen muss.

Migrationstools

In der Vergangenheit habe ich neben den Bordmitteln sehr gerne auch mit den Werkzeugen von Quest migriert. Das war insbesondere OnPremises und mit Notes als Quelle eine gute Wahl. Mit der Cloud haben sich aber die Marktanteile verschoben und wir haben nun viele Anbieter mit ganz unterschiedlichen Ansätzen. Ich habe exemplarisch und nicht repräsentativ meine Stichpunkte erstellt.

Es gibt natürlich noch weitere Produkte wie Audriga, BitTitan etc. und einige mehr habe ich auf 3rd-Party Migrationstools aufgeführt. Ein Stück weit musste ich aber filtern und wenn ich die Informationen zu einem Produkt nicht mit einem vertretbaren Aufwand ermitteln konnte, habe ich es erst einmal zurück gestellt, z.B.: wenn selbst Marketingvideos (How xxx Works) nur nach vorherige Anmeldung ersichtlich sind.

Ich frage mich manchmal schon, ob Marketingabteilungen wirklich Usability-Tests machen. Eine Suche nach Migrations-Tools wird durch Consultants oder Administratoren aber nicht durch Geschäftsführer oder Einkäufer gestartet. Die brauchen keine "schicken Webseiten" sondern Fakten, d.h. Aussagen zur Funktionsweise, einfache Test/Trial-Möglichkeiten und natürlich muss ein Preisrahmen ersichtlich sein. Es ist übrigens immer wieder erschreckend, wie viele Webseiten ohne JavaScript komplett unbenutzbar sind. Schlechte Aussichten, wenn ich auf einem Server so eine Online-Doku lesen müsste.

Ich hätte gerne noch weitere Tools getestet aber bin zeitlich nicht dazu gekommen und da meine Kollegen bislang schon viel mit Fly gemacht haben, habe ich diesmal die SaaS-Lösung genutzt. Beachten Sie, dass sie bei selbst gehosteten Systemen neben Kosten für die Hardware/VM auch Festplattenplatz für die Datenbanken mit dem Migrationsstatus und Bandbreite berücksichtigen müssen.

Ganzheitliche M365 Tenant zu Tenant Migration mit AvePoint Fly
https://www.netatwork.de/ganzheitliche-m365-tenant-zu-tenant-migration-mit-avepoint-fly/

• CodeTwo
  https://www.codetwo.de/office-365-migration/
  https://www.codetwo.com/userguide/office-365-migration/walkthrough-from-hosted-exchange.htm
• Fly SaaS
  https://cdn.avepoint.com/assets/webhelp/fly/index.htm#!Documents/performexchangeonpremisesmigrations.htm
  Run Migrations to Migrate Objects
  https://cdn.avepoint.com/assets/webhelp/fly/index.htm#!Documents/runmigrationstomigrateobjects1.htm
• Cloudiway
  https://cloudiway.com/documentation/exchange-to-microsoft-365/
  https://help.cloudiway.com/article/delta-pass-mail-migration/

Migration mit Fly SaaS

Die Vorarbeiten habe ich oben schon beschrieben, so dass ich hier nur noch die Übertragung der Inhalte mit der Fly SaaS in Stichpunkten zusammenfasse. Fly stellt einen Container bereit, in dem die Migration gesteuert wird und an den die Lizenzen gebunden werden. Wenn Sie mehrere Quellen in ein Ziel migrieren oder das Ziel auch zukünftig andere Dienste von Avepoint, z.B. Backup, nutzen möchte, dann sollten Sie eine Mailadresse aus dem Ziel als erste Domain anlegen. Ein Dienstleister sollte hier nicht seine Avepoint-Instanz nutzen.

Schritt	Erledigt
Anmelden bei Fly Wir starten bei https://www.avepointonlineservices.com/services, wählen das passende Datacenter (Deutschland Westen-Mitte (Frankfurt) aus und aktivieren nur den Dienst "Fly". Alle anderen Dienste brauchen wir erst einmal nicht. Avepoint braucht noch ihre Kontaktdaten. Das erste Konto ist wie bei Office 365 ein Administrator. Vielleicht legen Sie eine Mailadresse "avepoint@<firma>" als Verteiler oder eigenes Funktionspostfach an, damit Sie so ein generisches Konto nutzen können. Hinweis: Wenn Sie auf https://www.avepoint.com/de/free-trial starten, dann ist der SaaS-Einstieg auf der zweiten Karteikarte "Cloud Trials" versteckt.
Weitere Benutzer anlegen Nachdem Sie den Zugang verifiziert haben, können Sie natürlich weitere Benutzer unter https://www.avepointonlineservices.com/#/management/user anlegen und berechtigen. So können Sie z.B. einen Dienstleister erlauben, für Sie die Migration durchzuführen. Avepoint sendet dann einen Einladungslink an die Mailadresse mit einem Startkennwort. Sie können aber noch warten, bis Sie im nächsten Schritt den Tenant verbunden haben  und dann auf die Benutzerdatenbank des Tenants zurückgreifen. Als „Dienstadministrator“ sind die ebenfalls allmächtig. Als „Tenant Benutzer“ können Sie einige Dinge nur lesen und über die gesondert zuweisbare Rolle „Fly Anwendungsadministrator“ können Sie nur Migrationen steuern.
Tenant verbinden Über https://www.avepointonlineservices.com/#/management/tenant müssen Sie eine Verbindung zum „Zieltenant“ herstellen. Sie können hier bei einer Tenant zu Tenant Migration natürlich auch gleich die Quellen ebenfalls einrichten.
App-Verwaltung Mit Conditional Access und MFA und Security Defaults sollten sie kein Dienstkonto nutzen, sondern eine App einrichten und den Consent erteilen. Das erfolgt über https://www.avepointonlineservices.com/#/management/app. ACHTUNG: Fly fordert schon sehr umfangreiche Rechte an, damit er Mails aus einer Quelle in beliebige Zielpostfächer importieren soll. Leider nutzt Avepoint (Stand Herbst 2023) noch nicht die Recht, um z.B. auch die Identitäten in der Quelle und Ziel zu lesen und zu übertragen. Noch muss ich die Objekte im Ziel passende mit Eigenschaften anlegen. Sie können aber über eine eigene "Custom AzureApp" genau die Berechtigungen steuern und müssen nicht die von Avepoint vordefinierten Apps nutzen. Permissions for Source Exchange Online https://cdn.avepoint.com/assets/webhelp/fly/index.htm#!Documents/permissionsforsourceexchangeonline.htm Permissions for Destination Exchange Online https://cdn.avepoint.com/assets/webhelp/fly/index.htm#!Documents/permissionsfordestinationexchangeonline.htm
Exchange OnPremises Dienstkonto einrichten Für Exchange OnPremises als Quelle gibt es natürlich keine „Apps“: Daher müssen wir unter https://www.avepointonlineservices.com/#/management/service-account und die Karteikarte „OnPremises“ ein klassisches Dienstkonto einrichten und lokal berechtigen. Fly kennt einige alternative Exchange Hoster wie „1&1 Ionos“, AppRiver“, „Apptix“ und „Cobweb“. Für den eigenen Server tragen wir einfach  den OnPremises Exchange Servernamen ein.
Exchange Online Tenant Discovery Ein Discovery der OnPremises-Umgebung geht mit der Fly SaaS-Lösung im Dez 2023 noch nicht. Sie können aber nach Zuweisung der erforderlichen EntraID-Rollen ihren Exchange Online Tenant einmal inventarisieren lassen. Für die Exchange OnPremises zu Tenant Migration ist das nicht erforderlich.
Connections anlegen Nach den Vorarbeiten können wir nun zu Fly wechseln und die Connectoren auf https://fly.avepointonlineservices.com/#/settings/connection zur Quelle und dem Ziel unter Rückgriff auf die vorher schon angelegten Dienstkonten bzw. AppRegistrations anlegen. Eventuell müssen Sie in Exchange Online das EWS-Limit anheben. Throttling limits https://cdn.avepoint.com/assets/webhelp/fly-migration-process-guide/index.htm#!Documents/9throttlinglimits.htm. MaxReceiveSize 36MB Bei der Übertragung von Mails mittels EWS könnten Mails mit 25MB oder größer durch die BASE64 Codierung die Obergrenze von 36MB pro Mail blockiert werden. Diese Grenze kann in Exchange Online bis auf 150 MB angehoben werden. Wenn Sie im Fly-Portal also "EX-MaxMEssageSizeExceeded"-Meldungen sehen dann müssen Sie hier aktiv werden. Exchange Online Message Rate Grenzen.
Migration Policies Ehe wir gleich eine Migration konfigurieren, definieren wir unter https://fly.avepointonlineservices.com/#/settings/migration/hosted-exchange-policy die Randbedingungen der Migration, z.B. Einstellungen wie Umfang, Alter, Konfliktabhandlung, Archivierung, Löschungen etc.
Migrationsprojekt anlegen Nach all den Vorarbeiten können wir https://fly.avepointonlineservices.com/#/project/all-list ein Projekt anlegen und die Liste der Quell-User und Ziel-User eintragen. Diese Liste können Sie natürlich auch aus einer Excel/CSV-Datei importieren. Danach starten wir zwei Aktionen: "Verify Mapping“: Damit prüft Fly, dass er die Postfächer in Quelle und Ziel finden kann „Scan Source Data“ Damit prüft Fly den Zugriff auf die Quellen, d.h. dass er ausreichende Rechte hat.
Migration starten Der nächste Schritt ist dann eine Migration gemäß der Vorgaben. Wir wissen nun auch, wie viele Benutzer etwas tatsächlich sind und müssen den Lizenzkauf anstoßen. Die Trial-Version erlaubt nur eine Migration von bis zu 3 Postfächern. „Full Migration“: Kopiert einmal alle Daten aus der Quelle ins Ziel. „Incremental Migration“ Überträgt später immer wieder die Änderungen. Wie schnell das letztlich funktioniert, hängt von der Quelle (Bandbreite, Inhalte), dem Ziel (Disk-IO, Bandbreite) und Fly-Instanz ab. Meine Migrationen haben pro Postfach ca. 1,5-2 GB/h und 1500-2000 Objekte/Stunde geschafft. Ein XXL-Postfach mit 100.000 kleinen Objekten schaffte ca. 6000 Objekte/Stunde aber nur 0,5GB/h.
Migration abschließen Eine Koexistenz ist bei dieser Art einer Migration nicht vorgesehen. Zum festgelegten Zeitpunkt werden die Postfächer umgestellt, d.h. Umleitung im Ziel entfernen und ggfls. in der Quelle aktivieren MX-Record und Autodiscover ins Ziel umstellen Nach kurzer Zeit sollten alle Mails nun im neuen System ankommen. Alle Clients umstellen z.B. indem man das Profil neu anlegt, ActiveSync Partnerschaft ersetzt und die Quelle für die Anwender sperrt, z.B. indem das Kennwort zurückgesetzt oder das Konto deaktiviert wird Nachmigration Die zwischenzeitlichen Änderungen müssen noch einmal nachmigriert werden. Werden die Quelle/Ziel-Adresse beim Umschalten geändert, dann müssen Sie dies der Migrationssoftware mitteilen, sonst findet diese die Partnerschaften nicht mehr
Rückbau Wenn alle Benutzer im Ziel arbeiten und sich in der Quelle nichts mehr durch weiter aktive Benutzer oder alte Prozesse ändert, dann können Sie die Quelle und den Migrationsjob zurückbauen.

Dies ist nur eine Kurzfassung und kann nicht die ganzen Details und Erfahrungen beim Umgang wiedergeben.

Testfälle

Ich habe nicht alle möglichen Varianten und Konflikte durchgespielt aber einige Fälle wollte ich dann doch genauer wissen: Die Ergebnisse basieren auf einer Inkrementellen Migration von Exchange 2019 OnPremises nach Exchange Online am 10. Dez 2023. Das Produkt kann sich zwischenzeitlich weiterentwickelt haben.

Bei den meisten Fällen macht Fly das beste aus der Situation. Aber Sie sollten auch die wenigen Einschränkungen kennen, die nicht übertragen werden können. Ihre Anwender sollten auf jeden Fall auf Umbenennen von Ordnern und Löschen/Verschieben von Objekten in der Zeit verzichten und niemals im Ziel etwas ändern.

Fragen an 3rd Paty Tools

Eigentlich ist es Hexenwerk, tausende von Mails per EWS aus einer Quelle zu lesen und in ein Ziel zu kopieren. Aber es gibt schon die ein oder anderen Fallstricke, die sich aber nicht oder nur mit hohem Aufwand lösen lassen. Hier ein paar Fragen, die Sie ihrer Migrationssoftware stellen könnten:

• Rückantworten bei Domainwechsel
  Wie ist das Problem gelöst, dass jemand nach der Migration auf eine alte Mail antwortet und der Absender nun eine neue SMTP-Adresse, einen neuen LegacyExchangeDN und keine passende X500-Adresse hat? (Siehe LegacyExchangeDN und X.500) Die Mail kommt unzustellbar zurück. Der Absender sollte dann den Empfänger neu aus der Adressliste auswählen.
• Postfach-Stellvertreter und SendAs
  Überträgt die Migrationssoftware auch Berechtigungen anderer Benutzer? Einige Produkte versuchen dies.
• Ansichten und Regeln mit Weiterleitungen
  Bei Exchange zu Exchange wäre es nett, wenn Regeln und Ansichten mit übertragen würde. Das geht natürlich nicht bei komplett unterschiedlichen Systemen.

Das sind nur ein paar Fragen, und Konfliktszenarien, die Produkte unterschiedlich behandeln. Zwei Dinge sind mir aber aufgefallen, wo viele Produkte anscheinend noch Probleme haben:

• Mapping Tabelle von Hand
  Alle Produkte migrieren Mails von einem Quell-Postfach in ein bestehendes Zielpostfach. Je nach Produkt muss der Administrator die Zuordnung per CSV-Datei oder manuell vornehmen. Soweit ich weiß, kann ich bei Exchange per EWS auch die GAL abfragen. Die Produkte könnten also sehr wohl allein per EWS die Quellen und Ziele ermitteln. In der Cloud wäre auch der Zugriff und sogar schreiben per Graph möglich.
• Noch kein Graph für Exchange Online
  Anscheinend ist EWS noch der einfachere Weg, weil dabei vermutlich keine Formate geändert werden müssen. Aber das Ende von EWS in Exchange Online ist schon angekündigt und daher kann ich nur hoffen dass alle Anbieter schon an der Weiterentwicklung sind.

Was mich an Fly SaaS damals gestört hat

Das sind natürlich meine subjektiven Einschätzungen vom Herbst 2023 und können schon wieder obsolet sein. Bei der von mir damals genutzten Fly SaaS-Lösung könnte auch noch einige Dinge verbesser werden, z.B.:

• Zugang für Dienstleister
  Ich kann die Mailadresse eines "Lokalen User" nur einmal verwenden. Wenn ich bei mehreren Kunden in deren Instanz die Migration überwachen will, brauche ich jede Menge "Wegwerf-Adressen" und sollte meine eigene primäre Mailadresse besser nur in meiner eigenen Instanz verwenden oder mit dem AzureAD koppeln
• Keine Postfachgröße nach "Scan Source Data"
  Ich würde mir wünschen, dass in der Tabelle auch eine Spalte mit der aktuellen Größe und der Item-Anzahl sichtbar wäre.
• Fehler:"EX-MailSizeExceedLimit"
  Diese Meldung habe ich recht oft und Fly SaaS zeigt auch schön den Ordner und den Betreff an. Aber leider nicht die Größe der Mail, die nicht migriert wird.
• OnPrem Reporting
  Ich kann bei einer Tenant2Tenant-Migration sehr einfach einen Überblick über die Tenant-Nutzung erhalten. Fly Server kann dies auch OnPremises aber Fly SaaS im Dez 2023 leider noch nicht.
• Sprache und Default Folder
  Ein einer Testumgebung mit unterschiedlichen Postfachsprachen (Quelle vs. Ziel) wurden zwar alle Mails migriert aber die Default Folder nicht gematched, d.h. ich hatte die Standard-Order doppelt (Inbox/Posteingang, Calendar/Kalender, Kontakte/Contacts, etc.) und für den Benutzer waren die Elemente erst einmal nicht da.

Weitere Links

• 3rd-Party Migrationstools
• EXO Bordmittel zur Migration
• Cutover und ADSync
• IMAP4 Migration mit Exchange Online
• PST Import als Migrationsweg
• PST Export
• Remote Move Request - Kurzfassung
• RemoteMoveRequest ohne Hybrid
• LegacyExchangeDN und X.500
• Von SharePoint On-Premises in die Microsoft 365 Cloud Sichere Microsoft 365 Cloud Migration mit AvePoint Fly
  https://www.netatwork.de/sichere-microsoft-365-cloud-migration-mit-avepoint-fly/ 
• Ganzheitliche M365 Tenant zu Tenant Migration mit AvePoint Fly
  https://www.netatwork.de/ganzheitliche-m365-tenant-zu-tenant-migration-mit-avepoint-fly/