GSMMO rikkus e-kirjade kuupäevad? Kuidas parandada

GSMMO ja kuupäevaprobleem, millest keegi ei hoiata

Google Workspace Migration for Microsoft Outlook (GSMMO) on töölauarakendus, mille Google pakub PST-failide, Outlooki profiilide ja kohalike e-posti arhiivide migreerimiseks Gmaili. See on tasuta, ametlikult toetatud ja on migratsioonitee, mida Google soovitab, kui viite väikese meeskonna või mõne üksiku postkasti Outlookist üle Google Workspace'i.

Tööriist toimib. E-kirjad jõuavad Gmaili, kaustade struktuur seotakse siltidega, kontaktid tulevad läbi. Aga avage Gmail pärast seda ja sorteerige kuupäeva järgi. Iga e-kiri näitab tänast kuupäeva. See pakkumine, mille saatsite 2021. aasta jaanuaris, kannab nüüd kuupäeva aprill 2026. Arve raamatupidajalt 2023. aasta märtsist kannab samuti kuupäeva aprill 2026.

GSMMO ei hoiata teid, et see juhtub. Migratsiooni logi näitab õnnestumist iga sõnumi kohta. Google'i enda dokumentatsioon ei maini seda tuntud piiranguna. Selle avastate ainult siis, kui keegi otsib vana e-kirja kuupäevavahemiku järgi ja saab null tulemust.

Kuidas GSMMO teie e-kirjad tegelikult üles laadib

GSMMO loeb sõnumeid PST-failist (või otse Outlooki profiilist) ja laadib need Gmaili üles Gmail API kaudu (seda kinnitavad Google'i enda tööriista väljalaskemärkmed). Siin saab kuupäevaprobleem alguse, ja mehhanismi mõistmine on oluline, kuna see selgitab, miks parandus ei ole nii lihtne kui "impordi lihtsalt uuesti".

Kui GSMMO laadib sõnumi üles Gmail API kaudu, lisab Gmail värske Received: päise, mis on dateeritud üleslaadimise hetkega. Ja kui algset kuupäeva sõnumiga kaasa ei antud, seatakse INTERNALDATE, mis on Gmaili sisemine ajatempel sortimiseks ja kuvamiseks, üleslaadimise hetkele, mitte algsele saatmiskuupäevale.

Nii näeb päiste ahel välja pärast GSMMO migratsiooni:

Received: by 2002:a05:6512:3ca2:0:0:0:0 with SMTP id
    bi34csp1847206lfb; Sun, 5 Apr 2026 03:17:42 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1])
    by gmailapi.google.com; Sun, 05 Apr 2026 10:17:41 +0000
Date: Wed, 18 Sep 2019 14:33:07 +0200

Näete seda algset Date: päist 2019. aasta septembrist? See on endiselt seal, puutumata. GSMMO ei muuda sõnumi sisu ega algseid päiseid. Aga Gmail ignoreerib seda kuvamise eesmärgil ja kasutab selle asemel INTERNALDATE-t, mis nüüd näitab aprill 2026.

GSMMO vs administraatoripoolsed migratsioonitööriistad

Siit saab segadus tavaliselt alguse. Google'il on mitu migratsioonitööriista ja need kõik ei käitu ühtemoodi.

GSMMO (töölauarakendus) töötab kasutaja arvutis. See loeb Outlookist või PST-failist ja laadib e-kirjad üles Gmail API kaudu. Kasutajal peab olema Google Workspace'i konto ja GSMMO pistikprogramm Outlooki paigaldatud. See on kliendipoolne tööriist.

Google Workspace Migration Service (administraatorikonsooli tööriist) on serveripoolne. Administraator seadistab selle Google Admin Console'is, suunab selle Exchange serverile või teisele Google Workspace'i organisatsioonile, ja migratsioon toimub Google'i infrastruktuuris. Sellel tööriistal on mõnes konfiguratsioonis pisut parem kuupäevade käsitlemine, kuna see saab seada INTERNALDATE-i lähtemetaandmete põhjal. Aga "pisut parem" ei tähenda "usaldusväärne", ja paljud administraatorid kirjeldavad sama kuupäevaprobleemi ka selle tööriistaga.

Mis on peamine erinevus? GSMMO puhul puudub serveripoolne loogika, mis teeks otsuseid kuupäevade säilitamise kohta. Iga sõnum, mille see üles laadib, saab sama kohtlemise, olgu see värske e-kiri või 10 aasta vanune arhiveeritud sõnum: Received: päise, mis on dateeritud üleslaadimise päevaga. Ja punkt.

Miks GSMMO kuupäevade säilitamine ei toimi

Kui olete vaadanud GSMMO seadeid, olete võib-olla märganud, et tegelikult ei ole valikut "säilita kuupäevad". See ei ole tähelepanematus. GSMMO tugineb sellele, kuidas Gmail käsitleb selle API kaudu üles laaditud sõnumeid, ja ei saa seda ümber kirjutada.

Siin on tehniline sündmuste ahel:

1. GSMMO loeb sõnumi PST-failist, kaasa arvatud selle algsed ajatemplid
2. GSMMO laadib sõnumi andmed üles Gmail API kaudu
3. Gmail võtab üleslaadimise vastu ja salvestab sõnumi postkasti
4. Gmail lisab uue Received: päise, mis on dateeritud üleslaadimise hetkega (ülal näites gmailapi.google.com rida)
5. Kui algset kuupäeva kaasa ei antud, seab Gmail INTERNALDATE-i üleslaadimise ajatemplile
6. Sõnum jõuab Gmaili tänase kuupäevaga

Sammud 4 ja 5 on kriitilised. Gmail lisab selle päise igale sõnumile, mis laaditakse üles selle API kaudu, olenemata sellest, mida tööriist saadab, ja GSMMO-l puudub seade algse kuupäeva edastamiseks või säilitamiseks. Tulemus on, et kõik teie ajaloolised e-kirjad näevad välja, nagu need saabuksid täna.

Mõned administraatorid on proovinud käivitada GSMMO-t konkreetsete Google Workspace'i seadetega või kohandada GSMMO profiili seadeid. Mitte ükski neist ei mõjuta kuupäevakäitumist. Received: päis lisatakse Google'i poolel ja mitte ükski kliendipoolne seadistus seda ei muuda.

Konkreetsed GSMMO stsenaariumid, mis rikuvad kuupäevi

Mitte iga GSMMO migratsioon ei lõpe kuupäevade segadusega, kuigi enamik lõppeb just sellega. Siin on, kus see loeb:

• PST-fail Gmaili: Kuupäevad riknevad. See on kõige levinum GSMMO kasutusjuht ja kõige rohkem mõjutatud.
• Outlooki profiil Gmaili: Kuupäevad riknevad. Sama Gmail API üleslaadimine kui PST importimisel.
• Exchange Online (Microsoft 365) Gmaili GSMMO kaudu: Kuupäevad riknevad. GSMMO loeb Exchange serverist ja laadib üles Gmail API kaudu.
• Kohapealne Exchange Gmaili GSMMO kaudu: Kuupäevad riknevad. Sama mehhanism.
• Gmailist Gmaili (PST ekspordi uuesti importimine): Kuupäevad riknevad. Isegi kui algsetel e-kirjadel olid PST-failis õiged kuupäevad, märgib uuesti importimine need värskelt.

Muster on selge. Iga sõnum, mis laaditakse üles Gmail API kaudu, saab Received: päise, mis on dateeritud üleslaadimise päevaga. GSMMO kasutab alati seda teed.

Mis teeb selle eriti masendavaks, on see, et GSMMO migratsiooniraport näitab kõike õnnestununa. Ei mingeid hoiatusi kuupäevade kohta, ei mingeid tõrkeid, ei mingeid lippe. Peaksite käsitsi võrdlema ajatempleid enne ja pärast migratsiooni, et seda märgata, ja enamik administraatoreid ei tee seda enne, kui kasutaja kaebab.

Mõju ületab sortimist

Valed kuupäevad pärast GSMMO migratsiooni tekitavad reaalseid probleeme, mis ulatuvad korrast ära postkastist kaugemale.

Kujutage ette, et olete raamatupidaja, kes just läks üle Google Workspace'ile. Peate leidma kogu kliendikirjavahetuse 2024. aasta kolmandast kvartalist maksudeklaratsiooni jaoks. Otsite Gmailist kuupäevavahemiku järgi: juuli kuni september 2024. Null tulemust. Iga sellest perioodist pärit e-kiri näitab nüüd migratsiooni kuupäeva, nii et Gmaili kuupäevafilter ei leia neid. Olete kimpus, sirvides tuhandeid sõnumeid, või otsite märksõna järgi ja loodate, et mäletate õiget terminit.

Reguleeritud tööstusharude jaoks on see ebamugavusest hullem. E-kirjade ajatemplid toimivad õigusliku tõendina. Finantsnõustaja, kes peab tõestama, et saatis avalduse enne tehingu kuupäeva, ei saa seda teha, kui e-kiri näitab aprilli 2026, mitte veebruari 2023. SOX-il või HIPAA-l põhinevad vastavuskontrollid tuginevad täpsetele suhtluse ajatemplitele, ja valed kuupäevad tähendavad ebaõnnestunud auditeid.

Ja siis on veel lõimeprobleem. Gmail rühmitab vestlusi kuupäeva ja teema järgi. Kui iga sõnum lõimes näitab sama kuupäeva, muutub vestluse vaade sassiseks. Vastused ilmuvad enne algset sõnumit. Kogu lõime struktuur variseb kokku identsete kuupäevadega e-kirjade hunnikuks.

GSMMO kuupäevade parandamine Redate.io-ga

Hea uudis: see algne Date: päis on endiselt puutumata igas migreeritud e-kirjas. GSMMO ei muuda sõnumi sisu. Õige kuupäev on olemas, seda lihtsalt ignoreeritakse Gmaili kuvamisloogika poolt, kuna INTERNALDATE ja ülemine Received päis viitavad migratsiooni kuupäevale.

Redate.io ühendub Google Workspace'i postkastiga, skannib GSMMO migratsioonist mõjutatud e-kirju ja parandab kuupäeva metaandmed, kasutades Redate'i välja töötatud päiste ahela analüüsi ja kuupäevade taastamise mootorit. Redate ei pea teadma, milline tööriist migratsiooni teostas: see leiab e-kirjad, mille kuvatav kuupäev ei vasta nende algsele kuupäevale, ja parandab need sõnumi sisu, manuseid või lõime muutmata.

Iga parandatud e-kiri läbib individuaalse kontrolli: sõnumi terviklikkuse, manuste säilimise, siltide vastendamise ja lõime järjepidevuse. Originaalid jäävad nähtavasse Redate.io - Originals varukoopia kausta teie oma postkastis, kuni te need ise kustutate.

Saaksite selle ise skriptiga parandada? Probleemi mõistmine on üks asi. 12 000 e-kirja parandamine, murdmata S/MIME allkirju, rikkumata pesastatud MIME osi või rikkumata RFC 2047 kodeeritud päiseid üle terve tootmispostkasti, on hoopis teine asi. Kuidas käsitlete e-kirja, millel on 38 MB manus ja rikutud MIME piir, mille GSMMO importis, aga vaevu koos hoidis? Kuidas kontrollite, et iga üksik sõnum jõudis terviklikult kohale? Skript, mis töötab 20 testsõnumiga laboris, ei jää ellu tegelikus postkastis 8 aasta pikkuse kirjavahetusega.

Platvormipõhised juhendid GSMMO jaoks

Kuna GSMMO migreerib konkreetselt Google Workspace'i, toimub parandus Gmaili tasemel. Aga mõjutatud e-kirjad on nähtavad kõikides klientides, mis on selle Gmaili kontoga ühendatud:

• Parandage GSMMO migratsiooni kuupäevad Gmailis
• Parandage GSMMO migratsiooni kuupäevad Outlookis (ühendatud Google Workspace'iga)
• Parandage GSMMO migratsiooni kuupäevad Apple Mailis

Migreerisite juba kuid tagasi? Algne Date: päis ei vanane ajaga. Redate.io saab parandada GSMMO-st mõjutatud e-kirju, olenemata sellest, kas migratsioon toimus eelmisel nädalal või kolm aastat tagasi.

GSMMO migratsioon jättis teie e-kirjad valede kuupäevadega? Käivitage tasuta skannimine, et näha mõjutatud e-kirjade täpset arvu ja parandamise hinda, enne kui te millekski kohustute.