Was ist der IMAP-Import des Exchange Admin Centers?
Microsoft stellt im Exchange Admin Center (EAC) eine integrierte IMAP-Migrationsfunktion bereit, mit der Administratoren E-Mails von jedem IMAP-Server zu Exchange Online (Microsoft 365) importieren können. Dieses native Werkzeug ist für Organisationen konzipiert, die von Nicht-Microsoft-Plattformen migrieren: Gmail, Zimbra, Dovecot, Courier, cPanel-Hosting und jeder andere Server mit IMAP-Unterstützung.
Der IMAP-Import des Exchange Admin Centers ist oft das erste Werkzeug, das Administratoren ausprobieren. Keine Drittanbieter-Software. Keine zusätzlichen Lizenzkosten. Direkt in die Microsoft-365-Admin-Oberfläche integriert. Die scheinbar naheliegende Wahl.
Aber dieses native Microsoft-Werkzeug erzeugt dasselbe Datumsproblem wie Drittanbieter-Migrationswerkzeuge. Nach einem IMAP-Import über das Exchange Admin Center zeigt jede migrierte E-Mail das Migrationsdatum statt des ursprünglichen Empfangsdatums. Benutzer öffnen Outlook und stellen fest, dass Jahre an E-Mail-Verlauf am selben Tag angekommen zu sein scheinen. Es ist Microsofts eigenes Werkzeug, das die Daten im E-Mail-Client von Microsoft kaputtmacht.
Wie der Exchange-IMAP-Import Datumsprobleme verursacht
Der Importprozess
Der IMAP-Import des Exchange Admin Centers funktioniert, indem er sich mit dem IMAP-Quellserver verbindet, jede E-Mail herunterlädt und sie in das Exchange-Online-Zielpostfach einfügt. Während dieses Einfügens behandelt Exchange Online jede importierte E-Mail als neue Zustellung und fügt Transportheader hinzu, einschließlich eines "Received"-Headers mit dem aktuellen Zeitstempel - dem Importdatum.
Der von Exchange Online hinzugefügte "Received"-Header
Wenn Exchange Online eine Nachricht empfängt (ob durch normale Zustellung oder IMAP-Import), fügt es "Received"-Header hinzu, die den Weg der Nachricht durch die Microsoft-Transportinfrastruktur dokumentieren. Diese Header enthalten Zeitstempel, die den Zeitpunkt widerspiegeln, zu dem Exchange Online die Nachricht verarbeitet hat. Für importierte E-Mails entsprechen diese Zeitstempel dem Datum und der Uhrzeit des Importvorgangs, nicht dem ursprünglichen Zustelldatum.
Ein typischer von Exchange beim IMAP-Import hinzugefügter "Received"-Header sieht so aus:
Received: from BN6PR01MB1234.prod.exchangelabs.com
by BN6PR01MB5678.prod.exchangelabs.com with HTTPS;
Mon, 15 Jan 2024 08:30:45 +0000Dieser Header wird oben in die Header-Kette platziert und wird damit zum neuesten "Received". Outlook liest diesen Header, um das Empfangsdatum zu bestimmen, und zeigt für jede migrierte E-Mail das Importdatum an.
Warum Microsofts eigenes Werkzeug dieses Problem hat
Es klingt absurd, dass Microsofts Migrationswerkzeug ein Datumsanzeigeproblem in Microsofts E-Mail-Client verursacht. Aber die Erklärung ist logisch: Der IMAP-Import zeichnet korrekt auf, wann er die Nachricht verarbeitet hat (eine Anforderung der E-Mail-Transportstandards), und Outlook liest korrekt den neuesten "Received"-Header, um das Empfangsdatum zu bestimmen (Standard-Client-Verhalten). Die Kombination dieser beiden korrekten Verhaltensweisen erzeugt für migrierte E-Mails ein falsches Ergebnis. Zwei richtige Dinge, die zusammen ein falsches Ergebnis ergeben. Für die vollständige technische Erklärung siehe Warum E-Mails nach der Migration falsche Daten zeigen.
Die Konfiguration des IMAP-Imports verhindert das Problem nicht
Exchange Admin Center-Einstellungen
Der IMAP-Import des Exchange Admin Centers bietet Konfigurationsoptionen für Ordnerzuordnung, Elementfilterung und Migrationschargen-Planung. Aber keine dieser Optionen steuert, wie Exchange Online "Received"-Header beim Import behandelt. Kein Kontrollkästchen "Originaldaten beibehalten". Keine Einstellung, die Exchange am Hinzufügen von Transportheadern hindert. Das Datumsproblem ist eine Folge der E-Mail-Transportarchitektur, nicht eine fehlende Konfigurationsoption.
PowerShell-Migrations-Cmdlets
Administratoren, die die PowerShell-Cmdlets (New-MigrationBatch, New-MoveRequest) für die IMAP-Migration verwenden, haben Zugriff auf zusätzliche Parameter, aber keiner davon verhindert das Hinzufügen des "Received"-Headers. Das Cmdlet Start-MigrationBatch und verwandte Befehle steuern den Migrationsprozess, nicht das E-Mail-Transportverhalten von Exchange Online. Selbst bei sorgfältigster PowerShell-Konfiguration werden importierte E-Mails das Migrationsdatum als Empfangsdatum in Outlook haben.
Die Auswirkung auf Outlook und OWA
Outlook Desktop
Outlook Desktop ist der am stärksten betroffene Client. Die Standardansicht sortiert E-Mails nach "Empfangsdatum", das für jede migrierte Nachricht den Importzeitstempel anzeigt. Benutzer, die sich auf Suche, Sortierung und Filterung nach Datum stützen, sehen ihren Arbeitsablauf komplett gestört. Ein Posteingang mit fünf Jahren Korrespondenz erscheint so, als wäre alles am selben Tag angekommen. Wie findet man die wichtige E-Mail von 2021, wenn jede Nachricht behauptet, im Januar 2024 angekommen zu sein?
Outlook im Web (OWA)
OWA zeigt dieselben falschen Daten wie Outlook Desktop. Anders als die Gmail-Weboberfläche (die manchmal den "Date"-Header liest) verwendet OWA konsequent den Exchange-Zustellzeitstempel. Keine OWA-Einstellung oder Anzeigeoption zeigt das Originaldatum statt des Importdatums.
Outlook Mobil
Outlook Mobil (iOS und Android) zeigt ebenfalls das Importdatum. Das Problem ist über alle Outlook-Plattformen konsistent, da sie alle denselben Datumswert aus Exchange Online lesen. Für eine vollständige Anleitung zu Outlook-spezifischen Datumsproblemen siehe Falsche Outlook-Daten nach Migration korrigieren.
Gängige Behelfslösungen (und warum sie versagen)
Nach "Sendedatum" sortieren
Die am häufigsten vorgeschlagene Behelfslösung ist, die Outlook-Ansicht auf Sortierung nach "Sendedatum" statt "Empfangsdatum" umzustellen. Das ändert zwar die Anzeigereihenfolge, korrigiert aber nicht die zugrundeliegenden Daten. Das "Empfangsdatum" bleibt in Suchergebnissen, Regeln, Compliance-Werkzeugen und jeder anderen Funktion falsch, die den Empfangszeitstempel referenziert. Und diese Behelfslösung erfordert, dass jeder Benutzer seine Einstellungen auf jedem Gerät ändert.
IMAP-Import erneut ausführen
Das erneute Importieren der E-Mails korrigiert das Datumsproblem nicht. Ein zweiter Import fügt einen weiteren Satz "Received"-Header mit einem neuen Zeitstempel hinzu und verkompliziert die Header-Kette weiter, ohne das angezeigte Datum zu korrigieren. Der Reimport kann auch Duplikate erzeugen, wenn das Werkzeug die Deduplizierung nicht korrekt handhabt.
Ein anderes Migrationswerkzeug verwenden
Der Wechsel zu einem Drittanbieter-Werkzeug (BitTitan MigrationWiz, CloudM oder imapsync) löst das Datumsproblem nicht. Jedes Werkzeug, das E-Mails in Exchange Online einfügt, löst dasselbe Transportheader-Verhalten aus. Das Problem liegt daran, wie Exchange Online eingehende Nachrichten behandelt, nicht am Migrationswerkzeug selbst. Für einen Vergleich aller Korrekturoptionen siehe Können E-Mail-Daten nach der Migration korrigiert werden.
Exchange-IMAP-Importdaten mit Redate.io korrigieren
Wie Redate.io Exchange-Import-Header identifiziert
Redate.io verbindet sich mit Exchange Online und leitet jede E-Mail durch seine proprietäre mehrstufige Analyse-Pipeline. Für Exchange-IMAP-Importe führt Redate.io einen Signaturabgleich mit Hunderten bekannter Signaturen durch, einschließlich Exchange-Online-Transportinfrastruktur-Muster (wie "prod.exchangelabs.com"), um genau zu identifizieren, welche "Received"-Header beim Import hinzugefügt wurden und welche zur ursprünglichen Zustellkette gehören.
Was Redate.io liefert
Nach der Verarbeitung zeigt jede korrigierte E-Mail ihr ursprüngliches Empfangsdatum in Outlook, OWA und allen verbundenen Clients. Die chronologische Ordnung ist wiederhergestellt. Jede Korrektur durchläuft eine Integritätsprüfung vor der Finalisierung, und die Originale werden 30 Tage in einem Ordner "Redate.io - Originals" aufbewahrt. Die Korrektur-Engine behandelt die Sonderfälle, die handwerkliche Ansätze riskant machen: S/MIME-signierte Nachrichten, PGP-verschlüsselte Inhalte, Multipart-MIME-Strukturen mit verschachtelten Grenzen, Encoding-Variationen und beschädigte MIME-Grenzen. Ehrlich gesagt ist es weit mehr als ein simples Suchen-und-Ersetzen von Header-Text.
Verbindung zu Exchange Online
Redate.io verbindet sich über eine Azure-AD-App-Registrierung (Entra ID) mit OAuth2-Authentifizierung mit Exchange Online. Der Administrator erstellt eine App-Registrierung, gewährt die Mail.ReadWrite-Berechtigungen und erteilt die Administratoreinwilligung. Keine Benutzerpasswörter erforderlich. Die Einrichtung dauert etwa 15 Minuten und folgt denselben Mustern, die andere Microsoft-zertifizierte Anwendungen verwenden.
Plattformspezifische Anleitungen
Häufig gestellte Fragen
Ist das ein bekanntes Problem bei Microsoft?
Microsoft dokumentiert dieses Problem nicht offiziell als bekannten Defekt des IMAP-Imports im Exchange Admin Center. Supporttickets zu diesem Datumsproblem erhalten in der Regel Behelfslösungsvorschläge (nach Sendedatum sortieren) statt einer Korrektur. Das Problem ist eine Folge des Standard-Exchange-Transportverhaltens, kein Bug in der Importfunktion.
Kann PowerShell die Daten nach dem Import korrigieren?
Nein. Exchange Online PowerShell stellt keine Cmdlets zum Ändern des Rohinhalts bestehender Nachrichten bereit. Die Set-Mailbox- und verwandten Cmdlets steuern die Postfachkonfiguration, nicht die Header einzelner Nachrichten. Die Korrektur erfordert die Arbeit auf einer Ebene, die PowerShell für Exchange Online schlicht nicht freigibt.
Funktioniert Redate.io mit Exchange-Hybrid-Umgebungen?
Ja. Redate.io funktioniert mit jedem in Exchange Online gehosteten Postfach, unabhängig davon, ob die Organisation eine Exchange-Hybrid-Konfiguration verwendet oder nicht. Die Korrektur wird auf das Exchange-Online-Postfach angewendet und erfordert keinen Zugriff auf lokale Exchange-Server.
Exchange-IMAP-Import hat die Daten aller E-Mails verfälscht? Starten Sie eine kostenlose Analyse mit Redate.io, um betroffene E-Mails in jedem Postfach zu identifizieren und die korrekten Daten in Outlook, OWA und allen verbundenen Clients wiederherzustellen.