Ret CloudM-migreringsdatoer i Microsoft 365
Hvorfor CloudM-migreringer viser forkert dato i Microsoft 365
CloudM Migrate bruges almindeligt til at migrere postkasser fra Google Workspace, on-premises Exchange og andre platforme til Microsoft 365. Når CloudM uploader e-mails til Microsoft 365, behandler Exchange Onlines transportpipeline hver besked og tilføjer en Received-header med det aktuelle uploadtidsstempel. Denne bliver den nyeste Received-header i beskedens header-kæde.
Microsoft 365 bruger dette leveringstidsstempel på tværs af hele sit økosystem. Outlook desktop, Outlook på nettet, Outlook mobil og endda Microsofts AI-drevne funktioner refererer alle til den samme PR_MESSAGE_DELIVERY_TIME-egenskab, som sættes fra migrerings-Received-headeren. I modsætning til Google Workspace (hvor webklienten kan maskere problemet) viser Microsoft 365 migreringsdatoen konsekvent på tværs af alle sine klientapplikationer.
Konsistensen af den forkerte dato på tværs af alle Microsoft 365-klienter gør problemet øjeblikkeligt synligt for hver bruger. Efter en CloudM-migrering til Microsoft 365 ser hele organisationen det samme symptom: hver e-mail i hver postkasse ser ud til at være modtaget på migreringsdatoen. Der er ingen klientspecifik løsning; datokorruptionen er indlejret i beskedens metadata på serverniveau.
Hvordan dette påvirker Microsoft 365
Microsoft 365's ensartede datohåndtering betyder, at migreringsdatoen vises overalt samtidigt. Outlook desktop, OWA, Outlook mobil, Teams e-mailintegration og Microsoft Search viser alle den forkerte modtagelsesdato. Brugere kan ikke undgå de forkerte datoer ved at skifte til en anden Microsoft 365-applikation.
For Microsoft 365-administratorer strækker virkningen sig til administrations- og compliance-værktøjer. Exchange Admin Center, Microsoft Purview (tidligere Compliance Center) og eDiscovery Premium indekserer alle beskeder efter den beskadigede leveringsdato. Indholdssøgninger efter e-mails inden for et bestemt datointerval returnerer forkerte resultater. Opbevaringslabels der automatisk anvendes baseret på beskedens alder opererer på den forkerte tidslinje, hvilket potentielt forårsager for tidlig sletning eller ubegrænset opbevaring af beskeder der burde have været håndteret anderledes.
Ofte stillede spørgsmål
Tilbyder CloudM en mulighed for at forhindre datokorruption under M365-migrering?
CloudM bevarer den originale Date-header, men destinationsserveren (Exchange Online) tilføjer sin egen Received-header under beskedupload. Dette er serversidig adfærd som migreringsværktøjer ikke kan forhindre. Den eneste løsning er at rette datoerne efter migreringen.
Kan Microsoft 365-administrationsværktøjer rette datoerne?
Nej. Microsoft 365 leverer ikke indbyggede værktøjer til at ændre Received-headers eller leveringstiden for eksisterende beskeder. Redate.io er designet specifikt til dette problem: det fjerner migrerings-headeren og genindsætter e-mailen med den korrekte INTERNALDATE.
Er rettelsen permanent i Microsoft 365?
Ja. Når Redate.io retter e-mailen, flyttes den originale besked (med den forkerte dato) til et backup-label. Den rettede besked har de korrekte Received-headers og INTERNALDATE, og Microsoft 365 indekserer den korrekte dato fremover.