Corriger les dates de migration CloudM dans Microsoft 365
Pourquoi les migrations CloudM affichent la mauvaise date dans Microsoft 365
CloudM Migrate est couramment utilisé pour migrer des boîtes aux lettres depuis Google Workspace, Exchange sur site et d'autres plateformes vers Microsoft 365. Lorsque CloudM transfère les e-mails vers Microsoft 365, le pipeline de transport d'Exchange Online traite chaque message et ajoute un en-tête Received avec l'horodatage actuel du transfert. Celui-ci devient l'en-tête Received le plus récent dans la chaîne d'en-têtes du message.
Microsoft 365 utilise cet horodatage de livraison dans l'ensemble de son écosystème. Outlook bureau, Outlook sur le web, Outlook mobile et même les fonctionnalités d'IA de Microsoft référencent tous la même propriété PR_MESSAGE_DELIVERY_TIME, qui est définie à partir de l'en-tête Received de migration. Contrairement à Google Workspace (où le client web peut masquer le problème), Microsoft 365 affiche la date de migration de manière cohérente dans toutes ses applications clientes.
La cohérence de la mauvaise date dans tous les clients Microsoft 365 rend le problème immédiatement visible pour chaque utilisateur. Après une migration CloudM vers Microsoft 365, l'ensemble de l'organisation constate le même symptôme : chaque e-mail dans chaque boîte aux lettres semble avoir été reçu à la date de migration. Il n'existe aucune solution de contournement spécifique à un client ; la corruption des dates est intégrée dans les métadonnées du message au niveau du serveur.
Comment cela affecte Microsoft 365
La gestion unifiée des dates par Microsoft 365 signifie que la date de migration apparaît partout simultanément. Outlook bureau, OWA, Outlook mobile, l'intégration e-mail dans Teams et Microsoft Search affichent tous la mauvaise date de réception. Les utilisateurs ne peuvent pas échapper aux dates incorrectes en passant à une autre application Microsoft 365.
Pour les administrateurs Microsoft 365, l'impact s'étend aux outils de gestion et de conformité. Le Centre d'administration Exchange, Microsoft Purview (anciennement Centre de conformité) et eDiscovery Premium indexent tous les messages par la date de livraison corrompue. Les recherches de contenu pour les e-mails dans une plage de dates spécifique renvoient des résultats incorrects. Les étiquettes de rétention appliquées automatiquement en fonction de l'ancienneté du message fonctionnent sur la mauvaise chronologie, pouvant entraîner la suppression prématurée de messages qui auraient dû être conservés ou la conservation indéfinie de messages qui auraient dû être purgés.
Questions fréquemment posées
CloudM offre-t-il une option pour éviter la corruption des dates lors de la migration vers M365 ?
CloudM préserve l'en-tête Date original, mais le serveur de destination (Exchange Online) ajoute son propre en-tête Received lors du transfert du message. Il s'agit d'un comportement côté serveur que les outils de migration ne peuvent pas empêcher. La seule solution est de corriger les dates après la migration.
Les outils d'administration Microsoft 365 peuvent-ils corriger les dates ?
Non. Microsoft 365 ne fournit pas d'outils intégrés pour modifier les en-têtes Received ou la date de livraison des messages existants. Redate.io est conçu spécifiquement pour ce problème : il supprime l'en-tête de migration et réinsère l'e-mail avec l'INTERNALDATE correcte.
La correction est-elle permanente dans Microsoft 365 ?
Oui. Une fois que Redate.io a corrigé l'e-mail, le message original (avec la mauvaise date) est déplacé vers un libellé de sauvegarde. Le message corrigé possède les en-têtes Received et l'INTERNALDATE correctes, et Microsoft 365 indexe la bonne date à partir de ce moment.