IMAP4 Migration mit Exchange Online

Exchange Online kann mit Bordmitteln Postfächer von über das Internet erreichbar IMAP4-Server exportieren. Hier meine Notizen zur Funktionsweise und Ergebnisse verschiedener Tests.

Funktionsweise

Eine Migration per IMAP4 ist deutlich einfacher und geradliniger als Cutover, Staging oder RemoteMove-Migrationen. Das liegt sowohl am Inhalt als auch an den erforderlichen Vorarbeiten.

  • Exchange verbindet sich per BASIC/NTLM an IMAP4-Server
    Es gibt keine Sonderfunktionen für OAUTH, Kerberos, Zertifikate oder andere Anmeldeverfahren. Der IMAP4-Server muss einfach aus dem Internet erreichbar sein. Ich würde immer TL oder SSL nutzen aber auch unverschlüsselte Verbindungen sind möglich.
  • Liste der Benutzer als CSV-Datei
    Der Exchange Online Migrationsdienst muss mit einer CSV-Datei gefüttert werden, welche die Mailadresse, Username und Kennwort für den Zugriff enthält. Das ist entweder das Kennwort jedes Postfach oder sie bekommen einen Benutzer, der alle Postfächer lesen kann. Die Date kann maximal 50.000 Benutzer enthalten und muss <10MB sein, d.h. ca. 200 Byte/Zeile
  • Zielpostfach muss existieren
    Der Migrationsjob legt keine Benutzer an und aktiviert keine bestehenden Benutzer zu einem Mailboxuser. Das Zielpostfach muss schon existieren.
  • Userprovisioning mit ADSync/DirSync
    Sie können als Ziel sowohl CloudUser als auch DirSync-User nutzen. Der Migration ist das egal, solange es im Ziel ein Postfach mit der Mailadresse gibt, die in der CSV-Datei die Quelle definiert. Damit ist aber auch klar, das es keine Migration von User1 zu User2 unterstützt wird. Wie Sie die Benutzer anlegen und die Mailadressen der Quelle auch im Ziel übertragen, bleibt ihnen überlassen. Wer Exchange Hybrid nutzt, wird daher die Zielpostfächer in der Cloud mit einem "Enable-RemoteMailbox im lokalen AD anlegen und nach der Replikation mit ADSync die Postfächer in der Cloud mit einer Lizenz versehen.
  • Nur Mails, keine Kontakte, Termine, Aufgaben o.ä.
    Ein klassisches IMAP4-Postfach enthält nur Mails aber sonst keine Informationen. Sicher gibt es Clients, die IMAP4 auch zur Ablage von anderen Informationen nutzen aber bei der Migration werden diese "als Mails" übertragen. Es ist relativ unwahrscheinlich, dass Outlook damit etwas anfangen kann.
  • Limits 500.000 Mails und 35MB
    Es werden keine Mails >35MB migriert und mehr als 500.000 Elemente sind auch nicht möglich. Wer so viele Mails in der Quelle hat, muss archivieren, Aufteilen, Löschen oder 3rd Party Tools probieren.
  • Filterung
    Sie können Ordner bei der Migration ausschließen und auch nach dem Datum filtern. Order mit einem "/" im Namen kommen nicht mit und sollten vorher in der Quelle umbenannt werden.
  • Keine Verteiler/Kontakte
    Exchange Administratoren kennen die Funktion, dass Sie im AD/AzureAD auch Gruppen als Mailverteiler anlegen können. Bei einem MAP4-Service ist das ein LDAP-Server. Für die Migration gibt es hier keine Anknüpfungspunkte.
  • Exchange Online synchronisiert Inhalte
    Wenn alle Inhalte einmal kopiert sind, dann aktualisiert Exchange Online alle 24h automatisch eine Deltamigration. Dabei werden bis zu 10 Postfächer gleichzeitig inkrementell und 20 initial migriert.
  • Migration ist OneWay zu Exchange Online
    Exchange Online kann nur IMAP zu Exchange Online migrieren. Eine Rückmigration ist nicht vorgesehen.

Schade, dass IMAP4 nur Mails übernimmt. Für alles anderen Inhalte gibt es dann 3rd-Party Migrationstools.

Ablauf

Damit ist der Ablauf einer IMAP4-Migration einer kompletten SMTP-Domain zu Exchange Online mit den Bordmitteln schnell erzählt:

  • Domain im Ziel-Tenant registrieren
  • Benutzer mit Postfächer und zur Quelle passenden Mailadressen anlegen
  • CSV-Datei mit Liste der Benutzer und Kennwort anlegen
  • IMAP4-Migration mit Migration Endpunkt zum aus der Cloud erreichbaren IMAP4-Server und CSV einstellen
  • Warten und kontrollieren, dass die Datenmigration funktioniert
  • MX-Record zu Exchange Online umstellen und Benutzer auf die Quelle umziehen
  • Eine letzte Synchronisation starten (SyncNow)
  • Quelle abbauen

Wer nicht alle Benutzer auf einmal umstellen will, muss natürlich für ein aktives Postfach auf einer Seite auf der anderen Seite eine entsprechende Umleitung einrichten und ein zuverlässiges Mailrouting zwischen beiden Systemen konfigurieren.

Einrichtung

Schon die Anleitung von Microsoft zur Konfiguration eines Migrationsbatch ist sehr umfangreich und im Exchange Portal auch ohne Handbuch zu bewältigen. Sie benötigen ja auch nicht viel mehr als der Hostname des IMAP4-Quell-Servers und die CSV-Datei mit der Mailadresse, Anmeldenamen und Kennworte. Ich habe zum Test einfach mein Postfach bei IONOS genutzt und eine CSV-Datei mit dem header und genau einer Zeile erstellt.

EmailAddress,UserName,Password
imap4test@carius.de,imap4test@carius.de,Das!ist!das!imap4test!Kenn

Der Migrationsjob startet dann auf https://admin.exchange.microsoft.com/#/migrationbatch, Sie geben dem Migration Batch einen Namen und wählen "Migration zu Exchange Online" aus und im nächsten Schritte dann IMAP4.

Auf dem folgenden Fenster werden dann noch einmal die Schritte beschrieben, dass sie im Ziel die Benutzer samt Postfächer anlegen müssen. Der Tenant muss auch die Domain haben, wenn Sie den Benutzern die Mailadresse geben müssen. Das wir den IMAP4-Servername und die CSV-Datei benötigen, wird auch noch einmal angegeben. Im nächsten Schritt legen Sie dann ihren IMAP4-Server als "Migration Endpoint" an. Der Endpunkt bekomm auch einen Namen und kann hinsichtlich der Concurrent Migration und inkrementer Synchronisation konfiguriert werden. Natürlich sollten sie TLS auswählen.

Der nächste Schritt ist dann schon der Upload der vorbereiteten CSV-Datei:

Optional können noch Ordner oder Elemente nach der Zeit ausgeschlossen werden:

Zuletzt müssen wir nur noch den Zeitplan zum Start und Abschluss vorgeben.

Normalerweise startet der initiale Kopierprozess sofort aber wird nicht automatisch beendet. Das ist auch OK, denn wir müssen vor dem letzten Sync dafür sorgen, dass keine Mails mehr in der Quelle ankommen, z.B. indem wir den MX-Record umstellen oder in der Quelle für diese Postfächer eine Umleitung einrichten.

Sie können natürlich all diese Einstellungen auch per PowerShell ausführen. Ich gehe aber nicht davon aus, dass viele Administratoren auf die Web-UI verzichten.

Steuerung und Status

Während der Migration kann ich ebenfalls im Exchange Admin Center den Migrationsjob und die darin enthaltenen Postfächer überwachen.

Die Details dazu sind.

Über die "Edit"-Funktion können Sie nur das Ende zwischen "Manuell" und "Zeitpunkt" umstellen. Beachten Sie aber auch den oft übersehen Links "View Details", der dann die Postfächer in dem Job mit ihrem Status anzeigt.

Hier können sie einzelne Postfächer stoppen oder sogar entfernen. Ein Klick auf die Zeile selbst zeigt die Details zur Migration dieses Postfachs an.

In meinem Fall hat die Migration ca. 18700 Elemente mit insgesamt 2,3 GB in etwa Stunde migriert. Das Ergibt einen Durchsatz von 700kByte/Sek oder 7MBit/Sek. Die Performance hängt natürlich von der Geschwindigkeit des Quellsystems beim Ausliefern der Daten ab.

Vielleicht haben Sie noch nicht bemerkt, dass bei einer kleineren Ansicht im Browser die nicht angezeigten Funktionen in dem "..."-Menü verschwinden. Gerade die "SyncNow"-Funktion ist interessant, wenn Sie nicht 24h auf den nächsten geplanten Sync einer laufenden Migration warten wollen.

Wenn Sie im Migration Job eine Mailbox für Berichte angeben, dann landet dort nach jedem Zwischenstand eine Statusmail:

Status per Powershell

Per PowerShell gib es die beiden Commandlets Get-MigrationBatch, Get-MigrationUser, GetMigrationUserStatistics und Get-MigrationStatistics

Get-MigrationStatistics liefert einen Überblick über alle aktiven und vergangenen Migrationen:

PS C:\> Get-MigrationStatistics | fl

Identity         : carius.onmicrosoft.com
TotalCount       : 4
ActiveCount      : 0
StoppedCount     : 0
SyncedCount      : 2
FinalizedCount   : 0
FailedCount      : 2
PendingCount     : 0
ProvisionedCount : 0
MigrationType    : IMAP
Diagnostics      :
DiagnosticInfo   :

Über "Get-MigrationBatch" bekommen Sie zu jedem Batch bis zu 90 Felder mit weitergehenden Informationen. Essentiell sind z.B.

PS C:\> Get-MigrationBatch | fl identity,stat*,*Datetime*,*count*

Identity                  : IMAP4-9
Status                    : Synced
State                     : Waiting
CreationDateTime          : 19.10.2023 10:25:12
CreationDateTimeUTC       : 19.10.2023 10:25:12
StartDateTime             : 19.10.2023 10:25:12
StartDateTimeUTC          : 19.10.2023 10:25:12
ExpirationDateTime        : 18.12.2023 10:42:02
ExpirationDateTimeUTC     : 18.12.2023 10:42:02
LastSyncedDateTime        : 19.10.2023 10:26:35
LastSyncedDateTimeUTC     : 19.10.2023 10:26:35
TotalCount                : 1
ActiveCount               : 0
StoppedCount              : 0
SyncedCount               : 1
FinalizedCount            : 0
FailedCount               : 0
CompletedWithWarningCount : 0
PendingCount              : 0
ProvisionedCount          : 0
ValidationWarningCount    : 0

Details zu den einzelnen Benutzer gibt es mit Get-Migrationuser, ggfls. verkettet mit Get-MigrationUserStatistics. Hier eine exemplarische, leicht gekürzte, Ausgabe.

PS C:\> get-MigrationUser imp4user@carius.de | fl *

Identity                  : imp4user@carius.de
Guid                      : 53174b61-6f1e-4eeb-ab29-6b447268dbbc
BatchId                   : IMAP4-9
MailboxIdentifier         : imp4user@carius.de
MailboxEmailAddress       : imp4user@carius.de
RecipientType             : Mailbox
SkippedItemCount          : 0
SyncedItemCount           : 4
TransferredItemCount      : 0
MailboxGuid               : ffda4473-5579-4fb1-9216-fbfe308400fc
LastSuccessfulSyncTime    : 19.10.2023 10:42:56
Status                    : Synced
StatusSummary             : Synced
MigrationType             : IMAP
State                     : Waiting
ataConsistencyScore      : Investigate
HasUnapprovedSkippedItems : True
SupportedActions          : Stop, Set, Remove, SyncNow
IsHiddenByDefault         : False
EstimatedTotalCount       : 217
EstimatedTotalSize        : 55079914

An die meisten Informationen kommen Sie aber auch über das Exchange Admin Center.

Inkrementeller Sync

Wir gehen erst einmal davon aus, dass die erste Replikation komplett durchgelaufen ist und das Postfach zu einem bestimmten Zeitpunkt "in Sync" war. Danach kann der Anwender natürlich in der Quelle weiter arbeiten und die IMAP4-Migration sollte alle 24h ein inkrementelles Update durchführen. Ich habe daher in einem Testordner vier Mails angelegt und abgewartet, bis diese im Ziel angekommen sind. Die Zeitabfolge war

17.10.2023 21:43:00  Migrationsjob angelegt
17.10.2023 21:43:00  Migrationsjob gestartet
17.10.2023 22:48:05  LastSync nach erstem inkremementellen Sync
18.10.2023 00:48:00  Erfolgreicher Sync
18.10.2023 08:42:00  Versand der Testmails "IMAP42EXOMIG Test 1" bis "IMAP42EXOMIG Test 4" für nächste Tests
19.10.2023 00:49:00  Inkrementeller Sync überträgt die vier Testmails
19.10.2023 xx_xx_xx  Änderungen der replizieren Mails im Ziel

Danach habe ich die verschiedenen Änderungen gemacht und abgewartet, was passiert. Ich habe nicht geprüft, ob weitere Änderungen im Ziel einen Einfluss haben. Technisch würde dies zu einem Konflikt führen. Aber ich erwarte nicht, dass der Anwender auf beiden Systemen parallel arbeitet. Aber es gibt zwei andere Tests, die ich nach den Test mit einzelnen Mails noch durchgeführt habe.

Hinweis:
Der inkrementelle Sync läuft immer nur alle 24h.Sie können aber einen Migrationsjob natürlich Stoppen und wieder neu starten.

Aktion Beschreibung Status

Ungültige Mailadressen

Das Postfach wird nicht migriert. Der Fehler im Log lautet:

Error: MigrationRecipientNotFoundException: 
A recipient wasn't found for "invalid@carius.de" on the target. 
Create a recipient of the appropriate type for this migration on the target and try again.

OK

Ungültiges Kennwort

Das Postfach wird nicht migriert. Der Fehler im Log lautet:

Error: ImapAuthenticationException: 
The username or password for this account is incorrect, or IMAP access is disabled. 
--> Imap server sent NO response to AUTHENTICATE. 
Response code: '', message: 'authentication failed'.

OK

Gleicher User in zwei Jobs

Das Postfach wird nicht migriert. Der Fehler im Log lautet:

Error: UserDuplicateInOtherBatchException: 
The user "frank@carius.de" is already included in migration batch "IMAP4EXO1." 
Please remove the user from any other batch and try again.

OK

Migration in Shared Mailbox

Für die Migration macht es keinen Unterschied. ob das Ziel eine UserMailbox oder eine Shared Mailbox ist. Wenn die Mailadresse gefunden wird, funktioniert der Zugriff

OK

Bestandmails

Der erste Sync kopiert alle Elemente aus der Quelle in das Ziel Ich habe nicht ausgeschlossen und nach ca. 1h waren 2,3 GB ins Ziel kopiert. IMAP4 hat sich wohl an die "internen Namen" gehalten, denn in der Quelle gab es einen "Posteingang" in Outlook über IMAP4 aber in Exchange Online war dies die "Inbox". Die IMAP4-Migration hat die Mails in den richtigen Ordner einsortiert.

OK

Stop-Migrationbatch
Stop-Migrationbatch

Um nicht 24h warten zu müssen, habe ich den Job gestoppt und wieder gestartet. Ich habe die Erwartung, dass die Mails nicht noch mal migriert und damit dupliziert werden. Es passiert aber nichts, denn beim User steht ja dran, wann der letzte Sync erfolgt ist. So funktioniert es nicht.

Warn
Set-Migrationuser -Syncnow
Set-Migrationbatch -Syncnow

Aber ich kann beim Migrationuser oder Migrationbatch einer IMAP4-Migration mit dem Parameter "SyncNow" nachhelfen. Allerdings ist auch das "SyncNow" kein sofort, sondern es kann einige Minuten dauern

OK

Quelle: IMAP42EXOMIG Test 1:Neue Mails angelegt

Der erste inkrementelle Sync sollte alle vier neuen Mails aus der Quelle ins Ziel übertragen. Das ist beim nächsten DeltaSync am 19.10 um 00:49 erfolgt.

OK

Quelle: IMAP42EXOMIG Test 2: Mail gelöscht

Nach dem erste inkrementelle Sync habe ich die Mail in der Quelle "hart" gelöscht und nicht nach "Gelöschte Objekte" verschoben. Beim nächsten Sync wurde dies erkennat nud das Objekt auch im Ziel gelöscht.

OK

Quelle: IMAP42EXOMIG Test 3: Mail in anderen Ordner verschoben

Auch hier hat die IMAP4-Migration korrekt die Änderung erkannt und das Element auch im Ziel in den richtigen Ordner verschoben. Das würde so dann auch für Löschungen in den Papierkorb gelten

OK

Quelle: IMAP42EXOMIG Test 4: Mail geändert (gelesen/ungelesen)

Mit dem nächsten Sync wurde der "Gelesen"-Status wurde ebenfalls korrekt übertragen.

OK

Ziel: IMAP42EXOMIG Test 1: Mail gelöscht

Ich wollte wissen, ob die Mail beim nächsten inkrementellen Sync wieder angelegt wird. Daher habe ich sie im Ziel einfach mal gelöscht. Beim dem nächsten Sync-Lauf wurde die Mail nicht mehr erneut migriert. Die IMAP4-Migration scheint nicht alles der Quelle zu lesen und beim Schreiben ins Ziel zu prüfen, sondern erkennt Änderungen in der Quelle.

Warn

Papierkorbinhalte

Mit ist aber aufgefallen, dass der Ordner "Gelöschte Objekte" aus der Quelle scheinbar nicht in das Ziel übertragen wird. Ich sehe das als nicht kritisch an aber Sie sollten es wissen

Warn

Postfach aus Migrationsjobs löschen

Ich kann aus einem Job mit mehreren Postfächern ein einzelnes Postfach entfernen. Damit beende ich jegliche Migration. Es findet keine "Letzte Synchronisation" mehr statt

Warn

Migrationsjob löschen

Zum Schluss kann ich den Job anschließen und löschen oder ohne Abschluss löschen. Es findet keine "Letzte Synchronisation" mehr statt

Warn

User in neuem Job erneut migrieren.

Was passiert, wenn ich eine Mailbox nach Löschung des Migrationsauftrags ein zweites Mal migriere? Der Test ergab, dass überzählige Mails nicht gelöscht und fehlende Mails erneut übertragen wurden. Es wurden aber keine Mails dupliziert. Leider habe ich keine Information, woran Exchange erkennt, dass eine Mail schon migriert wurde.

OK

Viele Testfälle arbeiten wie erwartet aber einige Sonderfälle, sollten Sie dennoch beachten. Diese kommen in einer regulären Migration normalerweise nicht vor aber helfen beim Verständnis, was Microsoft hier anstellt.

  • Delta bei der Quelle
    So scheint die IMAP4-Migration sich den Status der Quelle zu merken. Das ist eine Grundfunktion von IMAP4, dass ein Mailclient nur die Änderungen repliziert und Exchange scheint sich auch diesen Quell-Status irgendwo zu speichern. Da die Mails bei einem zweiten erneuten Migrationsjob erneut zugestellt wurden, dürfte die Information mit dem Migrationsjob gespeichert sein und nicht am Ziel-Postfach hängen
  • Duplikaterkennung im Ziel
    Da bei einer zweiten Migration im Ziel keine Mails dupliziert wurden, muss Exchange auch hier gleiche Mails erkennen. Wie genau der Migrations-Prozess dies macht, konnte ich nicht ermitteln. In der Regel ändern sich aber einmal empfange Mails nicht.

Es kann übrigens auch Fälle geben, bei denen die Migration auf Probleme stößt. In dem Fall wird dies im "Data consistency score" abgebildet.

Hier aber ich absichtlich während einer Migration im Ziel zwei Ordner gelöscht. Ich könnte mir vorstellen, dass im Migrationsjob auch der Ziel-Status vorgehalten wird oder er die unerwarteten Änderungen im Ziel erkennt. Im Normalbetrieb sollte dies nicht passieren sondern eher Probleme beim Lesen aus der Quelle die Ursache sein.

Migration beenden

Bei den Bordmitteln Cutover (CEM), Staging (SEM) und Hybrid gibt es die Funktion, eine Migration abzuschließen. Exchange Online repliziert dann noch einmal alle Änderungen in der Quelle ins Ziel und aktiviert danach das Postfach im Ziel und bei einem Remote Move Request wird aus dem Postfach in der Quelle eine RemoteMailbox mit Umleitung in die Cloud. Das gibt es bei IMAP natürlich nicht. Sie beenden einfach die Migration mit einem "STOP" und Löschen danach den Job. Das sollten Sie aber natürlich abgestimmt machen, damit in der Quelle keine Änderungen mehr passieren, also.

  1. Zugriff der Anwender auf die Quelle unterbinden, Anwender auf Exchange Online umstellen.
    Wie möchten ja sicherstellen, dass da niemand mehr was ändert. Leider können Sie in der Quelle das Kennwort nicht einfach ändern um den Benutzer auszusperren, weil dann auch die Synchronisation nicht mehr funktioniert. Aber wenn der Anwender mit Exchange Online arbeitet und (fast) alles Mails dort hat, sollte es ja kein Problem sein.
  2. Mailrouting umstellen (MX order Umleitung)
    Falls immer noch Mails an die Quelle gehen, müssen wir dies nun anpassen, z.B. indem wir den MX-Record zu Exchange Online umstellen. Je nach TTL des DNS-Eintrags kann das etwas dauern. Auch könnte es sein, dass immer noch Mails an das alte System gehen, die direkt den Mailserver ansprechen, z.B. interne Prozesse, Skripte, Scan2Mail-Geräte etc. Daher prüfen Sie, ob Sie auf der Quelle eine Umleitung zum neuen Postfach einrichten, solange das alte System noch läuft.
  3. Letzter SyncNow
    Sie können auf den nächsten Lauf warten oder mit "SyncNow" einen letzten Abgleich anfordern. Dieser erfolgt zwar nicht sofort, da es auch nur ein Job ist, der von einem Scheduler dann vorgezogen wird aber sie können mit "(Get-migrationuser <mailadresse>).LastSuccessfulSyncTime..ToLocalTime()" schauen, wann der letzte inkrementelle Abgleich gelaufen ist.
  4. Migrationbatch oder einzelner Migrationuser löschen
    Danach entfernen Sie einfach das Migrationsobjekt. Sie müssen dies aber nicht sofort machen. Solange die Quelle weiter vorhanden ist, können sie auch noch nach dem Umstellen des Routings und des Anwenders weiter das Quellpostfach übertragen.
  5. Quelle zurückbauen
    Wenn Sie sicher sind, dass der Benutzer im Ziel arbeiten kann und alle Mails im Ziel sind, sollten sie zeitnah die Quelle zurückbauen. Sie sparen nicht nur Speicherplatz und Energie sondern verhindern auch, dass vielleicht doch noch etwas dort irrtümlich landet oder mangels Pflege die Sicherheit leidet.

Das Ende einer IMAP4-Migration muss also auch aktiv begleitet werden. Nur bei einem Exchange RemoteMoveRequest kümmert sich Exchange auch um die Quelle. Auch einige 3rd-Party Migrationstools machen das natürlich besser.

Einschätzung

Wenn Sie als Quelle einen IMAP4-Server haben oder eine Migration der Mails per IMAP4 ausreicht, dann ist die Bordmittelmigration zu Exchange Online ein einfacher, schneller und praktikabler Weg. Natürlich müssen Sie erst im Ziel die Postfächer mit den gleichen Mailadressen anlegen. ´Nur die Cutover-Migration oder 3rd-Party Migrationstools nehmen ihnen diese Arbeit ab. Wer ADSync nutzt, muss vorher im lokalen AD ein "Enable-RemoteMailbox" ausführen und die Mailadressen addieren, damit die IMAP4-Migration ein gültiges Zielpostfach findet.

Die eigentliche Inhaltsmigration ist robust, schnell und entspricht quasi einem "XCOPY" von der Quelle zum Ziel mit der Besonderheit, dass auch Löschungen in der Quelle übertragen werden. Allerdings sollten sie sich hüten im Ziel etwas zu löschen und verschieben, denn dies wird nicht mehr übertragen. Wir bei allen Migrationen gilt, dass die Zeit des Parallelbetriebs kurz gehalten werden sollte.

Wenn es nur um Mails geht, könnten Sie damit sogar dauerhaft Postfächer eines Quell-Systems in Exchange Online replizieren lassen, quasi als "Backup" oder Notfallsystem. Sie verlieren allerdings dann bis zu 24h, denn die Replikation erfolgt nicht häufiger und ob so ein "Dauermigrationsjob" sinnvoll ist, sei dahingestellt. So dürfen die Benutzer ihre Kennwort dann nicht ändern. Dafür eignet sich diese Funktion also nicht.

Weitere Links