Corriger les dates de migration imapsync dans Microsoft 365
Pourquoi les migrations imapsync affichent la mauvaise date dans Microsoft 365
Les migrations imapsync vers Microsoft 365 (Exchange Online) font face à un double défi pour la préservation des dates. Premièrement, la passerelle IMAP d'Exchange Online a des comportements spécifiques qui peuvent écraser l'INTERNALDATE fournie par le drapeau --syncinternaldates d'imapsync. Deuxièmement, Exchange Online ajoute son propre en-tête Received lors du processus IMAP APPEND, horodatant chaque message avec le moment de la migration.
L'implémentation IMAP de Microsoft 365 est limitée par rapport aux protocoles Exchange complets (EWS, MAPI). Lorsqu'imapsync transfère via IMAP, le message passe par le pipeline de transport d'Exchange Online, qui le traite de manière similaire à un nouveau message entrant. Ce pipeline ajoute des en-têtes de transport, effectue des vérifications de conformité et horodate le message avec des métadonnées de livraison reflétant la date réelle du transfert plutôt que l'INTERNALDATE demandée.
Les administrateurs qui choisissent imapsync pour les migrations Microsoft 365 (souvent parce qu'il est gratuit et scriptable) découvrent après la migration que la préservation des dates n'a pas fonctionné comme prévu. Le drapeau --syncinternaldates, qui fonctionne correctement avec de nombreux serveurs IMAP standard, ne produit pas les résultats attendus avec l'implémentation IMAP particulière d'Exchange Online. L'intégralité de la boîte aux lettres migrée affiche la date de migration dans tous les clients Microsoft 365.
Comment cela affecte Microsoft 365
Dans Microsoft 365, la date de migration apparaît uniformément dans Outlook bureau, OWA, Outlook mobile et Microsoft Search. Contrairement à Gmail (où le client web peut masquer le problème), les clients Microsoft 365 référencent tous le même horodatage de livraison. Les utilisateurs n'ont aucune solution de contournement et aucun client affichant la date correcte tant que les en-têtes Received et l'INTERNALDATE sous-jacentes ne sont pas corrigés au niveau du serveur.
Les fonctionnalités administratives et de conformité de Microsoft 365 sont également affectées. Exchange Online Protection, les stratégies de prévention des pertes de données et les recherches de conformité Microsoft Purview indexent toutes l'horodatage de migration. Pour les organisations soumises à des réglementations de conservation des données, les dates corrompues signifient que les stratégies de rétention basées sur l'ancienneté des messages fonctionnent sur des données incorrectes, pouvant entraîner la suppression prématurée de messages à conserver ou la conservation indéfinie de messages à purger.
Questions fréquemment posées
Pourquoi imapsync --syncinternaldates échoue-t-il avec Microsoft 365 ?
L'implémentation IMAP d'Exchange Online traite les messages transférés à travers son pipeline de transport, qui peut écraser l'INTERNALDATE demandée. De plus, Exchange Online ajoute des en-têtes Received portant l'horodatage du transfert. Ces comportements côté serveur échappent au contrôle d'imapsync.
Aurait-il fallu utiliser un autre outil de migration pour Microsoft 365 ?
La plupart des outils de migration (y compris les solutions commerciales comme BitTitan et CloudM) produisent le même problème de dates car la cause est dans la manière dont Exchange Online traite les messages transférés. Le choix de l'outil de migration ne prévient pas le problème. Redate.io le corrige quel que soit l'outil utilisé.
Redate.io peut-il corriger en masse les boîtes aux lettres migrées avec imapsync ?
Oui. Redate.io prend en charge le traitement en masse des boîtes aux lettres pour Microsoft 365. Les administrateurs peuvent analyser et corriger plusieurs boîtes aux lettres depuis un tableau de bord unique. Le plan Enterprise prend en charge jusqu'à 100 000 e-mails par boîte aux lettres.