Кешована пошта в Outlook відкривається, але нічого не синхронізується: що перевірити

Стара пошта відкривається, список тек виглядає нормально, а повідомлення, надіслане сьогодні вранці, так і не залишає теку «Вихідні». Це поєднання говорить про те, що локальний кеш у порядку, а з'єднання з Exchange ні, і це найчастіше неправильно зрозумілий симптом у всій цій галузі. Нічого не впало, тому звіт зазвичай надходить як «Outlook повільний», а не як «Outlook відключений».

Виконуйте перевірки по черзі й насамперед запишіть, яку збірку Outlook ви бачите, бо елементи керування різняться.

Визначте, який клієнт і який тип облікового запису

Класичний Outlook для Windows, новий Outlook і Outlook у вебі — це три різні клієнти з трьома різними шляхами підключення, і порада для одного часто хибна для іншого. У класичному Outlook обліковий запис Exchange і обліковий запис POP або IMAP поводяться по-різному, коли сервер недоступний, бо лише обліковий запис Exchange має транспорт MAPI і кешоване сховище поштової скриньки. Визначте тип облікового запису в налаштуваннях, перш ніж тлумачити будь-який стан. Виправлення, скопійоване з налаштування IMAP, не описує підключення Exchange.

Запишіть назву й версію клієнта. У темах підтримки їх постійно плутають, і знімки екрана перестають збігатися на півдорозі.

Прочитайте стан підключення під час збою

Коли класичний Outlook працює, утримуйте Ctrl і клацніть правою кнопкою піктограму в області сповіщень, потім відкрийте «Стан підключення». Робіть це під час невдалої операції, а не після перезапуску, бо подання показує, що клієнт намагається зробити в цей момент. Запишіть ім'я сервера, протокол і стан, потім порівняйте цей сервер з тим, який, на вашу думку, використовує обліковий запис. Діагностичні настанови Microsoft охоплюють це подання й докладніше журналювання, яке можна зібрати, коли зведення недостатньо.

Сучасні розгортання Exchange передають трафік Outlook через MAPI over HTTP, тому відкриття портів надсилання SMTP не є ремонтом підключення поштової скриньки. Якщо транспорт досягає служби, збережіть помилку HTTP або автентифікації і працюйте на цьому етапі, замість скидати пароль, який ніколи не був проблемою.

Порівняйте кінцеву точку з шляхом браузера

Робоча вебпоштова скринька доводить, що браузер може досягти однієї кінцевої точки через одне ім'я й одну конфігурацію проксі. Вона не доводить, що Outlook розв'язав ту саму адресу, використав той самий маршрут або прийняв той самий сертифікат. За наявності VPN розділений DNS може надсилати ім'я Outlook на внутрішню адресу, тоді як браузер використовує публічну, і сама ця різниця пояснює робочий вебсеанс поряд зі зламаним клієнтом. Порівняйте розв'язану адресу, вибраний маршрут і ідентичність TLS на обох шляхах.

Адміністративні портали й віддалений PowerShell не замінюють перевірку поштової скриньки користувача, бо це різні служби з різною автентифікацією.

Перевірте кеш новою операцією

Режим Exchange з кешуванням зберігає локальну копію й синхронізується із сервером, що робить його стійким до перерв і не робить незалежним від сервера. Читання старого кешованого повідомлення не є перевіркою мережі, як і перемикач «Працювати автономно». Надішліть нове повідомлення або примусово запустіть синхронізацію й спостерігайте саме цю операцію. Якщо невеликі обміни вдаються, а великі передавання застрягають, розмір пакета й MTU маршруту варті уваги, з доказами, взятими з невдалої операції.

Зміна режиму кешу може перемістити симптом, не виправивши маршрут або службу.

Після будь-якого підтримуваного виправлення повторіть початкову операцію й переконайтеся, що нові дані доходять до сервера й повертаються. Запишіть цей результат окремо від зручності читати пошту, яка вже була на диску.