Datų problema po „Google Workspace" migracijos
Organizacijos, migruojančios į „Google Workspace", dažnai padaro nemalonų atradimą: visi el. laiškai visose pašto dėžutėse rodo klaidingą datą. Vietoj originalios išsiuntimo ar gavimo datos kiekvienas pranešimas rodo datą, kada buvo atlikta migracija. Nesvarbu, ar organizacija migravo iš „Microsoft Exchange", „Office 365", „Zimbra", „Lotus Notes" ar kito IMAP serverio. Tūkstančiai el. laiškų, visi su viena ir ta pačia data.
Ir tai nėra būdinga konkrečiam migracijos įrankiui. Problema kyla su BitTitan MigrationWiz, CloudM Migrate, GSMMO, imapsync ir visais kitais įrankiais, kurie įterpia el. laiškus į „Google Workspace" per IMAP ar „Gmail" API. Priežastis susijusi su esminiu el. pašto serverių pranešimų apdorojimo mechanizmu.
Konkrečiam GSMMO (Google Workspace Migration for Microsoft Outlook) įrankio vadovui žr. straipsnį, skirtą GSMMO.
Dažni migracijos keliai į „Google Workspace"
Iš vietinio „Microsoft Exchange"
Organizacijos, naudojančios vietinius „Exchange" serverius (2010, 2013, 2016 ar 2019), migruoja į „Google Workspace" norėdamos sumažinti infrastruktūros kaštus ir pereiti prie debesijos modelio. Šios migracijos paprastai naudoja CloudM, BitTitan MigrationWiz arba GSMMO. Migracijos įrankis prisijungia prie „Exchange", atsisiunčia kiekvieną el. laišką ir įkelia jį į naudotojo „Google Workspace" pašto dėžutę. Kiekvienas įkeltas el. laiškas gauna naują „Received" antraštę su migracijos laiko žyma.
Iš „Microsoft 365" (Office 365)
Migracijos iš „Microsoft 365" į „Google Workspace" dažnos, kai organizacijos keičia ekosisteą. BitTitan MigrationWiz ir CloudM yra populiariausi šio tipo migracijos įrankiai. Procesas ištraukia el. laiškus iš „Exchange Online" ir įterpia juos į „Google Workspace". Ta pati „Received" antraštės problema taikoma: kiekvienas migruotas el. laiškas rodo migracijos datą.
Iš kitų IMAP serverių
Migracijos iš „Zimbra", „Zoho", cPanel prieglobos, Dovecot, Courier ir kitų IMAP serverių į „Google Workspace" naudoja tokius įrankius kaip imapsync, CloudM ar individualius scenarijus. Paskirties vieta („Google Workspace") prideda „Received" antraštę per įterpimo operaciją, nepriklausomai nuo šaltinio platformos. Net migracijos iš kito „Google Workspace" nuomininko sukelia tą pačią problemą.
Kodėl datos sugenda „Google Workspace"
„Gmail" žiniatinklio sąsaja ir IMAP klientai
„Google Workspace" pateikia ypatingą situaciją. „Gmail" žiniatinklio sąsaja paprastai naudoja el. laiško „Date" antraštę datai rodyti, o tai reiškia, kad el. laiškai dažnai rodomi su teisinga data peržiūrint per žiniatinklio sąsają. Tuo tarpu kai ta pati dėžutė pasiekiama per IMAP klientą („Outlook", „Apple Mail", „Thunderbird"), klientas skaito naujausią „Received" antraštę ir rodo migracijos datą.
Šis skirtumas sukelia didelę painiavą. Administratorius, testuojantis migraciją „Gmail" žiniatinklio sąsajoje, mato teisingas datas ir daro išvadą, kad migracija pavyko. Tačiau kai naudotojai prijungia „Outlook" prie savo „Google Workspace" paskyros, jie praneša, kad kiekvienas el. laiškas turi klaidingą datą. Problema tikrai egzistuoja serveryje (antraštėse yra migracijos laiko žyma), bet ji tampa matoma tik tam tikruose klientuose. Kiek administratorių užbaigė migracijos projektą manydami, kad viskas gerai, kad kitą pirmadienį būtų užversti užklausomis?
IMAP INTERNALDATE faktorius
„Google Workspace" saugo INTERNALDATE kiekvienam el. laiškui, nustatytą įterpimo proceso metu. Kai kurie migracijos įrankiai teisingai nustato šią reikšmę į originalią datą, kiti ją palieka ties migracijos data. Tačiau net kai INTERNALDATE teisinga, IMAP klientai, teikiantys pirmenybę „Received" antraštėms (kaip „Outlook"), vis tiek rodo klaidingą datą. Visapusiškas taisymas reikalauja tiek migracijos „Received" antraštės pašalinimo, tiek INTERNALDATE teisingumo patvirtinimo. Techniniam paaiškinimui žr. kodėl el. laiškai rodo klaidingas datas po IMAP migracijos.
„Google Workspace" administravimo parinktys (kurios neveikia)
„Google" administravimo konsolė
„Google" administravimo konsolė siūlo plačius „Google Workspace" valdymo kontrolės elementus, bet neturi jokios funkcijos el. pašto datoms taisyti po migracijos. Jokio masinio antraščių redagavimo įrankio. Jokios datų taisymo priemonės. Jokio būdo modifikuoti esamų el. laiškų INTERNALDATE per administravimo sąsają.
Google Apps Script
„Google Apps Script" gali automatizuoti daugelį „Gmail" operacijų, bet negali modifikuoti neapdorotų el. pašto antraščių. GmailApp ir „Gmail" API paslaugos, prieinamos per Apps Script, leidžia skaityti pranešimus, keisti etiketes ir modifikuoti metaduomenis, bet nepalaiko neapdoroto pranešimo RFC 2822 turinio pakeitimo. Taigi taisymas reikalauja darbo daug gilesniu lygiu nei tas, kurį Apps Script atskleidžia.
„Google" duomenų migracijos paslauga
„Google" duomenų migracijos paslauga (prieinama administravimo konsolėje) skirta el. laiškams migruoti į „Google Workspace", o ne antraštėms taisyti po migracijos. Antros migracijos paleidimas šiuo įrankiu pridėtų papildomą „Received" antraštę, pablogindamas problemą.
„Google Workspace" datų taisymas su Redate.io
Kaip veikia administravimo delegavimas
Redate.io naudoja „Google Workspace" domeno lygio delegavimo funkciją prieigai prie pašto dėžučių. Administratorius sukuria paslaugos paskyrą „Google Cloud Console", suteikia reikiamus „Gmail" API leidimų apimtis ir aktyvuoja domeno lygio delegavimą. Tai leidžia Redate.io apdoroti bet kurią organizacijos pašto dėžutę be individualių naudotojų kredencialų.
Delegavimo konfigūracija užtrunka maždaug 10 minučių ir seka tą patį procesą kaip ir kiti „Google Workspace" migracijos ir valdymo įrankiai. Sukonfigūravus, administratorius gali analizuoti ir taisyti bet kokį skaičių dėžučių iš Redate.io valdymo skydelio.
Darbo pradžia
Sukurti paslaugos paskyrą. „Google Cloud Console" sukurkite naują projektą (arba naudokite esamą), aktyvuokite „Gmail" API ir sukurkite paslaugos paskyrą su aktyvuotu domeno lygio delegavimu.
Suteikti API leidimų apimtis. „Google Workspace" administravimo konsolėje eikite į Sauga, tada API kontrolės, tada Domeno lygio delegavimas. Pridėkite paslaugos paskyros kliento ID ir suteikite Redate.io reikalaujamas „Gmail" API leidimų apimtis.
Prisijungti Redate.io. Prisijunkite prie Redate.io, pasirinkite „Google Workspace" kaip platformą ir įkelkite paslaugos paskyros JSON rakto failą. Redate.io patvirtina prisijungimą ir pateikia prieinamų dėžučių sąrašą.
Analizuoti dėžutes. Pasirinkite analizuotinas dėžutes (arba analizuokite visas). Nemokama analizė identifikuoja kiekvienoje dėžutėje esančių el. laiškų su klaidingomis datomis skaičių. Jokio mokėjimo analizei nereikia.
Taisyti. Peržiūrėkite analizės rezultatus, pasirinkite planą ir paleiskite taisymą. Redate.io nuosavybinis taisymo variklis apdoroja kiekvieną dėžutę praleisdamas kiekvieną el. laišką per daugiapakopį analizės konvejerį, tvarkantį kodavimo problemas, daugiadales pranešimų struktūras, skaitmeninius parašus ir dešimtis specialių atvejų, kuriuos rankinis scenarijus sugadintų. Eiga matoma realiu laiku. Originalūs pranešimai saugomi etiketėje „Redate.io - Originals" 30 dienų.
Po taisymo
Redate.io atlikus taisymą, el. laiškai rodo teisingą datą visuose klientuose: „Gmail" žiniatinklyje, „Outlook", „Apple Mail", „Thunderbird" ir bet kurioje kitoje IMAP prijungtoje programoje. Taisymas yra nuolatinis. Jokios nuolatinės priežiūros ar prenumeratos nereikia. Naudotojai gali rūšiuoti pagal datą, ieškoti pagal datų intervalą ir naudoti atitikties įrankius pasitikėdami laiko žymų tikslumu. Pašto dėžutė veikia taip, kaip turėjo veikti nuo pat pirmos dienos.
Įrankiams skirti vadovai „Google Workspace"
Išsamioms instrukcijoms pagal konkretų naudotą migracijos įrankį žr. šiuos vadovus:
- BitTitan MigrationWiz datų taisymas „Google Workspace"
- CloudM migracijos datų taisymas „Google Workspace"
Migracija į „Google Workspace" ir visi el. laiškai rodo klaidingą datą? Paleiskite nemokamą analizę su Redate.io ir sužinokite, kiek el. laiškų paveikta visose dėžutėse, bei atkurkite teisingas datas.