CloudM Migrate: kā labot nepareizus datumus

CloudM Migrate datumu problēma, par kuru neviens nebrīdina

CloudM Migrate pabeidza darbu. Vadības panelis rāda, ka viss ir 100 % pabeigts, visi lietotāji migrēti, nulle kļūdu. Jūs aizverat projekta pieteikumu un pārejat pie nākamā klienta.

Tad nedēļu vēlāk piezvana IT direktors. "Kāpēc katrs e-pasts manā iesūtnē rāda 2. aprīli?"

Ne daži e-pasti. Visi. Pieci gadi klientu sarakstes, juridiski dokumenti, personāla ieraksti, pirkuma pasūtījumi no 2020. gada, viss rāda datumu, kad CloudM veica migrāciju. Ziņojumi ir tur, saturs ir neskarts, pielikumi ir kārtībā. Bet datumi ir nepareizi katrā vienā no tiem.

Šī nav CloudM kļūda. CloudM pati atbalsta dokumentācija to atklāti atzīst. Problēma slēpjas krustpunktā starp to, kā migrācijas rīki pārsūta ziņojumus, un to, kā galamērķa pasta serveri apstrādā ienākošā e-pasta metadatus. Bet zināt to nepalīdz jūsu klientam, kura pastkaste tikko kļuvusi nesakārtojama.

Kā CloudM patiesībā pārsūta e-pasta ziņojumus

CloudM Migrate pieslēdzas avota un galamērķa platformām, izmantojot to API. Google Workspace gadījumā tas nozīmē servisa kontu ar domēna mēroga delegāciju (konfigurēts Google Admin Console sadaļā Drošība > API vadīklas). Microsoft 365 gadījumā tas izmanto Exchange Web Services vai Microsoft Graph API, atkarībā no migrācijas ceļa.

Kad CloudM nolasa ziņojumu no avota, tas iegūst pilnu RFC 2822 saturu, ieskaitot visas sākotnējās galvenes un ziņojuma pamattekstu. Sākotnējā Date: galvene (tā, ko sūtītāja pasta serveris uzlika, kad e-pasts pirmoreiz tika nosūtīts) tiek pārnesta neskarta. Tāpat tiek pārnestas visas sākotnējās Received: galvenes, kas izseko ziņojuma piegādes ceļu.

Problēma rodas kopijas rakstīšanas brīdī. Galamērķis saglabā datumu, kāds tam tiek nodots: Microsoft 365 un Gmail saglabā sākotnējo datumu, ja kopija to nes. Kad tas nenotiek, kopija saņem ievietošanas brīdi kā savu datumu. Un Google Workspace platformā katrs ziņojums, kas rakstīts caur Gmail API, papildus saņem jaunu Received: galveni, kas datēta ar ievietošanas brīdi.

Lūk, ko galvenes vienā no šiem e-pastiem joprojām satur pēc CloudM migrācijas uz Microsoft 365:

Date: Mon, 23 Sep 2019 14:06:58 +0200
Received: from mail.original-company.com
    by smtp.original-company.com; Mon, 23 Sep 2019 14:07:11 +0200

Sākotnējā Date: galvene no 2019. gada joprojām ir tur, tāpat kā sākotnējā Received: ķēde. Bet Microsoft 365 datums, ko Outlook rāda kā saņemšanas datumu, ir pastkastes pašas fiksācija par to, kad katrs e-pasts ieradās: ja CloudM nenodeva sākotnējo datumu, šī fiksācija saka 2026. gada 2. aprīlis.

CloudM iestatījums "Strip Received Headers"

CloudM piedāvā iestatījumu šīs problēmas risināšanai. Galamērķa platformas papildu iestatījumos, ziņojumu opciju sadaļā, ir slēdzis "Strip Received Headers". Kad tas ir aktivizēts, CloudM noņem Received galvenes pirms ziņojuma ievietošanas un aizstāj tās ar vienu galveni, kas atbilst e-pasta Date: galvenei.

Izklausās, ka tas atrisina visu, vai ne? Ne gluži.

Pirmkārt, par šo iestatījumu jums jāzina pirms migrācijas palaišanas. Vairums administratoru datumu problēmu atklāj pēc migrācijas pabeigšanas. Tobrīd ziņojumi jau atrodas galamērķī ar nepareiziem datumiem. CloudM atkārtota palaišana ar aktivizētu iestatījumu tikai rada dublikātus, tā nelabo to, kas jau ir tur.

Otrkārt, šim iestatījumam ir stingrs ierobežojums, kad galamērķis ir Google Workspace. Google paša dokumentācija to apstiprina: Gmail vienmēr pārraksta Received: galvenes ziņojumiem, kas ievietoti caur API, apzīmogojot tās ar ievietošanas laika zīmogu. Tas ir platformas līmeņa ierobežojums, ko CloudM nevar apiet. Pat ar aktivizētu "Strip Received Headers" Google Workspace pievieno savu Received: galveni ar migrācijas datumu.

Microsoft 365 galamērķiem šis iestatījums ir mazāk svarīgs: Microsoft 365 saglabā tai nodoto datumu, tāpēc rādāmo datumu izšķir tas, vai CloudM nodod katra e-pasta sākotnējo datumu.

Kuras CloudM migrācijas sabojā datumus (un kuras ne)

Ne katra CloudM migrācija rada nepareizus datumus. Rezultāts ir atkarīgs no avota un galamērķa kombinācijas, un konkrētā API ceļa, ko CloudM izmanto:

• Google Workspace uz Microsoft 365: Datumi sabojājas. CloudM lasa caur Gmail API un raksta Exchange, un katrs e-pasts saņem kopijas datumu.
• Microsoft 365 uz Google Workspace: Datumi sabojājas. Pat ar aktivizētu Strip Received Headers Google API pārraksta Received galveni ar ievietošanas datumu. CloudM atbalsta dokumentācija to sauc par "stingru platformas ierobežojumu".
• Google Workspace uz Google Workspace: Datumi sabojājas. Domēnu maiņas, nomnieku konsolidācijas, iegāžu apvienošanas - katrs ziņojums, kas rakstīts caur Gmail API, saņem Received: galveni, datētu ar migrācijas brīdi.
• Lokāls Exchange uz Microsoft 365: Viss ir atkarīgs no datuma, ko CloudM nodod, neatkarīgi no tā, vai kopija tiek pārsūtīta caur IMAP vai EWS.
• Vispārīgs IMAP avots uz jebkuru galamērķi: Tas pats noteikums: kad CloudM pieslēdzas vispārīgam IMAP serverim kā avotam, kopija rāda migrācijas datumu ikreiz, kad sākotnējais datums nav nodots galamērķim.

Grūtākā daļa? CloudM migrācijas vadības panelis neko no tā neatzīmē. Progresa josla piepildās, statusa kolonna saka "Pabeigts", vienību skaiti sakrīt. No CloudM skatpunkta migrācija izdevās. Un tehniski tā tiešām izdevās. Ziņojumi tika pārsūtīti. Vienkārši datumi ceļojumu nepārcieta.

CloudM pārvaldīts un pašapkalpošanās: tā pati datumu problēma

CloudM piedāvā divus izvietošanas modeļus. SaaS versija (mitinātais CloudM Migrate) darbojas pilnībā CloudM infrastruktūrā. Pašmitināšanas versija ļauj izvietot primāros un sekundāros migrācijas serverus savā tīklā, Google Cloud, Azure vai AWS.

Daži MSP pieņem, ka pašmitināšanas opcija dod lielāku kontroli pār datumu apstrādi, jo migrācijas serverus jūs pārvaldāt tieši. Tā nedod. Datumu izšķir tas, ko migrācijas dzinējs nodod kopā ar katru ziņojumu, un šis dzinējs ir tas pats, kur arī tas darbojas. Neatkarīgi no tā, vai jūsu migrācijas ferma darbojas CloudM mākonī vai jūsu pašu Azure virtuālajā mašīnā, rezultāts datumiem ir vienāds.

CloudM piedāvā arī pilnībā pārvaldītu pakalpojumu "Serviced Migration", kur viņu komanda vada projektu no sākuma līdz beigām. Tāds pats rezultāts datumiem. Inženierija ir identiska, atšķiras tikai rokas, kas ir pie tastatūras. Vai jums ir gadījies maksāt par premium pakalpojumu un tomēr saņemt to pašu ierobežojumu, kas ir bezmaksas plānā? Tieši tā tas šķiet.

Nederīgas Date galvenes komplikācija

Ir vēl viena CloudM-specifiska uzvedība, kas situāciju padara sliktāku. Kad CloudM sastopas ar avota e-pastu, kura Date: galvene neatbilst RFC 822 (nepareizi formatēta laika zona, trūkstoša nedēļas diena, nestandarta formāts), tas modificē galveni, lai nodrošinātu, ka ziņojumu var migrēt.

Tas nozīmē, ka daži e-pasti zaudē pat savu sākotnējo datuma atsauci. Modificētā Date: galvene var vispār neatbilst reālajam nosūtīšanas datumam. CloudM atbalsta dokumentācija to piemin kā zināmu uzvedību sadaļā "Iespējamās izmaiņas migrētajos elementos", bet nenorāda, kāds kļūst modificētais datums.

Pastkastei ar 12 000 ziņojumiem, kas uzkrāti astoņu gadu laikā, var būt simtiem e-pastu ar nedaudz nestandarta Date galvenēm (jo īpaši ziņojumi no vecākiem pasta serveriem, automatizētām sistēmām vai starptautiskiem sūtītājiem ar laika zonas formatēšanas savdabībām). Pēc CloudM modifikācijas, kā arī kopijas, kas nenes sākotnējo datumu, šie ziņojumi beidzas ar datumiem, kam nav nekāda sakara ar realitāti.

Kāpēc manuālie labojumi pēc CloudM nedarbojas lielā apjomā

Vai jūs to varētu salabot paši? Tehniski sākotnējā Date: galvene joprojām ir iestrādāta vairumā ziņojumu (izņemot tos, kurus CloudM modificēja RFC atbilstības nodrošināšanai). Daži administratori ir mēģinājuši rakstīt skriptus datumu labošanai pēc CloudM migrācijas.

Šīs pieejas realitāte ir šāda. Jums nāktos pieslēgties potenciāli tūkstošiem pastkastu, katrā ar tūkstošiem ziņojumu. Katram e-pastam jāanalizē pilna galveņu ķēde, jāidentificē, kuras Received: galvenes pievienoja CloudM vai galamērķa serveris, jāapstrādā robežgadījumi (S/MIME parakstīti ziņojumi, kuros galvenes modifikācija sabojā parakstu, PGP šifrēts saturs, daudzdaļīgas MIME struktūras ar ligzdotām robežām, RFC 2047 kodētas ne-ASCII galvenes no japāņu vai korejiešu sūtītājiem), un visu to izdarīt, nezaudējot ne vienu pielikumu un nesabojājot e-pasta pavedienu.

Skripts, kas darbojas ar 50 testa e-pastiem no tīras pastkastes, neizturēs saskarsmi ar ražošanas vidi, kurā ir 40 000 ziņojumu, kas aptver desmit gadus. Kas notiek, kad uzduraties uz 47 MB e-pasta ar sešiem ligzdotiem pielikumiem? Kā ar API pieprasījumu ierobežojumiem (Google 250 kvotas vienības uz lietotāju sekundē, Microsoft ierobežojums ap 10 000 pieprasījumu 10 minūtēs)? Kāds ir jūsu atgriešanas plāns, kad kaut kas noiet greizi pie ziņojuma Nr. 8 347?

Un patiesais jautājums, ko vairums administratoru neuzdod, kamēr nav par vēlu: kā jūs pārbaudāt, ka katrs labotais ziņojums patiešām ir neskarts?

CloudM migrācijas datumu labošana ar Redate.io

Redate.io pieslēdzas tieši ietekmētajām pastkastēm (Google Workspace, Microsoft 365 vai IMAP) un skenē e-pastus, kuru attēlotais datums neatbilst to sākotnējam datumam. Skenēšana ir bezmaksas un aizņem pāris minūtes uz pastkasti, parādot precīzu ietekmēto ziņojumu skaitu pirms jebkādas saistības.

Labošana izmanto Redate.io izstrādātu galveņu ķēdes analīzes dzinēju, un tam nav vajadzības zināt, kurš rīks migrāciju veica. Redate.io veic mērķtiecīgu metadatu labošanu, nemainot ziņojuma saturu, saglabājot pielikumus, pavedienus, etiķetes, mapes un digitālos parakstus. Katrs labotais ziņojums iziet individuālu verifikāciju, pārbaudot ziņojuma integritāti pret oriģinālu, pirms process turpinās tālāk.

Sākotnējie e-pasti tiek glabāti redzamā Redate.io - Originals rezerves mapē, kamēr jūs paši to nedzēšat. Ja kaut kas jāatgriež, oriģināli ir tepat pastkastē, nevis apglabāti kādā ārējā arhīvā.

MSP, kas izmantojuši CloudM klientu vidēs, ar Redate.io var apstrādāt vairāku pastkastu labošanu lielā apjomā, ar tādu pašu verifikāciju katram ziņojumam neatkarīgi no tā, vai jūs labojat 1 pastkasti vai 500. Datumu problēmai, ko atstāja CloudM, nav jākļūst par jūsu klienta pasta vides pastāvīgu iezīmi.

Platformai specifiskas pamācības CloudM migrācijām

Labošanas process pielāgojas galamērķa platformai. Redate.io automātiski apstrādā katras platformas specifiku, bet detaļām par jūsu iestatījumu:

• Izlabojiet CloudM migrācijas datumus Gmail
• Izlabojiet CloudM migrācijas datumus programmā Outlook
• Izlabojiet CloudM migrācijas datumus Google Workspace
• Izlabojiet CloudM migrācijas datumus Microsoft 365

Padziļinātam skaidrojumam par to, kāpēc tas notiek visos migrācijas rīkos, ne tikai CloudM, skatiet kāpēc e-pasti pēc migrācijas rāda nepareizus datumus.

Migrējāt ar CloudM un palikāt ar nepareiziem datumiem katrā e-pastā? Sāciet bezmaksas skenēšanu, lai redzētu, cik precīzi ziņojumu ir ietekmēti un cik maksā to labošana.