Gekasde Outlook-pos maak oop, maar niks sinchroniseer: wat om te kontroleer

Ou pos maak oop, die vouergids lyk normaal, en ’n boodskap wat vanoggend gestuur is, verlaat nooit die Outbox nie. Dié kombinasie sê die plaaslike kas is in orde en die verbinding met Exchange is nie, en dit is die mees verkeerd geleesde simptoom in hierdie hele gebied. Niks het ineenstort nie, en daarom kom die verslag gewoonlik as Outlook wat stadig is eerder as Outlook wat ontkoppel is.

Werk die kontroles in volgorde, en let eers op watter Outlook-bou jy kyk, want die kontroles verskil.

Bevestig watter kliënt en watter soort rekening

Klassieke Outlook vir Windows, die nuwe Outlook en Outlook op die web is drie verskillende kliënte met drie verskillende verbindingspaaie, en advies vir een is dikwels verkeerd vir ’n ander. Binne klassieke Outlook gedra ’n Exchange-rekening en ’n POP- of IMAP-rekening hulle anders wanneer die bediener onbereikbaar is, want net die Exchange-rekening het ’n MAPI-vervoer en ’n gekasde posbusstoorkas. Identifiseer die rekeningtipe in die rekeninginstellings voordat jy enige status interpreteer. ’n Regstelling wat uit ’n IMAP-opstelling gekopieer is, sal nie ’n Exchange-verbinding beskryf nie.

Skryf die kliënt se naam en weergawe neer. Ondersteuningsdrade meng dit gereeld, en die skermbeelde hou halfpad op om te pas.

Lees die verbindingstatus terwyl dit misluk

Met klassieke Outlook aan die gang, hou Ctrl en regskliek op die kennisgewingarea-ikoon, en maak dan Connection Status oop. Doen dit tydens die mislukkende bewerking eerder as ná ’n herbegin, want die aansig rapporteer wat die kliënt op daardie oomblik probeer. Teken die bedienernaam, die protokol en die toestand aan, en vergelyk dan daardie bediener met wat jy verwag die rekening moet gebruik. Microsoft se diagnostiese leiding dek hierdie aansig en die meer gedetailleerde logboeke wat jy kan insamel wanneer die opsomming nie genoeg is nie.

Moderne Exchange-ontplooiings dra Outlook-verkeer oor MAPI over HTTP, so om SMTP-inhandigingspoorte oop te maak is nie ’n herstelling vir ’n posbusverbinding nie. As vervoer die diens bereik, hou die HTTP- of verifikasiefout en werk aan daardie stadium eerder as om ’n wagwoord terug te stel wat nooit die probleem was nie.

Vergelyk die eindpunt met die blaaier se pad

’n Werkende web-posbus bewys dat ’n blaaier een eindpunt deur een naam en een instaanbediener-konfigurasie kan bereik. Dit bewys nie dat Outlook dieselfde adres opgelos het, dieselfde roete gebruik het of dieselfde sertifikaat aanvaar het nie. Met ’n VPN in plek kan gesplete DNS die Outlook-naam na ’n interne adres stuur terwyl die blaaier ’n publieke een gebruik, en daardie verskil alleen verklaar ’n werkende websessie langs ’n stukkende kliënt. Vergelyk die opgeloste adres, die gekose roete en die TLS-identiteit op beide paaie.

Administratiewe portale en afgeleë PowerShell is nie plaasvervangers vir ’n gebruiker-posbustoets nie, want dit is verskillende dienste met verskillende verifikasie.

Toets die kas teen ’n nuwe bewerking

Cached Exchange Mode hou ’n plaaslike kopie en sinchroniseer met die bediener, wat dit verdraagsaam maak teen onderbreking en dit nie onafhanklik van die bediener maak nie. Om ’n ou gekasde boodskap te lees is nie ’n netwerktoets nie, en die Work Offline-skakelaar ook nie. Stuur ’n nuwe boodskap of forseer ’n sinchronisasie en kyk na daardie spesifieke bewerking. As klein uitruilings slaag terwyl groot oordragte vasdraai, verdien pakketgrootte en pad-MTU die aandag, met bewyse wat uit die mislukkende bewerking geneem is.

Om die kastipe te verander kan die simptoom verskuif sonder om die roete of die diens te herstel.

Herhaal ná enige ondersteunde regstelling die oorspronklike bewerking en bevestig dat nuwe data die bediener bereik en terugkom. Teken daardie resultaat apart aan van die gerief om pos te lees wat al op skyf was.