Vad är CloudM och varför orsakar det datumproblem?
CloudM Migrate (tidigare Cloud Migrator) är en ledande migreringsplattform, specialiserad på Google Workspace-övergångar. IT-administratörer använder CloudM för att flytta brevlådor från Microsoft Exchange, Office 365, Lotus Notes, Zimbra och andra plattformar till Google Workspace. CloudM hanterar även migreringar i motsatt riktning och mellan olika molnbaserade e-postplattformar. Google har själv rekommenderat CloudM som migreringspartner, vilket gör det till ett av de mest betrodda verktygen i Google Workspace-ekosystemet.
Så varför läser du den här artikeln? För att trots CloudMs tillförlitlighet vid dataöverföring producerar verktyget samma frustrerande datumproblem som drabbar praktiskt taget varje e-postmigreringsverktyg. Efter en CloudM-migrering visar varje e-postmeddelande i destinationsbrevlådan migreringsdatumet istället för det ursprungliga mottagningsdatumet. Tusentals e-postmeddelanden, alla stämplade med samma datum. Åratal av kronologisk ordning, förstörd i en enda migreringskörning.
Hur CloudM lägger till huvuden under migreringen
Migreringens "Received"-huvud
När CloudM migrerar ett e-postmeddelande från källplattformen till destinationen behandlar det varje meddelande genom sin migreringspipeline och infogar det i destinationsbrevlådan. Under denna infogning lägger destinationens e-postserver till ett "Received"-huvud på meddelandet. Det huvudet registrerar tidstämpeln för när e-postmeddelandet infogades i den nya servern, alltså migreringsdatumet, inte det ursprungliga leveransdatumet.
Det CloudM-relaterade "Received"-huvudet hamnar längst upp i e-postmeddelandets huvudkedja. Eftersom e-postklienter som Outlook, Apple Mail och Thunderbird bestämmer mottagningsdatumet genom att läsa det översta "Received"-huvudet visar varje migrerat e-postmeddelande migreringens tidstämpel istället för det ursprungliga datumet. Det är kärnan i problemet.
Identifiera CloudM-huvudet
För att bekräfta att ett datumproblem orsakats av CloudM undersöker du de råa huvudena i ett drabbat e-postmeddelande. I Gmail öppnar du e-postmeddelandet, klickar på de tre punkterna och väljer "Visa original". Leta efter "Received"-huvuden nära toppen av meddelandet. CloudMs migreringshuvud innehåller vanligtvis referenser till CloudMs bearbetningsinfrastruktur eller en generisk localhost-post med en tidstämpel som matchar migreringsdatumet.
Den avgörande indikatorn är ett "Received"-huvud vars tidstämpel matchar det kända migreringsdatumet men inte matchar det ursprungliga leveransdatumet. Om det översta "Received"-huvudet visar april 2024 men e-postens "Date"-huvud visar januari 2021 är migreringshuvudet orsaken.
Vanliga CloudM-migreringsscenarier som orsakar datumproblem
Exchange till Google Workspace
Den vanligaste CloudM-migreringssökvägen går från Microsoft Exchange (on-premises eller Exchange Online) till Google Workspace. Organisationer som byter från Microsoft till Google använder CloudM för att överföra brevlådor, kalendrar och kontakter. Varje e-postmeddelande migrerat via denna väg får migreringens "Received"-huvud, vilket orsakar datumvisningsproblem i alla IMAP-klienter som ansluter till Google Workspace-brevlådan.
Office 365 till Google Workspace
Migreringar från Office 365 (Microsoft 365) till Google Workspace följer samma mönster. CloudM extraherar e-postmeddelanden via Microsoft Graph API eller Exchange Web Services och infogar dem i Google Workspace via Gmail API eller IMAP. Infogningssteget lägger till migreringshuvudet, och datumproblemet uppstår så fort migreringen är klar.
Google Workspace till Google Workspace
Även migreringar mellan Google Workspace-tenanter (vanliga vid fusioner, förvärv eller domänbyten) kan ge datumproblemet. CloudM exporterar från en Google Workspace-organisation och importerar till en annan, och destinationsservern lägger till ett "Received"-huvud under importprocessen.
Varför datumproblemet är viktigt för Google Workspace-användare
Google Workspace-användare är särskilt drabbade eftersom många använder sin e-post via flera klienter. Gmails webbgränssnitt visar ofta rätt datum (då det läser "Date"-huvudet), men Outlook, Apple Mail och Thunderbird anslutna till samma konto via IMAP visar migreringsdatumet. Det skapar förvirring när samma e-postmeddelande visas med olika datum beroende på vilken klient som används.
För organisationer som migrerade till Google Workspace för att förbättra produktiviteten underminerar felaktiga e-postdatum hela syftet med migreringen. Användarna tappar förtroendet för den nya plattformen, helpdesk-ärenden hopar sig, och IT-administratörer står inför ett problem de inte hade förutsett och inte enkelt kan lösa. För att bättre förstå problemet, se varför e-post visar fel datum efter IMAP-migrering.
Korrigeringsförsök som inte räcker
Sortera efter "Skickat"-datum
Den vanligaste lösningen är att be användarna sortera efter "Skickat"-datum istället för "Mottaget"-datum. Det ändrar visningsordningen, men det korrigerar inte underliggande data. Sökresultat visar fortfarande felaktiga tidstämplar. Automatiserade arbetsflöden och complianceverktyg som beror på mottagningsdatumet fortsätter att fungera fel. Och användarna måste komma ihåg att ändra inställningen på varje enhet och i varje mapp. Hur stor är chansen att det håller i en organisation med 200 personer?
Kontakta CloudM-supporten
CloudMs supportteam erbjuder ingen datumkorrigering efter migrering. Datumproblemet är en konsekvens av hur IMAP-protokollet hanterar meddelandeinfogning, inte en bugg i CloudMs programvara. CloudM kan inte retroaktivt ta bort de "Received"-huvuden som lades till under migreringen. Verktyget utförde migreringen korrekt, huvudena är det förväntade resultatet av infogningsprocessen.
Använda Google Apps Script
Vissa administratörer försöker korrigera datumen med Google Apps Script. Det verkar smart. Men Google Apps Script ger inte åtkomst till råa e-posthuvuden på den nivå som krävs för att ta bort "Received"-huvuden. Gmail API:ets modify-endpoint kan ändra etiketter och metadata men kan inte ändra det råa RFC 2822-innehållet i meddelandet. I praktiken kräver en fullständig korrigering att arbeta på en mycket djupare nivå än vad Apps Script exponerar.
Korrigera CloudM-migreringsdatum med Redate.io
Hur Redate.io hanterar CloudM-huvuden
Redate.ios proprietära korrigeringsmotor analyserar den fullständiga huvudkedjan i varje e-postmeddelande i brevlådan. För CloudM-migreringar tillämpar Redate.io signaturmatchning mot hundratals profiler från kända migreringsverktyg, inklusive CloudM-specifika mönster, för att exakt identifiera vilka "Received"-huvuden som lades till under migreringen kontra de som är legitima delar av den ursprungliga leveranskedjan.
Men att identifiera rätt huvud är bara början. Korrigeringspipelinen hanterar även kantfall som skulle få ett enkelt skript att snubbla: S/MIME-signerade meddelanden, PGP-krypterat innehåll, multipart MIME-strukturer med nästlade gränser, icke-ASCII-kodade huvuden och korrupta MIME-gränser från själva migreringsprocessen. Det är mycket mer komplext än en sök-och-ersätt på huvudtext.
Vad du får efter korrigeringen
När Redate.io har behandlat brevlådan visar varje korrigerat e-postmeddelande sitt ursprungliga mottagningsdatum i alla e-postklienter, oavsett om det är Outlook, Apple Mail, Thunderbird eller Gmails webbgränssnitt. Den kronologiska ordningen är återställd i varje mapp. Varje korrigering genomgår en integritetskontroll innan slutförande, och originalen bevaras i en synlig mapp "Redate.io - Originals" i 30 dagar.
Admindelegering för Google Workspace
För Google Workspace-organisationer stödjer Redate.io domänövergripande delegering via ett Service Account. IT-administratören ansluter en enda gång, och Redate.io kan behandla alla brevlådor i organisationen utan att kräva individuella användares lösenord. Det är samma delegeringsmodell som CloudM använde för migreringen, vilket gör det bekant för administratörer som redan genomfört CloudM-migreringen.
Plattformsspecifika CloudM-korrigeringsguider
Redate.io tillhandahåller detaljerade guider för varje plattforms- och klientkombination som påverkas av CloudM-migreringar:
- Korrigera CloudM-migreringsdatum i Gmail
- Korrigera CloudM-migreringsdatum i Outlook
- Korrigera CloudM-migreringsdatum i Google Workspace
Vanliga frågor
Har CloudM något alternativ för att förhindra datumproblem?
CloudM försöker bevara INTERNALDATE under migreringen. Däremot tar det "Received"-huvud som läggs till under infogningen över INTERNALDATE i de flesta e-postklienter. Det finns ingen CloudM-konfiguration som förhindrar att detta huvud läggs till, det är ett krav från IMAP-protokollet.
Kan Redate.io korrigera datum för en hel Google Workspace-organisation?
Ja. Via domänövergripande delegering kan Redate.io analysera och korrigera varje brevlåda i en Google Workspace-organisation från en enda adminanslutning. Administratören väljer vilka brevlådor som ska behandlas, och Redate.io hanterar resten.
Är korrigeringen permanent?
Ja. När Redate.io har korrigerat ett e-postmeddelandes datum är korrigeringen permanent. Det korrigerade e-postmeddelandet visar rätt datum i alla e-postklienter i fortsättningen. Ingen prenumeration eller löpande underhåll krävs.
CloudM-migreringen lämnade varje e-postmeddelande med fel datum? Kör en gratis analys med Redate.io för att se exakt hur många e-postmeddelanden som är drabbade och förhandsgranska korrigeringen innan köp.