Google Workspace migrācija: sabojāti e-pastu datumi

Scenārijs, kuru neviens negaida

Migrācija starp diviem Google Workspace tenantiem ir pabeigta. Uzņēmuma pirkums, domēna maiņa, divu struktūrvienību apvienošana, kas gadiem pastāvēja uz atsevišķiem G Suite kontiem. Viss noritējis gludi, pastkastes ir savās vietās, lietotāji piesakās. Pirmdienas rītā pirmais pieteikums: "Visiem maniem e-pastiem ir vienāds datums." Tad otrs. Tad desmit.

Instinktīvi jūs domājat: noteikti IMAP problēma, nepareizi konfigurēts rīks, kaut kas eksotisks. Ne nu Google uz Google migrācija. Taču tieši tur tas notiek.

Šis scenārijs ir varbūt vissliktāk dokumentētais nozarē. Lielākā daļa IT administratoru, kas to sastop, pavada vairākas stundas, meklējot skaidrojumu pasta klienta pusē, Outlook iestatījumos, konta parametros, pirms saprot, ka problēma slēpjas pašos e-pastu galvenēs.

Kāpēc Google uz Google migrācija sabojā datumus

Lai saprastu, kas notiek, jāatgriežas pie e-pastu galveņu mehānikas. Katrs RFC 2822 ziņojums satur oriģinālo Date: lauku, ko nosūtīšanas brīdī pievieno klients vai sūtītāja serveris. Tas ir e-pasta "īstais" datums, kas atbilst tam, kad ziņojums tika uzrakstīts un nosūtīts.

Bet pastāv arī cits mehānisms: IMAP INTERNALDATE. Tā ir servera pusē glabāta metadatu vērtība, kas norāda, kad ziņojums tika ievietots pastkastē. Un tieši te kļūst interesanti.

Kad migrācijas rīks pārceļ e-pastu no viena Google Workspace tenanta uz otru, tas izmanto IMAP protokolu (pat ja abi serveri ir pie Google). Ziņojums tiek nolasīts no avota, pēc tam atkārtoti ievietots galamērķī. Šīs atkārtotas ievietošanas brīdī galamērķa serveris automātiski pievieno Received: galveni ar operācijas laikspiedolu, tas ir, migrācijas datumu.

Turklāt tādi pasta klienti kā Outlook ziņojuma datuma attēlošanai izmanto pirmo Received: galveni ķēdē, nevis obligāti oriģinālo Date: lauku. Rezultāts: visi e-pasti rāda migrācijas dienas datumu.

Kuri rīki izraisa problēmu

Praktiski visi rīki, ko izmanto Google Workspace starptenanta migrācijām, ir skartie. Nav būtisku izņēmumu:

• GSMMO (Google Workspace Migration for Microsoft Outlook): sākotnēji paredzēts migrācijai no Exchange, bet tiek izmantots dažos GWS uz GWS scenārijos.
• CloudM Migrate: ļoti izplatīts MSP vidū starpGoogle migrācijām, sistemātiski pievieno Received: migrācijas galveni. Skatiet detalizēto CloudM analīzi.
• BitTitan MigrationWiz: tāpat, šī rīka uzvedība ir aplūkota rakstā par BitTitan.
• imapsync: atvērtā pirmkoda rīks, kas ļauj skriptot IMAP migrācijas, tostarp starp diviem Google tenantiem.
• Manuālie eksporti/importi, izmantojot Takeout + IMAP reimports: retāk izmantoti, bet rada precīzi tādu pašu efektu.

Iemesls ir vienkāršs: visi šie rīki darbojas kā standarta IMAP klienti. Tiem nav piekļuves kādai "natīvai" Google ceļam, kas saglabātu metadatus. Pat ja abi tenanti ir pie Google, pārsūtīšana notiek caur IMAP slāni, un šis slānis nezina, ka tas runā pats ar sevi.

Received galveņu mehānika sīkāk

(Starp citu, ja kādreiz esat mēģinājis lasīt e-pasta neapstrādātās galvenes no Gmail vai Outlook, jūs zināt, ka tas reti ir baudāms lasījums. Bet tieši tur slēpjas visa patiesība.)

E-pasts, kas ir normāli ceļojis, satur Received: galveņu ķēdi apgrieztā secībā: serveris, kas ziņojumu apstrādāja pēdējais, atrodas augšā. Pēc migrācijas migrācijas galvene nonāk tieši kaudzes virsotnē.

Lūk, kā tas izskatās ziņojumā, kas migrēts ar CloudM no viena GWS tenanta uz otru:

Received: from mail-migration.cloudm.io (mail-migration.cloudm.io [203.0.113.42])
        by mx.google.com with ESMTPS id xyz123
        for <lietotajs@jaunais-domens.com>
        ; Mon, 14 Oct 2024 09:17:32 +0000 (UTC)
Received: from mail-relay.google.com ...
        ; Tue, 5 Mar 2019 14:22:08 +0000
Date: Tue, 5 Mar 2019 14:22:08 +0000

Lauks Date: rāda 2019. gadu. Pirmā Received: galvene rāda 2024. gada oktobri. Outlook lasa pirmo Received:. Lietotājs redz 2024. gada oktobri 2019. gada e-pastam.

Oriģinālais Date: lauks ir neskarts. Tas nav mainījies. Tā ir labā ziņa: dati ir tur, tie vienkārši gaida, kad tiks pareizi izmantoti.

Outlook un Gmail uzvedas atšķirīgi

Šī ir svarīga nianse. Lietotāji, kas piekļūst e-pastiem caur Gmail tīmekļa saskarni, bieži redz pareizos datumus, jo Gmail prioritāri izmanto RFC 2822 Date: lauku ziņojumu attēlošanai. Tīmekļa pusē problēma ir mazāk pamanāma.

Savukārt lietotāji, kas konfigurē savu Google Workspace pastkasti Outlook, izmantojot IMAP (vai Exchange ActiveSync sinhronizāciju), pilnībā izjūt nepareizo datumu, jo Outlook paļaujas uz IMAP INTERNALDATE, kas atspoguļo migrācijas laikā pievienotās pirmās Received: galvenes datumu.

Precizēsim: Outlook uzvedība atšķiras atkarībā no versijas un savienojuma veida. Outlook 2019 un Microsoft 365 (jaunākās versijas) IMAP savienojumā izmanto INTERNALDATE. Vecākām versijām var būt nedaudz atšķirīga uzvedība. Taču visos ražošanas vidē novērotajos gadījumos GWS uz GWS migrācija caur IMAP Outlook rāda nepareizus datumus.

Tādēļ organizācijās, kas pārcēlās uz jaunu tenantu un uztur hibrīdus lietotājus (daži izmanto Gmail tīmekli, citi Outlook), pieteikumi ir nekonsekventi. IT komandas pavada laiku, mēģinot saprast, kāpēc "daži ir skartie, bet citi ne", lai gan atbilde ir vienkārša: atšķirību rada pasta klients.

Pirkumi, apvienošanās, domēna maiņas: biežākie gadījumi

Šis migrācijas veids nav mazsvarīgs. Lūk, scenāriji, kas rada visvairāk pieteikumu:

Uzņēmuma iegāde

Iegādātajam uzņēmumam bija savs Google Workspace tenants (domēns @vecaisuznemums.com). Pēc pirkuma viss jāpārceļ uz mātes uzņēmuma tenantu (@grupa.com). 250 pastkastes, arhīvi, 8 gadu e-pastu vēsture. BitTitan vai CloudM tiek norīkots operācijai. Rezultāts: 2,4 miljoni e-pastu ar migrācijas nedēļas nogales datumu.

Domēna maiņa

Pārkārtots uzņēmums pāriet no @vecaisnosaukums.lv uz @jaunaissaukums.lv. Tas pats Google tenants, bet tiek izveidots jauns tenants, lai sāktu tīri (izplatīta izvēle, lai izvairītos no konfigurācijas artefaktiem). Pastkastes migrē ar imapsync vai GSMMO. Datumi tiek sabojāti tieši tādā pašā veidā.

Filiāļu konsolidācija

Koncerns ar 4 meitasuzņēmumiem, katrs uz sava vēsturiskā G Suite tenanta, nolemj visu apvienot vienā tenantā. Četras paralēlas migrācijas, četras e-pastu partijas ar bojātiem datumiem apstrādei.

Visos trijos scenārijos problēma ir identiska un risinājums ir viens. E-pasta migrācijas kontrolsaraksts palīdz paredzēt šāda veida problēmas pirms migrācijas uzsākšanas.

Kāpēc pašrakstīts skripts nav atbilde

Saprast problēmu ir viena lieta. Teikt sev "uzrakstīšu Python skriptu, kas attīra galvenes" un pielietot to 30 000 ražošanas e-pastiem, ir pavisam cita.

Robežgadījumu ir ļoti daudz. Skripts, kas darbojas uz 50 testa e-pastiem tīrā vidē, reālā ražošanas pastkastē neizbēgami saskarsies ar:

• Ziņojumiem ar S/MIME parakstiem vai PGP šifrētu saturu, kur jebkura izmaiņa ziņojuma struktūrā padara kriptogrāfisko parakstu nederīgu.
• E-pastiem ar sarežģītām ligzdotām MIME struktūrām (multipart/alternative multipart/mixed iekšienē ar vairāku desmitu megabaitu pielikumiem).
• Galvenēm, kas kodētas ar RFC 2047 (ne-ASCII rakstzīmes), kuras nepareizi konfigurēti parseri klusi apēd.
• 429 Too Many Requests kļūdām no Google API pulksten 2 naktī, labojumu paketes vidū, atstājot procesu nenoteiktā stāvoklī.
• E-pastiem, kuros Received: ķēde ir neskaidra: vairāki secīgi migrācijas rīki katrs pievienoja savu galveni, un nav triviāli noteikt, kuru no tām dzēst.

Un vissvarīgākais jautājums: kā pārbaudīt, e-pasts pa e-pastam, ka katrs labotais ziņojums ir neskarts un nekas nav pazudis vai bojāts? Pašrakstīts skripts šo pārbaudi parasti neveic. Redate.io to dara automātiski, saglabājot oriģināļus redzamā rezerves kopiju mapē 30 dienas.

Ko Redate.io dara šāda veida migrācijās

Redate.io izveido savienojumu ar galamērķa Google Workspace tenantu (izmantojot domēna deleģēšanu, bez manuālas iejaukšanās katrā pastkastē) un skenē e-pastus, identificējot tos, kuru datumu metadati neatbilst ziņojuma saturam. Šī skenēšanas fāze ir bezmaksas un pirms jebkādas labošanas sniedz precīzu priekšstatu par problēmas apmēru.

Patentētais labošanas dzinējs pēc tam analizē katras galveņu ķēdi, veic rakstu saskaņošanu ar zināmajām migrācijas rīku parakstiem (BitTitan, CloudM, imapsync, GSMMO un citiem, retāk izmantotiem), un veic mērķtiecīgu metadatu labošanu, nemainot ziņojuma saturu. Katrs labotais e-pasts tiek pārbaudīts individuāli. Oriģināļi tiek saglabāti.

Google Workspace starptenanta migrācijām konkrēti, konveijers apstrādā gadījumus, kuros ir notikušas vairākas migrācijas kārtas (piemēram, pastkaste migrēta pirmo reizi 2021. gadā un atkārtoti 2024. gadā), ar vairākiem parazītu galveņu slāņiem, kas jāatrisina.

Specifiskas labošanas instrukcijas pieejamas lapās CloudM uz Google Workspace un BitTitan uz Google Workspace, ar savienojuma soļiem šāda veida konfigurācijai.

Problēmas atklāšana pirms lietotāji sūdzas

Labākais brīdis bojātu datumu atklāšanai ir tūlīt pēc migrācijas, pirms nodošanas ekspluatācijā. Ātra pārbaude uz dažām pilotpastkastēm, izmantojot IMAP klientu kā Thunderbird, ļauj salīdzināt datumu attēlojumu ar sagaidāmo. Ja visi importētie e-pasti šķiet ar vienādu nesenāku datumu, tas ir raksturīgākais problēmas simptoms.

Taču praksē problēma bieži tiek atklāta vairākas nedēļas pēc migrācijas, kad lietotājs meklē vecu līgumu un saprot, ka viņa Gmail pastkaste ir lieliski sakārtota... pēc migrācijas datuma. Tūkstošiem e-pastu sakrauti ar vienādu laikspiedolu. Meklēšana pēc datuma vairs nestrādā. Diskusiju pavedieni ir juceklīgi. Vēsture šķiet pazudusi.

MSP, kas regulāri veic Google Workspace starptenanta migrācijas, Redate.io skenēšanas iekļaušana pēcmigrācijas kontrolsarakstā (pirms klienta apstiprinājuma) novērš šādus pārsteigumus. Detalizētāku ieskatu skatiet rakstā par nepareiziem e-pastu datumiem pēc migrācijas.

Tikko migrējāt starp diviem Google Workspace tenantiem un jūsu e-pastu datumi ir nepareizi? Palaidiet bezmaksas skenēšanu Redate.io, lai novērtētu ietekmi pirms jebkādas labošanas.