Uus Outlook: valed kuupäevad pärast migratsiooni

Kaks Outlooki, kaks erinevat käitumist samade meilidega

Kui olete hiljuti migratsiooni kaudu postkastid Microsoft 365-i viinud ja mõned kasutajad kurdavad, et kõik vanad meilid kuvatakse sama kuupäevaga (migratsiooni kuupäevaga), võite märgata midagi imelikku: klassikalist Outlooki kasutajad näevad lugemispaanis kohati õiget kuupäeva, samas kui uue Outlooki kasutajad Windowsis näevad alati migratsiooni kuupäeva. Sama postkast. Samad meilid. Erinevad tulemused.

See ei ole viga ranges tähenduses. See on arhitektuurne otsus, millel on otsesed tagajärjed kuupäevade kuvamisele pärast IMAP-migratsiooni. Et mõista, mis toimub, tuleb süveneda meili päiste ja IMAP-protokolli üksikasjadesse, mis ei ole täpselt kerge lugemine, kuid selgitab, miks ükski kliendipoolne lahendus probleemi ei lahenda.

IMAP INTERNALDATE: tegelik süüdlane

Kui meil salvestatakse IMAP-serverisse, on sellel kaks erinevat kuupäeva, mis eksisteerivad koos ega kattu.

Esimene on päis Date:, mille määratleb RFC 2822. See on sõnumisse kirjutatud kuupäev, mille saatja pani meili saatmise hetkel. See on osa sõnumi kehast ja ei muutu kunagi, olenemata sellest, millist teed meil hiljem läbib.

Teine on INTERNALDATE, IMAP-serveri hallatud metaandmed, mis asuvad väljaspool sõnumit. See on kuupäev, millal server sõnumi salvestas. Tavamigratsioonil säilitavad tõsised tööriistad algse INTERNALDATE'i. Aga valesti seadistatud migratsioonil, või teatud tööriistadega, mis seda metaandmeid korralikult ei halda, lähtestatakse INTERNALDATE migratsiooni päeva kuupäevale. Tulemus: kõikidel migreeritud meilidel on serveri jaoks sama vastuvõtmise kuupäev.

(Muide, kui olete kunagi imapsync'i või MigrationWizi logisid lugenud, teate, et INTERNALDATE säilitamiseks on spetsiifilisi valikuid. Need ei tööta alati ja mõned sihtkohta serverid keelduvad neid täitmast.)

Klassikaline Outlook: kuidas see kuupäevi loeb

Klassikaline Outlook, see tähendab kohalikult installitud COM-versioonid (Outlook 2016, 2019, 2021 ja Microsoft 365 Apps töölauaklient), kasutab kuupäeva kuvamiseks meilinimekirjas natuke keerukamat mehhanismi.

Saadetud kausta meilide puhul kasutab see päist Date:. Saabunud meilide puhul eelistab see serveri INTERNALDATE'i, kuid teatud kontekstides (eriti kui OST-vahemälu on kaasatud või lugemispaanis esmakordsel kuvamisel) võib see lugeda ka Received: päiste ahelat, et ligikaudselt algne kuupäev rekonstrueerida.

Sellepärast täheldataksegi seda ebajärjekindlat käitumist: klassikaline Outlook võib mõnikord kuvada lugemispaanis õiget kuupäeva, kuna loeb üksikasjaliku eelvaate jaoks sõnumi originaalset Date: päist, isegi kui meilinimekirja enda puhul kasutatakse rikutud INTERNALDATE'i. Aga see ei ole usaldusväärne ega paranda midagi. Sortimine on ikka katki, kuupäevapõhised otsingud ikka valed.

Uus Outlook: põhjalikult erinev arhitektuur

Uus Outlook Windowsile, mida hakati järk-järgult kasutusele võtma 2023. aasta lõpust, ei ole enam COM-rakendus. See on sisuliselt progressiivne veebirakendus (PWA), mis põhineb samal koodibaasil kui Outlook veebibrauseris (OWA). Sellel ümberkujundamisel on sügavad tagajärjed.

Uus Outlook delegeerib kuupäevade kuvamise täielikult Microsoft 365 API-le. See ei loe Received: päiseid, ei uuri päiste ahelat algse kuupäeva leidmiseks ega tee mingit kliendipoolset rekonstrueerimiskatset. See kuvab lihtsalt seda, mida server tagastab: INTERNALDATE'i.

Tulemus: kui INTERNALDATE rikuti migratsiooni käigus, ei kõhkle uus Outlook hetkegi. See kuvab iga mõjutatud meili puhul migratsiooni kuupäeva, ilma eranditeta, ilma nüanssideta. See on klassikalise Outlookiga võrreldes järjekindlam ja etteaimatavam käitumine, aga see muudab migratsioonist tuleneva probleemi kohe nähtavaks ja ignoreerimiseks võimatuks.

Admin, kes migreeriks 300 postkasti reedel õhtul, avastaks esmaspäeva hommikul, et kõik uut Outlooki kasutavad kasutajad näevad oma kogu arhiivi dateerituna eelmise nädalavahetusega. Piletid hakkavad kiiresti tulema.

Miks ükski kliendipoolne lahendus ei toimi

Paljud administraatorid proovivad kliendipoolseid lahendusi enne, kui mõistavad, et probleem peitub serveri andmetes. Siin on klassikalised katsed ja põhjused, miks need ebaõnnestuvad.

Sortimine "Saatmiskuupäeva" järgi "Vastuvõtmiskuupäeva" asemel

Outlooki saatmiskuupäeva järgi sortimine kasutab sõnumi päist Date:, mis on puutumata. Seega jah, see sortimine võib töötada. Aga see on laastuga haava katmine, mitte lahendus. Kuupäevapõhised otsingud jäävad katki. Kuupäevapõhised reeglid jäävad kasutuskõlbmatuks. Ja mis kõige tähtsam, kasutaja peab iga kausta ja iga postkasti käsitsi ümber seadistama. 300 postkasti puhul on see ebareaalne. Saatmiskuupäeva järgi sortimine ei lahenda probleemi ja lõppkasutajad ei mõista, miks neilt oodatakse harjumuste muutmist.

Outlooki vahemälu tühjendamine või profiili taaslooming

See ei puutu serveri INTERNALDATE'i. Pärast profiili taasloomist sünkroniseerib Outlook meilid serverist uuesti ja saab täpselt samad rikutud metaandmed tagasi. Vahemälu ei ole probleem.

OWA kasutamine alternatiivina

OWA ja uus Outlook jagavad sama andmebaasi. Kui Exchange Online'i serveris on INTERNALDATE rikutud, kuvab OWA täpselt sama vale kuupäeva. Kliendi vahetamine ei muuda andmeid.

Probleem on serveris, iga sõnumi metaandmetes. Ükski kliendipoolne toiming ei saa parandada serveripoolselt salvestatud andmeid.

Received-päiste lõks: miks need kõike keerulisemaks teevad

Kui migratsioonitööriist kopeerib meili IMAP-i kaudu ühest serverist teise, lisab sihtserver automaatselt päise Received: ahela ülaossa koos lisamise kuupäeva ja kellaajaga. See on RFC-ga kooskõlas olevate SMTP- ja IMAP-serverite tavaline käitumine.

Need päised kogunevad meili poolt läbitud tee vastupidises järjekorras. Viimane on ülaosas. Mõned meilirakendused loevad esimest Received: päist vastuvõtmiskuupäeva hindamiseks, mis annab tulemuseks migratsiooni kuupäeva algse kuupäeva asemel.

Täpsustus: see käitumine ei ole omane ühele konkreetsele tööriistale. BitTitan MigrationWiz, CloudM, imapsync, GSMMO ja isegi käsitsi IMAP-kopeerimine kahe Thunderbirdi kliendi vahel annavad kõik sama tulemuse. Algne Date: päis jääb sõnumis puutumata. Just see teebki tehnilise parandamise võimalikuks. Aga INTERNALDATE on eraldi metaandmed, mida haldab server, ja neid ei saa parandada lihtsalt kliendipoolsete sõnumipäiste manipuleerimisega.

Selle mehhanismi kohta lähemalt saab lugeda artiklist IMAP INTERNALDATE: miks kuupäevad katki lähevad, mis kirjeldab üksikasjalikult, kuidas seda metaandmeid erinevates serverites hallatakse.

Millised migratsioonitööriistad selle probleemi Microsoft 365-s põhjustavad

Küsimus kerkib sageli: kas kõik migratsioonitööriistad põhjustavad selle probleemi?

Lühike vastus on, et see sõltub konfiguratsioonist ja sihtkohta platvormist. Exchange Online'il ja Microsoft 365-l on INTERNALDATE'i haldamisel eriti range käitumine. Isegi tööriistad, mis üritavad seda säilitada, ebaõnnestuvad mõnikord, kuna Graph API-l ja EWS-il (Exchange Web Services) on kasutatava lisamistee alusel erinev käitumine.

BitTitan MigrationWiz on üks levinumaid tööriistu Microsoft 365-i migratsioonide jaoks ja ka üks neist, kelle kuupäevaprobleemid on kõige paremini dokumenteeritud. Sihtleht BitTitan migratsioonikuupäevade parandamine Microsoft 365-s käsitleb spetsiifilisi konfiguratsioone, mida jälgida. CloudM-il ja imapsync-il on omad eripärad, mis on vastavalt dokumenteeritud lehtedel CloudM migratsioonikuupäevade parandamine Microsoft 365-s ja imapsync migratsioonikuupäevade parandamine Microsoft 365-s.

Mis on kõigile nendele tööriistadele ühine: algne Date: päis jääb pärast migratsiooni ellu. See on alus, millele tuginedes parandamine on võimalik.

Miks on omatehtud skript siin halb mõte

Probleemi mõistmine tekitab mõnikord illusiooni, et lahendus on lihtne. See ei ole seda, mitte tootmiskeskkonnas.

Exchange Online'is salvestatud meilide metaandmete muutmine ei ole triviaalne. Microsofti Graph API-l on ranged kiiruspiirangud (viga 429 Too Many Requests öise pakktöötluse ajal tuleb kiiresti). S/MIME-ga allkirjastatud või PGP-ga krüpteeritud meilide käsitsemine nõuab erilist tähelepanu, et allkirju mitte kehtetuks muuta. Mahukate manustega multipart-struktuurid lisavad võrgu ajalõppudele piiranguid. Ja mis kõige tähtsam: kuidas kontrollida meili kaupa, et parandamine töötas korralikult ega muutnud sisu ega manuseid?

Skript, mis töötab hästi 50 testmeiliga, ei käitu samamoodi 40 000 sõnumiga postkastis, millel on 8-aastane ajalugu. Tõenäosus, et mõni äärejuhtum midagi katki teeb, kasvab iga lisanduva tuhande sõnumiga. Ja rollback-mehhanismi puudumisel jätab viga pooleli jäänud kohas postkasti ebajärjekindlasse olekusse.

Vt ka: kuupäevade parandamine pärast Microsoft 365 migratsiooni kõikide saadaolevate võimaluste ülevaate jaoks.

Mida Redate.io konkreetselt teeb

Redate.io logib iga kasutaja oma Microsofti kontoga sisse ja avab ainult selle postkasti sisselogimisel antud õigustega, ilma Azure portaali ega rakenduse registreerimiseta. Seejärel skannib see vale kuupäevaga meilid tasuta ja rakendab seejärel tuvastatud sõnumitele Redate'i välja töötatud parandusmootorit. Mitmeastmeline analüüsikonveier teostab mustrite sobitamise sadade tuntud migratsioonitööriistade signatuuride alusel, RFC-vastavuse valideerimise ja päiste ahela analüüsi, et rekonstrueerida õiged kuupäeva metaandmed.

Iga parandatud meil kontrollitakse individuaalselt. Originaalsõnumid säilitatakse nähtavas varunduskaustas, kuni te need enda käest kustutate. Hinnakujunduse mudel põhineb ühekordsel maksel postkasti kohta, ilma tellimuseta.

Uus Outlook kuvab seejärel õigeid kuupäevi, kuna serveriandmed on parandatud, mitte maskeeritud.

Teil on uues Outlookis mõjutatud postkaste? Käivitage Redate.io-s tasuta skannimine, et tuvastada täpselt, kui paljud meilid on mõjutatud, enne kui otsustate edasiste sammude üle.