Datumproblemet efter Google Workspace-migrering
Organisationer som migrerar till Google Workspace gör ofta en obehaglig upptäckt: alla e-postmeddelanden i alla brevlådor visar fel datum. Istället för ursprungligt sänd- eller mottagningsdatum visar varje meddelande datumet då migreringen genomfördes. Det spelar ingen roll om organisationen migrerade från Microsoft Exchange, Office 365, Zimbra, Lotus Notes eller en annan IMAP-server. Tusentals e-postmeddelanden, alla stämplade med ett enda datum.
Och det är inte specifikt för något enskilt migreringsverktyg. Problemet uppstår med BitTitan MigrationWiz, CloudM Migrate, GSMMO, imapsync och alla andra verktyg som infogar e-post i Google Workspace via IMAP eller Gmail API. Orsaken är kopplad till en grundläggande mekanism i hur e-postservrar behandlar meddelanden.
För en guide specifik för GSMMO (Google Workspace Migration for Microsoft Outlook), se den dedikerade GSMMO-artikeln.
Vanliga migreringssökvägar till Google Workspace
Från Microsoft Exchange (on-premises)
Organisationer som driver Exchange-servrar on-premises (2010, 2013, 2016 eller 2019) migrerar till Google Workspace för att minska infrastrukturkostnader och anta en molnmodell. Dessa migreringar använder vanligtvis CloudM, BitTitan MigrationWiz eller GSMMO. Migreringsverktyget ansluter till Exchange, laddar ner varje e-postmeddelande och laddar upp det till användarens Google Workspace-brevlåda. Varje uppladdat e-postmeddelande får ett nytt "Received"-huvud med migreringens tidstämpel.
Från Microsoft 365 (Office 365)
Migreringar från Microsoft 365 till Google Workspace är vanliga när organisationer byter ekosystem. BitTitan MigrationWiz och CloudM är de populäraste verktygen för denna typ av migrering. Processen extraherar e-post från Exchange Online och infogar den i Google Workspace. Samma "Received"-huvudproblem gäller: varje migrerat e-postmeddelande visar migreringsdatumet.
Från andra IMAP-servrar
Migreringar från Zimbra, Zoho, cPanel-hosting, Dovecot, Courier och andra IMAP-servrar till Google Workspace använder verktyg som imapsync, CloudM eller anpassade skript. Destinationen (Google Workspace) lägger till ett "Received"-huvud under infogningsoperationen, oavsett källplattform. Även migreringar från en annan Google Workspace-tenant ger samma problem.
Varför datum går sönder i Google Workspace
Gmails webbgränssnitt kontra IMAP-klienter
Google Workspace presenterar en speciell situation. Gmails webbgränssnitt använder vanligtvis e-postens "Date"-huvud för att visa meddelandedatumet, vilket innebär att e-postmeddelanden ofta visas med rätt datum när de visas via webbgränssnittet. Däremot, när samma brevlåda öppnas via en IMAP-klient (Outlook, Apple Mail, Thunderbird) läser klienten det senaste "Received"-huvudet och visar migreringsdatumet.
Denna skillnad skapar avsevärd förvirring. En administratör som testar migreringen i Gmails webbgränssnitt ser korrekta datum och drar slutsatsen att migreringen lyckades. Men när användarna ansluter Outlook till sitt Google Workspace-konto rapporterar de att varje e-postmeddelande har fel datum. Problemet finns faktiskt på servern (huvudena innehåller migreringens tidstämpel) men blir bara synligt i vissa klienter. Hur många administratörer har avslutat ett migreringsprojekt i tron att allt var bra, bara för att översvämmas av ärenden följande måndag?
IMAP INTERNALDATE-faktorn
Google Workspace lagrar ett INTERNALDATE för varje e-postmeddelande, satt under infogningsprocessen. Vissa migreringsverktyg ställer in det värdet korrekt till ursprungsdatumet, andra lämnar det vid migreringsdatumet. Men även när INTERNALDATE är korrekt visar IMAP-klienter som prioriterar "Received"-huvuden (som Outlook) ändå fel datum. Fullständig korrigering kräver både borttagning av migreringens "Received"-huvud och verifiering att INTERNALDATE är korrekt satt. För en detaljerad teknisk förklaring, se varför e-post visar fel datum efter IMAP-migrering.
Google Workspace-adminalternativ (som inte fungerar)
Google Admin-konsolen
Google Admin-konsolen erbjuder omfattande kontroller för Google Workspace-hantering, men den inkluderar ingen funktion för att korrigera e-postdatum efter migrering. Inget verktyg för massändring av huvuden. Inget datumkorrigeringsverktyg. Inget sätt att ändra INTERNALDATE på befintliga e-postmeddelanden via administrationsgränssnittet.
Google Apps Script
Google Apps Script kan automatisera många Gmail-operationer, men det kan inte ändra råa e-posthuvuden. GmailApp- och Gmail API-tjänsterna som exponeras via Apps Script kan läsa meddelanden, ändra etiketter och modifiera metadata, men de stödjer inte ersättning av det råa RFC 2822-innehållet i ett meddelande. Korrigeringen kräver alltså att arbeta på en mycket djupare nivå än vad Apps Script exponerar.
Googles datamigreringstjänst
Googles datamigreringstjänst (tillgänglig i Admin-konsolen) är avsedd för att migrera e-post till Google Workspace, inte för att korrigera huvuden efter migrering. Att köra en andra migrering med det verktyget skulle lägga till ett ytterligare "Received"-huvud, vilket förvärrar problemet.
Korrigera Google Workspace-datum med Redate.io
Hur admindelegering fungerar
Redate.io använder Google Workspaces domänövergripande delegeringsfunktion för att nå brevlådor. Administratören skapar ett Service Account i Google Cloud Console, beviljar nödvändiga Gmail API-scopes och aktiverar domänövergripande delegering. Det ger Redate.io möjlighet att behandla vilken brevlåda som helst i organisationen utan att kräva individuella användares inloggningsuppgifter.
Delegeringskonfigurationen tar ungefär 10 minuter och följer samma process som andra Google Workspace-migrerings- och hanteringsverktyg. När den är konfigurerad kan administratören analysera och korrigera valfritt antal brevlådor från Redate.io-instrumentpanelen.
Kom igång
Skapa ett Service Account. I Google Cloud Console skapar du ett nytt projekt (eller använder ett befintligt), aktiverar Gmail API och skapar ett Service Account med domänövergripande delegering aktiverad.
Bevilja API-scopes. I Google Workspace Admin-konsolen navigerar du till Säkerhet, sedan API-kontroller, sedan Domänövergripande delegering. Lägg till Service Accountets klient-ID och bevilja de Gmail API-scopes som krävs av Redate.io.
Anslut i Redate.io. Logga in på Redate.io, välj "Google Workspace" som plattform och ladda upp Service Accountets JSON-nyckelfil. Redate.io validerar anslutningen och listar tillgängliga brevlådor.
Analysera brevlådor. Välj brevlådor att analysera (eller analysera alla). Den gratis analysen identifierar antalet e-postmeddelanden med felaktiga datum i varje brevlåda. Ingen betalning krävs för analysen.
Korrigera. Granska analysresultaten, välj en plan och starta korrigeringen. Redate.ios proprietära korrigeringsmotor behandlar varje brevlåda genom att köra varje e-postmeddelande genom en flerstegs analyspipeline som hanterar kodningsproblem, multipart-meddelandestrukturer, digitala signaturer och dussintals specialfall som ett hemmagjort skript skulle korruptera. Framstegen visas i realtid. Ursprungliga meddelanden bevaras i en etikett "Redate.io - Originals" i 30 dagar.
Efter korrigeringen
När korrigeringen är klar visar e-postmeddelandena rätt datum i alla klienter: Gmail-webben, Outlook, Apple Mail, Thunderbird och alla andra IMAP-anslutna appar. Korrigeringen är permanent. Inget löpande underhåll eller prenumeration krävs. Användarna kan sortera efter datum, söka efter datumintervall och använda complianceverktyg med förtroende för tidstämplarnas korrekthet. Brevlådan fungerar som den borde ha gjort från dag ett.
Verktygsspecifika guider för Google Workspace
För detaljerade instruktioner baserade på det specifika migreringsverktyget som användes, se dessa guider:
- Korrigera BitTitan MigrationWiz-datum i Google Workspace
- Korrigera CloudM-migreringsdatum i Google Workspace
Migrering till Google Workspace och alla e-postmeddelanden visar fel datum? Kör en gratis analys med Redate.io för att se hur många e-postmeddelanden som berörs i alla brevlådor och återställ korrekta datum.