Outlook profilio atkūrimas: kodėl datos pasikeičia

Trikčių šalinimo veiksmas, kuris sugadina datas

Vartotojas skundžiasi, kad Outlook nebesisinchronizuoja. El. laiškai neatvyksta, aplankas Išsiųsti nesinaujina, sukasi ratas be galo. Technikas diagnozuoja sugadintą profilį, ištrina OST failą, atkuria Outlook profilį nuo nulio. Rezultatas: Outlook vėl prisijungia, el. laiškai vėl matomi, viskas atrodo gerai.

Iki kitos ryto, kai vartotojas atidaro pašto dėžutę ir supranta, kad 8 metų korespondencija rodo tą pačią datą: šiandien.

Tai lygiai tas pats simptomas kaip ir nepavykusios IMAP migracijos atveju. Ir dėl tų pačių priežasčių.

Kas vyksta techniniu požiūriu

Norint suprasti, kodėl profilio atkūrimas duoda tokį rezultatą, reikia grįžti prie skirtumo, kurį dauguma technikų prastai išmano: skirtumo tarp el. laiško antraštės Date: ir jo IMAP INTERNALDATE.

Kiekvienas el. laiškas RFC 2822 antraštėse turi lauką Date:, nurodantį, kada žinutė buvo išsiųsta. Šį lauką užrašo siuntėjo pašto programa išsiuntimo metu, tada jis perduodamas per visus serverius nepakitęs iki jūsų pašto dėžutės. Jis niekada nesikeičia. El. laiškas, išsiųstas 2019 m. kovo 14 d. 09:32, visada turės tą patį nepakitusį lauką Date:, kad ir kas vėliau nutiktų.

IMAP INTERNALDATE yra kitas dalykas. Tai serverio valdoma metaduomenų reikšmė, nepriklausoma nuo žinutės turinio. Ji nurodo, kada žinutė buvo "įdėta" į pašto dėžutę. Įprastomis sąlygomis, kai el. laiškas ateina per SMTP, serveris užfiksuoja gavimo laiką kaip INTERNALDATE. El. laiškas, gautas 2019 m. kovo 14 d., turės INTERNALDATE, atitinkančią jo išsiuntimo datą.

Outlook pagal nutylėjimą rikiuoja ir rodo el. laiškus pagal IMAP serverio perduodamą INTERNALDATE, o ne pagal pačios žinutės lauką Date:. (Beje, jei kada nors atverėte pilnas el. laiško ypatybes Outlook programoje, kad pamatytumėte neapdorotas antraštes, žinote, kad tai retai kada būna malonus skaitymas.)

Ką sukelsia OST failo ištrynimas

Kai Outlook naudoja IMAP paskyrą, jis palaiko vietinę duomenų bazę: OST failą (Offline Storage Table). Šis failas yra vietinis serverio el. laiškų atspindys su jų metaduomenimis, skaitymo būsenomis, kategorijomis ir pan.

Ištrinti OST failą reiškia ištrinti šį vietinį atspindį. Outlook turi iš naujo atsisiųsti viską iš IMAP serverio.

Problema? Kai Outlook iš naujo atsisiunčia žinutę per IMAP, naudoja komandą FETCH turiniui gauti. Tačiau ne visada naudoja komandą FETCH INTERNALDATE pradinei IMAP datai gauti ir išsaugoti. Tam tikrose Outlook konfigūracijose ir versijose klientas atnaujina vietinį indeksą naudodamas datą, kada žinutė buvo atsisiųsta iš naujo, o ne serverio išsaugotą INTERNALDATE.

Ir štai visi pašto dėžutės el. laiškai tampa pažymėti perkrovimo dienos data.

Ne visos Outlook versijos elgiasi vienodai

Tiksliau: šis elgesys veikia ne visas Outlook versijas vienodai, ir čia diagnostika tampa sudėtinga.

Outlook 2016 ir 2019 IMAP režimu turi dokumentuotų neteisingos indekso rekonstrukcijos problemų po talpyklos ištrynimo. Naujasis Outlook (žiniatinklio pagrindu, diegiamas palaipsniui nuo 2023 m. pabaigos) talpyklą valdo kitaip ir gali duoti kintančius rezultatus. Outlook per Exchange/Microsoft 365, konfigūruotas Exchange režimu, yra mažiau pažeidžiamas šios konkrečios problemos, nes MAPI/Exchange protokolas sinchronizavimą valdo kitaip nei IMAP.

Tačiau jei jūsų vartotojas naudoja IMAP paskyrą klasikiniame Outlook ir technikas ištrynė OST failą arba atkūrė profilį, rizika yra reali.

Kaip atskirti šį atvejį nuo tikros migracijos

IT administratorius, gaunantis užklausas „mano datos klaidingos" po profilio atkūrimo, gali klaidingai manyti, kad tai migracijos problema. Štai kaip atskirti abu atvejus.

IMAP migracijos atvejis

IMAP migracijos metu (BitTitan, CloudM, imapsync ir pan.) migracijos įrankis kopijuoja el. laiškus iš vieno serverio į kitą. Kiekvienai kopijuojamai žinutei sukuriamas naujas įrašas paskirties serveryje naudojant komandą IMAP APPEND. Jei įrankis aiškiai nenurodo pradinės INTERNALDATE šioje komandoje, paskirties serveris kaip INTERNALDATE užfiksuoja dabartinį laiką. Be to, kai kurie įrankiai prideda antraštę Received: su migracijos data, kas kai kuriuose klientuose dar labiau apsunkina situaciją. Išsamų šio mechanizmo aprašymą rasite mūsų straipsnyje apie IMAP INTERNALDATE ir neteisingas datas.

Profilio atkūrimo atvejis

Čia el. laiškai vis dar yra tame pačiame serveryje su tomis pačiomis pradinėmis INTERNALDATE reikšmėmis. Serverio pusėje niekas nepasikeitė. Tik Outlook vietinė talpykla buvo atstatyta su klaidingomis datomis. Matomas simptomas identiškas (visi el. laiškai rodo tą pačią naują datą), tačiau priežastis skirtinga.

Patikrinti galima taip: prisijunkite prie pašto dėžutės per žiniatinklio pašto sąsają (Gmail, Outlook.com arba savo prieglobos žiniatinklio pašto sąsają). Jei datos žiniatinklio pašte rodomos teisingai, problema yra vietinė ir susijusi tik su Outlook. Jei datos žiniatinklio pašte taip pat klaidingos, problema yra serverio pusėje (migracija arba INTERNALDATE pakeitimai pačiame serveryje).

Kodėl pradinės datos išlieka atkuriamos

Gera žinia: abiem atvejais (migracija ar profilio atkūrimas) pradinės datos nėra prarastos.

RFC 2822 antraštės laukas Date: yra neatskiriama žinutės dalis. Jis toks pat nekintamas kaip teksto turinys ar priedai. El. laiškas, išsiųstas 2017 m., grynajame tekste turi kažką panašaus į:

Date: Mon, 12 Jun 2017 14:23:41 +0200

Ši eilutė yra serveryje saugomoje žinutėje. Ji nebuvo pakeista. Tai, ką Outlook rodo (klaidingai), yra metaduomenys, esantys žinutės turinio išorėje.

Būtent tai ir leidžia taisymą atlikti. Redate.io variklis analizuoja kiekvienos žinutės antraščių grandinę, kad išskirtų tikrąją pradinę datą, ir tada atlieka tikslinę metaduomenų korekciją nepakeisdamas žinutės turinio. Outlook matoma INTERNALDATE reikšmė rekonstruojama remiantis šia autentiška informacija, kuri visada yra žinutėje.

„Švaraus" atkūrimo spąstai

Ką tik išsprendėte sinchronizavimo problemą vartotojui. Jo Outlook vėl veikia, nauji el. laiškai ateina. Uždarote užklausą.

Po trijų dienų vartotojas vėl skambina: ieško el. laiško iš tiekėjo iš praėjusių metų, tačiau Outlook visi 2023 m. el. laiškai atrodo gauti „vakar". Nieko neranda. Automatinis archyvavimas greičiausiai suklasifikavo naujus el. laiškus kaip senus. O jo vadovas prašo 2022 m. rugsėjo mėnesio el. laiškų pokalbio dėl ginčo.

Šis scenarijus kartojasi reguliariai. Ne todėl, kad technikas blogai atliko darbą, o todėl, kad šis Outlook elgesys nėra matomai dokumentuotas standartuose trikčių šalinimo vadovuose.

Netikri sprendimai, kurie nieko neišsprendžia

Rikiavimas pagal „Siuntimo datą" vietoj „Gavimo datos" Outlook programoje yra pirmas dalykas, kurį bando vartotojai. Ir atrodo, kad veikia... kol jie supranta, kad rikiavimas pagal siuntimo datą galimas tik kai kuriuose aplankuose, išnyksta pakeitus rodinį ir kad kitos programos (mobilioji, žiniatinklio paštas, automatinio rikiavimo taisyklės) toliau naudoja klaidingą INTERNALDATE.

Rikiavimas pagal siuntimo datą nėra sprendimas. Tai pleistras, slepiamas simptomas neliečiant tikros problemos. Tai išsamiai paaiškinta straipsnyje Rikiavimas pagal siuntimo datą nėra sprendimas.

Antrą kartą atkurti profilį? Tai nieko nekeičia, jei Outlook talpyklą atnaujina dabartine data.

Eksportuoti ir reimportuoti PST formatu? Atsargiai. PST eksportas iš Outlook su neteisingomis datomis eksportuoja sugadintus metaduomenis. PST failas turės klaidingas datas. Jo reimportavimas nieko netaiso, ir netgi gali pabloginti situaciją sukuriant dublikatus su nenuosekliomis datomis. Ši tema atskirai nagrinėjama straipsnyje apie PST importą Outlook ir datas, tampančias šiandienos.

Ką Redate.io daro šiuo konkrečiu atveju

Nesvarbu, ar problema kilo dėl IMAP migracijos, ar dėl Outlook profilio atkūrimo, serverio pusės rezultatas panašus: el. laiškai, kurių datų metaduomenys neatitinka tikrojo turinio.

Redate.io tiesiogiai prisijungia prie pašto dėžutės (Google Workspace, Microsoft 365 arba tiesioginis IMAP), nuskaito visas žinutes identifikuodamas tas, kurių metaduomenys klaidingi, ir taiko daugiapakopį analizės procesą kiekvienam el. laiškui atskirai. Kiekviena korekcija yra patikrinama. Pradinės žinutės išsaugomos matomame atsarginės kopijos aplanke, kol jų nepašalinsite patys.

Procesas tvarko kraštutinius atvejus, kurie namuose rašyti skriptai sistemingai praleidžia: S/MIME pasirašytos žinutės, el. laiškai su ne-ASCII kodavimu antraštėse (RFC 2047), sudėtingos multipart struktūros, Date: antraštės su nestandartinėmis arba klaidingomis laiko juostomis. Skriptas, tinkamai veikiantis su 50 bandomųjų el. laiškų kūrimo dėžutėje, gali neatitaisymai sugadinti 2000 žinučių gamybos aplinkoje. IMAP protokole nėra natūralaus atšaukimo mechanizmo, kai žinutė pakeičiama be išankstinės atsarginės kopijos.

Atvejams, susijusiems konkrečiai su Outlook, korekcijos puslapis Pataisykite rankinio IMAP kopijavimo datas Outlook detaliai aprašo žingsnius, kaip prijungti pašto dėžutę ir paleisti analizę.

Kaip išvengti problemos kitų intervencijų metu

Jei esate technikas arba IT administratorius, reguliariai dirbantis su Outlook profiliais, keletas refleksų padės išvengti šios situacijos.

Prieš ištrinant OST failą ar atkuriant profilį, patikrinkite datas žiniatinklio pašto sąsajoje. Jei jos teisingos, užfiksuokite tai savo užklausoje. Po atkūrimo vėl prisijunkite per žiniatinklio paštą ir palyginkite rodomas datas su tomis, kurios rodomos Outlook programoje. Jei matomas skirtumas, problema identifikuojama iš karto, prieš vartotojui skundžiantis po trijų dienų.

Planuojamų migracijų atveju, el. pašto migracijos kontrolinis sąrašas išvardija patikrinimus, kuriuos reikia atlikti prieš ir po operacijos, kad šio tipo problemos būtų aptiktos iš karto po pabaigos.

Atkūrėte Outlook profilį ir dabar visos pašto dėžutės datos yra klaidingos? Paleiskite nemokamą nuskaitymą Redate.io, kad identifikuotumėte paveiktus el. laiškus ir pataisytumėte metaduomenis nepaliesdami žinučių turinio.