Kaŝmemorigita Outlook-poŝto malfermiĝas, sed nenio sinkroniziĝas: kion kontroli

Malnova poŝto malfermiĝas, la dosieruja listo aspektas normala, kaj mesaĝo sendita ĉi-matene neniam forlasas la Elsendujon. Tiu kombino diras, ke la loka kaŝmemoro bone funkcias kaj la konekto al Exchange ne, kaj ĝi estas la plej mislegata simptomo en ĉi tiu tuta kampo. Nenio kraŝis, kaj tial la raporto kutime alvenas kiel malrapida Outlook, ne kiel malkonektita Outlook.

Faru la kontrolojn laŭvicaj, kaj antaŭ ĉio notu, kiun Outlook-version vi rigardas, ĉar la regiloj malsamas.

Konfirmu, kiu kliento kaj kiu kontotipo

Klasika Outlook por Windows, la nova Outlook kaj Outlook en la reto estas tri malsamaj klientoj kun tri malsamaj konektovojoj, kaj konsilo por unu ofte malĝustas por la alia. En klasika Outlook, Exchange-konto kaj POP- aŭ IMAP-konto kondutas malsame kiam la servilo estas neatingebla, ĉar nur la Exchange-konto havas MAPI-transporton kaj kaŝmemorigitan retkestan konservejon. Identigu la kontotipon en la kontagordoj antaŭ ol interpreti ajnan staton. Riparo kopiita el IMAP-agordo ne priskribos Exchange-konekton.

Notu la nomon kaj version de la kliento. Subtenaj fadenoj rutine miksas ilin, kaj la ekrankopioj ĉesas kongrui duonvoje.

Legu la konektan staton dum ĝi malsukcesas

Dum klasika Outlook funkcias, tenu Ctrl kaj dekstre alklaku la ikonon de la sciiga areo, poste malfermu Connection Status. Faru tion dum la malsukcesa operacio, ne post restartigo, ĉar la vido raportas, kion la kliento provas en tiu momento. Notu la servilan nomon, la protokolon kaj la staton, poste komparu tiun servilon kun tiu, kiun vi atendas, ke la konto uzu. La diagnozaj gvidlinioj de Microsoft kovras ĉi tiun vidon kaj la pli detalajn protokolojn, kiujn vi povas kolekti kiam la resumo ne sufiĉas.

Modernaj Exchange-ekspedoj portas Outlook-trafikon per MAPI over HTTP, do malfermi SMTP-sendajn pordojn ne estas riparo por retkesta konekto. Se la transporto atingas la servon, konservu la HTTP- aŭ aŭtentikigan eraron kaj laboru pri tiu stadio anstataŭ restarigi pasvorton, kiu neniam estis la problemo.

Komparu la finpunkton kun la vojo de la retumilo

Funkcianta reta retkesto pruvas, ke retumilo povas atingi unu finpunkton per unu nomo kaj unu prokura agordo. Ĝi ne pruvas, ke Outlook solvis la saman adreson, uzis la saman itineron aŭ akceptis la saman atestilon. Kun VPN en loko, dividita DNS povas sendi la Outlook-nomon al interna adreso dum la retumilo uzas publikan, kaj tiu diferenco sole klarigas funkciantan retan sesion apud rompita kliento. Komparu la solvitan adreson, la elektitan itineron kaj la TLS-identecon sur ambaŭ vojoj.

Administraj portaloj kaj fora PowerShell ne anstataŭas teston de uzanta retkesto, ĉar ili estas malsamaj servoj kun malsama aŭtentikigo.

Testu la kaŝmemoron per freŝa operacio

Cached Exchange Mode tenas lokan kopion kaj sinkroniziĝas kun la servilo, kio igas ĝin tolerema al interrompo kaj ne igas ĝin sendependa de la servilo. Legi malnovan kaŝmemorigitan mesaĝon ne estas reta teststemo, kaj la ŝaltilo Work Offline ankaŭ ne. Sendu novan mesaĝon aŭ devigu sinkronizadon kaj observu tiun specifan operacion. Se malgrandaj interŝanĝoj sukcesas dum grandaj transigoj haltas, paketa grando kaj la MTU de la vojo meritas atenton, kun pruvoj prenitaj el la malsukcesa operacio.

Ŝanĝi la kaŝmemoran reĝimon povas movi la simptomon sen ripari la itineron aŭ la servon.

Post ajna subtenata korekto, ripetu la originan operacion kaj konfirmu, ke freŝaj datumoj atingas la servilon kaj revenas. Notu tiun rezulton aparte de la komforto legi poŝton, kiu jam estis sur la disko.