Outlook profila atjaunošana: kāpēc mainās datumi

Problēmu novēršanas darbība, kas sabojā datumus

Lietotājs sūdzas, ka Outlook vairs nesinhronizējas. E-pasti nepienāk, mape Nosūtītie netiek atjaunināta, ritenis griežas bezgalīgi. Tehniķis diagnosticē bojātu profilu, dzēš OST failu, atjauno Outlook profilu no jauna. Rezultāts: Outlook atkal pieslēdzas, e-pasti parādās, viss šķiet strādājam.

Līdz nākamās dienas rītam, kad lietotājs atver savu pastkasti un pamana, ka 8 gadu korespondence rāda vienu un to pašu datumu: šodien.

Tas ir tieši tāds pats simptoms kā neveiksmīgas IMAP migrācijas gadījumā. Un tādu pašu iemeslu dēļ.

Kas notiek tehniski

Lai saprastu, kāpēc profila atjaunošana rada šo rezultātu, jāatgriežas pie atšķirības, ko lielākā daļa tehniķu nepazīst labi: starpību starp e-pasta galvenes lauku Date: un tā IMAP INTERNALDATE.

Katrs e-pasts savās RFC 2822 galvenēs satur lauku Date:, kas norāda, kad ziņojums tika nosūtīts. Šo lauku nosūtītāja pasta klients ieraksta nosūtīšanas brīdī, un tad tas tiek pārsūtīts nemainīts caur visiem serveriem līdz jūsu pastkastei. Tas nekad nemainās. E-pastam, kas nosūtīts 2019. gada 14. martā plkst. 09:32, vienmēr būs šis Date: lauks neskarts, neatkarīgi no tā, kas notiek vēlāk.

IMAP INTERNALDATE ir kas cits. Tā ir pasta servera pārvaldīta metadatu vērtība, neatkarīga no ziņojuma satura. Tā norāda, kad ziņojums tika „nogādāts" pastkastē. Normālos apstākļos, kad e-pasts pienāk caur SMTP, serveris reģistrē saņemšanas laiku kā INTERNALDATE. Tātad e-pastam, kas saņemts 2019. gada 14. martā, būs INTERNALDATE, kas atbilst tā nosūtīšanas datumam.

Outlook pēc noklusējuma kārto un rāda e-pastus pēc INTERNALDATE, ko nodod IMAP serveris, nevis pēc paša ziņojuma Date: lauka. (Starp citu, ja jūs kādreiz esat atvēruši pilnas e-pasta rekvizītas Outlook, lai apskatītu neapstrādātās galvenes, jūs zināt, ka tā nav tieši pludmales lasāmviela.)

Ko izraisa OST faila dzēšana

Kad Outlook izmanto IMAP kontu, tas uztur lokālu datu bāzi: OST failu (Offline Storage Table). Šis fails ir serverī glabāto e-pastu lokāls spogulis ar to metadatiem, lasīšanas stāvokļiem, kategorijām u.tml.

OST faila dzēšana nozīmē šī lokālā spoguļa izdzēšanu. Outlook viss no IMAP servera jālejupielādē no jauna.

Problēma? Kad Outlook lejupielādē ziņojumu caur IMAP, tas izmanto komandu FETCH, lai iegūtu saturu. Taču tas ne vienmēr izmanto komandu FETCH INTERNALDATE, lai atgūtu un saglabātu sākotnējo IMAP datumu. Dažās Outlook konfigurācijās un versijās klients atjauno savu lokālo indeksu, izmantojot datumu, kad tas lejupielādēja ziņojumu, nevis serverī glabāto INTERNALDATE.

Un tad visi pastkastes e-pasti tiek datēti ar atkārtotas ielādes dienu.

Ne visas Outlook versijas uzvedas vienādi

Patiesībā šī uzvedība neietekmē visas Outlook versijas vienādi, un tieši šeit diagnostika kļūst sarežģīta.

Outlook 2016 un 2019 IMAP režīmā ir dokumentēta nepareiza indeksa atjaunošana pēc kešatmiņas dzēšanas. Jaunais Outlook (tīmekļa versija, ko pakāpeniski izvērsa kopš 2023. gada beigām) pārvalda kešatmiņu citādi un var dot mainīgus rezultātus. Outlook, kas konfigurēts ar Exchange/Microsoft 365 kontu Exchange režīmā, ir mazāk pakļauts šai konkrētajai problēmai, jo MAPI/Exchange protokols sinhronizāciju pārvalda citādi nekā IMAP.

Bet ja jūsu lietotājs izmanto IMAP kontu, kas konfigurēts klasiskajā Outlook, un tehniķis ir dzēsis OST failu vai atjaunojis profilu: risks ir reāls.

Kā atšķirt šo gadījumu no īstas migrācijas

IT administrators, kas saņem biļetes „mani datumi ir nepareizi" pēc profila atjaunošanas, var kļūdaini domāt, ka runa ir par migrācijas problēmu. Lūk, kā atšķirt abus gadījumus.

IMAP migrācijas gadījums

IMAP migrācijas laikā (BitTitan, CloudM, imapsync u.c.) migrācijas rīks kopē e-pastus no viena servera uz otru. Katram kopētam ziņojumam tas mērķa serverī izveido jaunu ierakstu, izmantojot komandu IMAP APPEND. Ja rīks šajā komandā neprecizē sākotnējo INTERNALDATE, mērķa serveris reģistrē pašreizējo laiku kā INTERNALDATE. Turklāt daži rīki pievieno arī galveni Received: ar migrācijas datumu, kas dažos klientos vēl vairāk pastiprina problēmu. Sīkāku informāciju par šo mehānismu varat lasīt mūsu rakstā par IMAP INTERNALDATE un sabojātajiem datumiem.

Profila atjaunošanas gadījums

Šeit e-pasti joprojām atrodas tajā pašā serverī ar tiem pašiem sākotnējiem INTERNALDATE. Servera pusē nekas nav mainījies. Tikai Outlook lokālā kešatmiņa ir atjaunota ar nepareiziem datumiem. Redzamais simptoms ir identisks (visi e-pasti rāda to pašu jaunāko datumu), bet cēlonis ir atšķirīgs.

Lai pārbaudītu: piesakieties pastkastē caur tīmekļa pastu (Gmail, Outlook.com vai sava mitinātāja tīmekļa pasta saskarne). Ja tīmekļa pastā rādītie datumi ir pareizi, problēma ir tikai lokāla Outlook līmenī. Ja datumi tīmekļa pastā arī ir nepareizi, problēma ir servera pusē (migrācija vai INTERNALDATE maiņa pašā serverī).

Kāpēc sākotnējie datumi ir atgūstami

Labā ziņa: abos gadījumos (migrācija vai profila atjaunošana) sākotnējie datumi nav pazuduši.

RFC 2822 galvenes lauks Date: ir neatņemama ziņojuma daļa. Tas ir tikpat nemainīgs kā teksta pamatteksts vai pielikumi. E-pastā, kas nosūtīts 2017. gadā, neapstrādātā tekstā ir kaut kas līdzīgs:

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

Šī rinda ir serverī glabātajā ziņojumā. Tā nav mainīta. Ko Outlook rāda (nepareizi) ir metadatu vērtība, kas ir ārpus ziņojuma satura.

Tieši tas padara labošanu iespējamu. Redate.io dzinējs analizē katra ziņojuma galveņu ķēdi, lai iegūtu patieso sākotnējo datumu, pēc tam veic mērķtiecīgu metadatu labošanu, nemainot ziņojuma saturu. Outlook redzamais INTERNALDATE tiek atjaunots, pamatojoties uz šo autentisko informāciju, kas vienmēr ir klātesoša ziņojumā.

"Tīrās" atjaunošanas slazds

Jūs tikko atrisinājāt sinhronizācijas problēmu kādam lietotājam. Viņa Outlook atkal strādā, jaunie e-pasti pienāk. Jūs aizveriet biļeti.

Trīs dienas vēlāk lietotājs atkal zvana: viņš meklē e-pastu no piegādātāja pagājušajā gadā, bet Outlook visi viņa 2023. gada e-pasti parādās kā saņemti „vakar". Viņš neko neatrod. Automātiskā arhivēšana, iespējams, jaunos e-pastus ir klasificējusi kā vecos. Un viņa priekšnieks prasa e-pasta sarakstes vēstules no 2022. gada septembra strīdus gadījumam.

Šis scenārijs notiek regulāri. Ne tāpēc, ka tehniķis ir slikti veicis darbu, bet tāpēc, ka šī Outlook uzvedība standarta problēmu novēršanas rokasgrāmatās nav skaidri dokumentēta.

Viltus risinājumi, kas neko nerisina

E-pastu kārtošana pēc „Nosūtīšanas datuma", nevis „Saņemšanas datuma" Outlook ir pirmā lieta, ko lietotāji izmēģina. Un šķiet, ka tas strādā... līdz brīdim, kad viņi saprot, ka kārtošana pēc nosūtīšanas datuma ir pieejama tikai dažām mapēm, ka tā pazūd, mainoties skatam, un ka citas lietojumprogrammas (mobilā, tīmekļa pasts, automātiskās kārtošanas noteikumi) turpina izmantot nepareizo INTERNALDATE.

Kārtošana pēc nosūtīšanas datuma nav risinājums. Tā ir plāksteris, kas slēpj simptomu, nepieskaroties reālajai problēmai. To mēs detalizēti skaidrojam rakstā Kārtošana pēc nosūtīšanas datuma nav risinājums.

Atjaunot profilu otro reizi? Tas neko nemaina, ja Outlook uzvedība atjauno kešatmiņu ar pašreizējo datumu.

Eksportēt un pēc tam reimportēt PST formātā? Uzmanību. PST eksports no Outlook ar bojātiem datumiem eksportē bojātos metadatus. PST fails saturēs nepareizos datumus. Šī faila reimports neko nelabo un var pat pasliktināt situāciju, veidojot dublētus ierakstus ar nekonsekventes datumiem. Šī tēma tiek aplūkota atsevišķā rakstā par PST importu Outlook un datumiem, kas mainās.

Ko Redate.io dara šajā konkrētajā gadījumā

Neatkarīgi no tā, vai problēma radusies IMAP migrācijas vai Outlook profila atjaunošanas dēļ, rezultāts servera pusē ir līdzīgs: e-pasti, kuru datuma metadati neatbilst to faktiskajam saturam.

Redate.io pieslēdzas tieši pastkastei (Google Workspace, Microsoft 365 vai tiešam IMAP), skenē visus ziņojumus, lai identificētu tos, kuriem ir nepareizi metadati, pēc tam piemēro savu daudzpakāpju analīzes pipeline, lai katru e-pastu labotu individuāli. Katra labojuma pareizība tiek pārbaudīta. Sākotnējie ziņojumi tiek saglabāti redzamā rezerves kopiju mapē jūsu pastkastē, kamēr jūs pats tos nedzēšat.

Process apstrādā robežgadījumus, kurus mājas skripti sistemātiski palaiž garām: S/MIME parakstīti ziņojumi, e-pasti ar ne-ASCII kodējumiem galvenēs (RFC 2047), sarežģītas multipart struktūras, Date: galvenes ar nestandarta vai deformētām laika joslām. Skripts, kas pareizi darbojas ar 50 testa e-pastiem izstrādes pastkastē, var neatgriezeniski sabojāt 2000 ziņojumus ražošanas vidē. IMAP nav natīva atgriešanās mehānisma, kad ziņojums ir aizvietots bez iepriekšējas rezerves kopijas.

Gadījumiem, kas saistīti konkrēti ar Outlook, labošanas lapa manuālās IMAP kopēšanas datumu labošana Outlook detalizēti apraksta soļus, lai savienotu pastkasti un uzsāktu analīzi.

Problēmas novēršana nākamajās intervencēs

Ja esat tehniķis vai IT administrators, kas regulāri strādā ar Outlook profiliem, daži ieradumi var palīdzēt izvairīties no šīs situācijas.

Pirms dzēšat OST failu vai atjaunojat profilu, pārbaudiet tīmekļa pastā rādītos datumus. Ja tie ir pareizi, ierakstiet to savā biļetē. Pēc atjaunošanas vēlreiz piesakieties tīmekļa pastā un salīdziniet tur rādītos datumus ar tiem, kas redzami Outlook. Ja parādās atšķirība, problēma ir uzreiz identificēta, pirms lietotājs par to sūdzas trīs dienas vēlāk.

Plānotu migrāciju gadījumā e-pasta migrācijas kontrolsaraksts uzrāda pārbaudes, kas jāveic pirms un pēc migrācijas, lai šāda veida problēmu atklātu uzreiz pēc operācijas beigām.

Vai esat atjaunojuši Outlook profilu un tagad visi jūsu pastkastes datumi ir nepareizi? Palaidiet bezmaksas skenēšanu Redate.io, lai identificētu skartās e-pasta vēstules un labotu metadatus, nepieskaroties jūsu ziņojumu saturam.