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.

Produkt/Kriterium CodeTwo Fly SaaS Fly Server Cloudiway
Kosten pro Exchange Postfach (ohne Mengenrabatt)
Raum/Shared/Ressource
Public Folder
10€
0€
100 User
15€/User/Jahr
0€
-
15€/User/Jahr
0€
-
9,50€/3 Monate
?
?

TrialLimit

5 Mailboxen,

3 Mailboxen

5 Mailboxen

100MB/Mailbox

Plattform

Windows Software auf einem PC

SaaS

Windows Software auf einem PC

SaaS

Exchange OnPrem Zugriff (EWS)

Impersonation, CDO

Full Access
Impersonation

Impersonation
FullAccess
Impersonation
FullAccess
UserCredential

Exchange Online Zugriff (EWS)

EWS mit Impersonation oder Full Access oder App Permission

EWS mit Impersonation oder Full Access oder App Permission

EWS mit Impersonation oder Full Access oder App Permission

App Permission

IMAP (wenn man nicht die Bordmittel nutzen will)

IMAP User oder Full Access

Nein

Ja

Ja

Sonstiges

nur Mails, kein OneDrive, Teams, SharePoint

SharePoint, OneDrive, Teams, u.a.

SharePoint, OneDrive, Teams, u.a.

OneDrive, Teams, Sharepoint, Google, Slack, IMAP, Zimbra, Notes

Einschätzung

Ein einfaches, günstiges aber tolles Programm, wenn Sie selbst sie auf einem eigenen Server Mails auf ein andere System kopieren wollen. Leider gibt es kein SaaS -Angebot und wenn Quelle und Ziel in der Cloud sind, müssten Sie schon selbst eine AzureVM o.ä.. bereitstellen.

Als SaaS Lösung brauchen Sie keine eigenen Server und alles läuft in der Cloud. Eine ExOnPremises-Analyse gibt es ebenso wenig wie IMAP4

Vorteilhaft, wenn man viele Dienste von OnPremises in die Cloud migrieren will und die lokalen Server nicht extern veröffentlicht sind.

Konnte ich nicht weiter evaluieren. (kein Verschulden des Anbieters)

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/

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.

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.

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.

Fall Szenario Ergebnis Status

1

Quelle: Neues Element (Mail, Termin, Kontakt)

Werden beim Fullmigration und inkrementellen Migrationen übertragen

OK

2

Quelle: Mail löschen

In der Quelle gelöschte Mails werden im Ziel nicht gelöscht! Wurde die Mail in der Quell nach "Gelöschte Objekte" verschoben und ist der Ordner in der Migration eingeschlossen, dann wird diese migriert, d.h. ist dann doppelt im Postfach.

Unschön

3

Quelle: Mail ändern(z.B. Gelesen/Ungelesen/Kennzeichnung)

Gelesen/ungelesen und Kennzeichnen wurden problemlos beim inkrementellen Migration übertragen. Fly erkennt also die Änderungen in der Quelle und kann Sie den Objekten im Ziel zuordnen

OK

4

Quelle: Mail in anderen Ordner verschieben

Objekt wird im neuen Ordner neu migriert aber am alten Platz im Ziel nicht gelöscht.

Unschön

5

Quelle: Termin verschieben (Zeitpunkt)

Geänderte Termine werden Ziel aktualisiert. Fly erkennt die Änderung in der Quelle. Er überschreibt sogar Änderungen im Ziel durch die Quelle

OK

6

Quelle: Termin löschen

Wurden Termine in der Quelle gelöscht, verschwanden diese auch im Ziel

OK

7

Ziel: Termin löschen

Die Termine werden erst wieder angelegt, wenn er in der Quelle verändert wird.

OK

8

Quelle: Kontakt Neu

Kontakt wird übertragen, ggfls. in anderem Kontaktordner

OK

9

Quelle: Kontakt ändern (Rufnummer)

Kontakt wird beim inkrementelle Update aktualisiert

OK

10

Quelle: Kontaktgruppe mit Kontakt + GAL Kontakt

Werden samt aller Mitglieder übernommen aber Mitglieder aus der GAL erscheinen z.B. mit dem LegacyExchangeDN als Adresse und sind damit nur nutzbar, wenn Sie auch die Benutzer mit X.500 Adresse mit kopieren

OK

11

Quelle: Ordner umbenennen

Der Ordner wird als neu im Ziel angelegt aber die Elemente nicht neu kopiert. Sie bleiben im Ziel im Ordner mit dem alten Namen.

Unschön

12

Ziel: zusätzliche Mail empfangen

Bleiben erhalten, d.h. die Migration löscht keine überzähligen Elemente.

OK

13

Ziel: Ordner umbenennen und in der Quelle eine Mail darin ändern

Der Ordner der Quelle wird im Ziel neu angelegt aber nur das eine geänderte Objekte übertragen.

Beachten

14

Sprachkonflikt: Quelle Posteingang und Ziel "Inbox"

Leider matched Fly nicht die "Default Folders", sondern kopiert die Ordner 1:1 mit dem Namen. Im Ziel hatte ich dann neben der Inbox auch noch einen Posteingang und auch alle anderen Ordner. Achten Sie darauf, dass die Sprache des Ziels mit der Quelle übereinstimmt, damit die Benutzer die Inhalte der Standardordner nicht verschieben müssen.

Unschön

15

Weitere Einstellungen

Ich habe in der Quellmailbox auch einige Einstellungen vorgenommen und die Migration geprüft:

  • Posteingangsregeln: Werden mit übertragen und aktualisiert - Funktion hängt von der Aktion ab.
  • Out of Office Einstellungen: Wird mit übertragen und aktualisiert
  • Signatur: Wird mit übertragen und aktualisiert
  • Berechtigungen auf Ordner: Wird nicht übertragen
  • Berechtigungen auf Postfach: Nicht getestet.
    Postfach

Beachten

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/a>