Outlook не видит новые письма после переезда: мой порядок проверки

Если после переноса Outlook не показывает новые письма, я сначала сверяю ящик в веб-почте, затем проверяю подключение клиента, сертификат и папки. Рабочий браузер ещё не доказывает исправность IMAP. Новый профиль проверяю отдельно, сохранив старый и локальные данные. Ниже — порядок, который помогает найти причину без удаления переписки.

Веб-почта работает, а Outlook молчит: что это доказывает

Я начинаю с конкретного ящика и конкретного письма. Открываю веб-почту нового сервера с рабочего компьютера, проверяю адрес учётной записи и время сообщения. При настройке корпоративной почты этот тест включаю в приёмку заранее. Если письмо видно в браузере, оно доступно в этом ящике через веб-интерфейс. Из этого нельзя вывести, что клиентский IMAP доступен из офиса, сертификат подходит для его имени, а вся история перенесена без пропусков. Один удачный вход слишком мал для такого заключения.

У браузера и Outlook могут различаться адреса подключения, способы входа и сетевой маршрут. Веб-интерфейс открывается, а служба доступа к письмам недоступна с рабочего места; или браузер уже показывает новый ящик, а клиент продолжает обращаться к старому. Поэтому я фиксирую, где именно появилось контрольное письмо: в новом веб-интерфейсе, старом ящике, клиенте или нигде. Когда известна эта точка, можно проверить нужный участок. Диагноз «сервер здоров, виноват Outlook» по одной открытой странице — медицинское заключение по обоям приёмной.

Затем провожу раздельные пробы: письмо с внешнего адреса в новый ящик и ответ из него наружу. Письмо самому себе полезно, но может остаться внутри одной системы и не проверить внешнюю доставку. Записываю время, тему и папку для каждого сообщения, проверяю получение на другой стороне. Если нового письма нет и в веб-почте, возвращаюсь к маршрутизации, очередям и журналам доставки. Если оно есть в браузере, проверяю клиентский доступ и отображение. Отсутствие письма в одном окне ещё не объясняет, на каком этапе оно задержалось.

Для разбора возьму условную компанию «Эльбрус Групп»: в примере 24 ящика, классический Outlook для Windows и новый сервер с Dovecot 2.4.5 для IMAP. Это учебный сценарий с заданными условиями. На двух пилотных компьютерах одно контрольное письмо видно в новой веб-почте, но отсутствует в Outlook. На остальных рабочих местах я пока ничего не меняю. Сначала сравню адрес сервера, тип учётной записи и состояние подключения на пилоте. Такой порядок позволяет проверить объяснение до массовой перенастройки и сохранить возможность вернуться к исходной конфигурации.

Масштаб симптома тоже полезен. Сбой у одного сотрудника направляет меня к его учётной записи, данным и настройкам; одинаковый отказ у всех заставляет проверить общие точки — адрес подключения, сертификат, службу и доступ из сети. Это рабочие гипотезы, а не доказательства. Для полноты переноса отдельно сверяю старые папки, даты и выборочные вложения: наличие свежего сообщения не подтверждает сохранность архива. Подробный порядок такой сверки после переноса почты нужен до отключения старой системы, а не после первой жалобы на пропавший договор.

• Убедиться, что открыта веб-почта нового сервера и нужный ящик.
• Раздельно проверить внешнее входящее письмо и исходящий ответ.
• Сравнить, где видно контрольное сообщение: браузер, клиент, старый ящик.
• Записать время ошибки и её полный текст до изменения настроек.

Новый профиль Outlook: как проверить и сохранить данные

Профиль Outlook — это набор учётных записей, настроек и связей с файлами данных. PST и OST нельзя называть файлами профиля и считать взаимозаменяемыми. PST может содержать самостоятельный локальный архив, а OST используется как автономное хранилище для поддерживаемых типов подключения. Прежде чем что-либо пересоздавать, я проверяю «Исходящие», локальные папки, черновики, контакты и календарь. Всё, чего нет на сервере, требует отдельного сохранения. Удалять данные в расчёте на повторное скачивание можно только после проверки, что скачивать действительно есть откуда.

Создание дополнительного профиля в классическом Outlook помогает проверить, связана ли ошибка с прежней конфигурацией. Обязательного правила «переехал сервер — удали профиль» нет: действия зависят от типа переноса и подключения. Я оставляю прежний профиль, задаю новому понятное имя и добавляю целевой ящик. Старый профиль не конфликтует с новым лишь потому, что существует рядом. Если в новой конфигурации проблема повторяется, это повод проверить другие причины. Диагностический тест ценен именно возможностью сравнить результат, а не торжественностью удаления старых настроек.

Перед тестом я записываю адреса серверов и расположение подключённых PST. Для локальных данных делаю проверяемую копию подходящим для установленной версии способом; копирование рабочих файлов выполняю при закрытом Outlook. Само удаление профиля не удаляет связанные PST с диска, что прямо описано у Microsoft, однако автономные данные могут быть удалены. И сохранённый файл ещё нужно суметь открыть и прочитать. Поэтому проверяю доступ к архиву заранее. Формула «всё уже на сервере» без сверки — удобный способ перепутать резервную копию с хорошим настроением.

После выбора другого профиля Outlook нужно закрыть и снова запустить. Этот шаг есть в экспертной базе и в инструкции Microsoft: открытое окно не переключается на другую конфигурацию само. Я проверяю, какой профиль выбран при новом запуске, затем повторяю контрольный обмен письмами. Автонастройку тоже проверяю по результату: она зависит от сервера, Autodiscover и возможностей клиента. Новый профиль сам по себе не исправляет ошибочный адрес службы обнаружения. Для IMAP может понадобиться ручной ввод параметров, которые дал администратор нового сервера.

Инструкции с выбором профиля относятся к классическому Outlook для Windows. У нового Outlook другой порядок управления учётными записями; переносить на него меню классического клиента вслепую нельзя. Я сначала уточняю приложение и его сборку, потом открываю соответствующую инструкцию. В нашем условном сценарии дополнительный профиль создаю только на пилоте. Сравниваю получение, отправку, архив и нужные папки. Лишь после успешного теста составляю порядок для остальных сотрудников. Старую конфигурацию сохраняю до завершения сверки, а не объявляю ненужной после первого доставленного письма.

IMAP, адрес сервера и таймауты: ищу место обрыва

Я сравниваю фактические параметры клиента с настройками нового сервера: имя узла, тип учётной записи, способ входа, порт и режим защиты. Для IMAP с непосредственным TLS обычно используется порт 993; этот вариант подтверждён базой и инструкцией mailcow. Но сам номер не доказывает, что именно он включён у вашего провайдера. Нельзя произвольно сочетать порт и режим шифрования. В условном примере задаю mail.example.com, IMAP, 993 и SSL/TLS. Это параметры входящего доступа; отправку проверяю отдельно по настройкам исходящей почты.

Смена MX определяет доставку почты для домена, но не переписывает сохранённый адрес IMAP в Outlook. Поэтому я смотрю, куда клиент подключается после переезда, и сверяю разрешение именно этого имени с планом миграции. Затем проверяю доступ к нужному порту с проблемного рабочего места и запись о попытке подключения в журнале сервера. Успешное открытие TCP-соединения ещё не доказывает успешный вход и чтение папок. Ошибка может возникнуть дальше — при TLS, проверке учётных данных или открытии ящика. Каждый этап проверяю отдельно, сохраняя время попытки.

В связке Postfix и Dovecot я не ищу IMAP-таймаут в настройках Postfix: это разные компоненты. Postfix обслуживает SMTP, а Dovecot может предоставлять IMAP-доступ. Документация Dovecot 2.4.5 указывает 30 минут бездействия после входа, но отдельно оговаривает активную команду IDLE: из-за одного лишь бездействия такое соединение не отключается. Это существенная поправка к совету «увеличьте idle timeout». Наличие слова timeout в журнале ещё не определяет нужный параметр. Имена настроек и их смысл сверяю с документацией установленной версии, прежде чем менять конфигурацию.

Документация Dovecot также отмечает: некоторые версии Outlook после разрыва IMAP-соединения прекращают получать новые письма до ручного вмешательства. Поэтому симптом «после ручной проверки письма появились» полезен, но сам по себе не доказывает серверный таймаут. Я сопоставляю момент остановки с журналами клиента, Dovecot и сетевого оборудования. Ищу, кто закрыл соединение, был ли повторный вход и дошёл ли он до сервера. Настройка keepalive или интервала проверки оправдана после такого сопоставления. Крутить все таймеры сразу — значит получить новые числа и потерять объяснение результата.

Если жалоба появляется только после простоя, я воспроизвожу именно простой: оставляю клиент подключённым, отправляю контрольное письмо снаружи и наблюдаю доставку без ручной проверки. После точечного изменения повторяю те же условия. Проверка сразу после запуска недостаточна: новое соединение может работать, пока не повторился исходный обрыв. В условном примере сначала исправляю старое имя сервера на пилоте и повторяю тест. Если при этом исчез симптом, оснований менять таймауты нет. Если зависание остаётся, проверка продолжается по журналам, без обещаний вылечить всё одним профилем.

• Сверить адрес, протокол, способ входа, порт и режим защиты.
• Проверить доступ с рабочего места и соответствующую попытку в журнале.
• Разделить сбой соединения, TLS, авторизации и открытия папки.
• После изменения повторить исходный сценарий, включая простой.

Ошибка сертификата: исправляю доверие и имя подключения

Смена сертификата не означает, что Outlook обязан запомнить прежний отпечаток и отвергнуть новый. Я начинаю с текста предупреждения и адреса, к которому обращается клиент. Проверяю срок действия, имя сервера в сертификате и доверие к цепочке выдачи. Отдельно сверяю часы рабочего компьютера. Ошибка имени, истёкший срок и неизвестный издатель требуют разных действий. Совет «импортируйте сертификат, потому что сервер переехал» пропускает саму диагностику. Предупреждение безопасности — полезное сообщение о проверке подключения; превращать его в надоедливую заставку не стоит.

В документации Microsoft описан конкретный случай: Autodiscover направляет Outlook к узлу, ожидаемое имя которого отсутствует в сертификате. Значит, я проверяю не только имя IMAP в настройках, но и фактическую точку автообнаружения, если клиент ею пользуется. Правильный пароль такую ошибку не исправляет. Сертификат должен подходить тому имени, с которым устанавливается защищённое соединение. В условном сценарии mail.example.com требуется проверить именно на почтовом подключении. Сертификат, показанный браузером на другом имени веб-почты, ещё ничего не говорит об этом узле.

Если сервер использует сертификат публичного центра, я проверяю, отдаёт ли нужная служба корректный сертификат с необходимой цепочкой. Для внутреннего центра доверие распространяется управляемо, после проверки его происхождения и назначения. Случайный сертификат сервера нельзя объявлять доверенным корневым только ради исчезновения ошибки. Самоподписанный сертификат тоже не освобождает от проверки имени и срока. Сначала устанавливаю, какая модель доверия предусмотрена в этой системе, затем исправляю её. Кнопка согласия быстро убирает предупреждение, но не делает чужое имя своим.

После миграции веб-интерфейс и почтовая служба могут отдавать разные сертификаты. Поэтому проверяю тот сервис и то имя, которые использует Outlook, а затем повторяю проверку с рабочего компьютера. Если установлен локальный компонент, который проверяет защищённый почтовый трафик, учитываю и его участие в цепочке. Удачный тест с административной машины не заменяет пользовательский: настройки доверия могут различаться. Для случая, когда веб-почта уже обновилась, а клиент продолжает получать старый сертификат, есть отдельный разбор сертификата на почтовой службе.

Исправление принимаю только после повторного подключения без необъяснённых предупреждений. Записываю, что именно изменили: имя службы, выдаваемый сертификат, промежуточную цепочку или управляемое доверие к внутреннему центру. Если причина связана с возможностями устаревшего клиента, проверяю совместимость его конкретной сборки с сервером; не приписываю отказ любому «старому Outlook». Массовый импорт и отключение проверки сертификатов в мой порядок восстановления не входят. Они скрывают симптом, мешают понять причину и оставляют следующую смену сертификата той же незаконченной работой.

Письма появились, календарь пуст: проверяю тип подключения

Получение писем по IMAP не доказывает перенос календаря и контактов: этот протокол решает задачи доступа к почтовым папкам. Если после переезда учётную запись подключили как IMAP, прежние возможности групповой работы не возникают автоматически. Я уточняю, где хранились встречи и адресная книга, чем их переносили и каким способом клиент должен обращаться к ним теперь. Пустой календарь может означать отсутствие переноса, неподходящий тип подключения или неправильное сопоставление папки. Пересоздание профиля без этих ответов просто создаст ещё один аккуратно настроенный пустой календарь.

Exchange ActiveSync поддерживает работу с почтой, календарём, контактами и задачами на совместимых мобильных устройствах — это подтверждено экспертной базой и Microsoft. Но утверждение «без ActiveSync мобильная почта невозможна» неверно: для писем может использоваться IMAP, а для других данных — поддерживаемые клиентом способы синхронизации. Я выбираю способ под возможности сервера и приложения, проверяю права и предусмотренную схему входа. Слово Exchange в названии учётной записи ещё не доказывает, что выбранный клиент поддерживает все нужные функции конкретной серверной реализации.

Для mailcow документация отдельно описывает классический Outlook с CalDav Synchronizer для календарей и контактов. Там же подключение настольного Outlook через ActiveSync помечено как нерекомендуемое, а инструкция с дополнением не подходит новому Outlook. Поэтому обещание «включим ActiveSync, и всё появится на любом Outlook» я убираю из плана. До переключения сотрудников проверяю совместимость конкретного приложения, дополнения и сервера. Различия клиентов разобраны в статье про календари в новом Outlook; здесь мне важен выбор правильной ветки диагностики после получения писем.

На телефоне я сначала проверяю серверные копии встреч и контактов, затем параметры учётной записи и разрешения приложения. Удалять старую запись до сохранения уникальных локальных данных нельзя: часть информации может существовать только на устройстве. Вместо универсального совета «проверьте службу ActiveSync» смотрю документацию конкретного решения и журнал нужной точки доступа. Отдельного системного сервиса с одинаковым именем у всех почтовых платформ нет. Если вход не проходит, разбираю его причину; если вход успешен, а события не обновляются, перехожу к выбранным календарям и направлению синхронизации.

Приёмку провожу в обе стороны. Создаю тестовую встречу в веб-интерфейсе, проверяю её в клиенте, затем меняю в клиенте и проверяю изменение на сервере. Для контакта повторяю такую же проверку отдельно. Личные и общие ресурсы не смешиваю: доступ к личному календарю не подтверждает права на общий. В условном сценарии результат по календарям фиксирую отдельной строкой после успешной почты. Это защищает от ложного завершения работ, когда новые письма уже видны, а встречи по-прежнему живут в старой системе или только на одном устройстве.

• Проверить наличие встреч и контактов на новом сервере.
• Уточнить поддержку нужного подключения установленным приложением.
• Сохранить локальные данные до удаления учётной записи на устройстве.
• Проверить создание и изменение событий в обе стороны.

Письмо доставлено, но его не видно: папки и приёмка

Если вход работает, я ищу контрольное сообщение по теме, отправителю и времени в веб-почте и во всех доступных папках клиента. Проверяю архив, удалённые, нежелательную почту и ограничения текущего представления: например, показ только непрочитанных сообщений. Письмо могло оказаться в другой папке или не попасть в выбранное представление. Сначала устанавливаю его фактическое местоположение, затем меняю настройки. Наличие сообщения в нежелательной почте не объясняет само по себе, кто его туда переместил. Клиентское правило и решение серверного фильтра требуют разных исправлений.

Для IMAP отдельно проверяю список папок и подписки. Microsoft описывает получение списка серверных папок и выбор тех, которые должны отображаться в классическом Outlook. Поэтому «папка есть в браузере, но отсутствует в клиенте» не равно «папку не перенесли». Сверяю полное имя и вложенность: после миграции могла появиться другая структура. Не задаю наугад корневой путь папок из чужой инструкции. Изменение такого параметра должно соответствовать устройству конкретного сервера. Иначе попытка вернуть архив легко превращается в новый спор о том, где теперь находятся «Отправленные».

Правила проверяю на сервере и в клиенте, сохранив исходные условия и порядок выполнения. Для теста временно отключаю конкретное подозрительное правило и отправляю новое контрольное письмо; меняю один элемент за раз. Общий антиспам не выключаю ради диагностики одного перемещения. Смена почтового хостинга сама по себе не меняет домен отправителя каждого входящего письма: объяснять этим любое попадание в спам нельзя. Смотрю заголовки и журнал обработки конкретного сообщения. Рассуждение «переехали, значит фильтр всё испортил» звучит уверенно ровно до первого запроса доказательств.

Вернусь к заданному сценарию «Эльбрус Групп». На двух пилотных компьютерах порядок такой: сохраняю локальные данные, проверяю правильный узел IMAP и TLS, запускаю дополнительный профиль, сверяю папки. Допустим, после исправления старого адреса на mail.example.com с портом 993 и SSL/TLS контрольные письма появляются автоматически. Тогда итог примера — подтверждена ошибочная точка подключения, удаление старых профилей и увеличение таймаутов не потребовались. Это условный результат для заданных условий, а не обещание такого же диагноза любому офису. Для остальных 22 ящиков повторяю проверенный порядок с индивидуальной сверкой данных.

Работу считаю завершённой после проверки входящей и исходящей почты, появления сообщений после простоя, доступа к нужным архивам и отдельных результатов по календарям. Проверяю также продолжение доставки в старую систему, если она ещё участвует в переходе. Фиксирую найденную причину, изменения, результаты повторного теста и способ отката. Срок отключения старого сервера назначаю по завершённой сверке и согласованному плану. Совет «понаблюдать до завтра» без контрольных условий ничего не принимает: завтра можно с тем же успехом наблюдать вчерашнюю ошибку. Мне нужен воспроизводимый результат и понятная ответственность за оставшиеся проверки.

Частые вопросы