Перенос почты с Exchange на Linux выполняется в три шага: разворачивается почтовая система на серверах под Linux, к ней подключается служба каталогов с учётными записями, после чего содержимое ящиков (письма, календари, контакты, задачи, публичные папки) копируется с Exchange через IMAP, MAPI/EWS или импорт PST-файлов. Для крупных инсталляций перенос делают волнами, включая режим сосуществования: часть пользователей уже на новой системе, часть остаётся на Exchange, а маршрутизация писем и свободно/занято работают между ними. Полностью «за одну ночь» переезжают обычно организации до нескольких сотен ящиков — дальше почти всегда нужен поэтапный сценарий.
Что переносить и чем
Сначала стоит разделить данные на три категории: содержимое ящиков, объекты каталога и конфигурацию транспорта. Учётные записи, группы рассылки и контакты чаще берут напрямую из Active Directory или LDAP — многие серверные почтовые платформы под Linux умеют одновременно работать с несколькими службами каталога, поэтому AD можно оставить как источник учётных данных и не заводить пользователей заново.
Содержимое ящиков переносят одним из способов:
- IMAP-синхронизация (imapsync и аналоги) — надёжно для писем и структуры папок, но календари, задачи и контакты через IMAP не передаются.
- EWS/MAPI-коннектор — переносит календарные события, приглашения, повторяющиеся встречи, контакты и делегирование. Именно этот путь используют встроенные миграторы отечественных почтовых систем.
- Экспорт в PST через New-MailboxExportRequest с последующим импортом. Годится для архивных ящиков и уволенных сотрудников, но на больших объёмах медленный.
Публичные папки — отдельная история: их структура в Exchange не всегда имеет прямой аналог, часто их превращают в общие ящики или в папки с разделяемым доступом. Иногда, но не всегда, часть публичных папок вообще оказывается заброшенной, и перед миграцией их проще удалить, чем переносить.
Порядок работ и режим сосуществования
Практическая последовательность выглядит так. Разворачивается кластер: два и более узла с распределённым почтовым хранилищем, чтобы отказ одного сервера не останавливал приём почты. Подключается каталог, проверяется аутентификация, настраивается транспорт — SPF, DKIM, DMARC, реле для приложений и МФУ. Затем прогоняется тестовая волна: 5–10 ящиков разных типов (руководитель с делегатами, секретарь с общим календарём, ящик с большим архивом).
После тестовой волны MX-запись или маршрутизация внутри домена переключается так, чтобы новая система стала точкой входа, а письма для ещё не перенесённых пользователей пересылались на Exchange. Такой режим сосуществования держат от нескольких дней до нескольких месяцев — тут всё зависит от числа ящиков и от того, сколько интеграций завязано на Exchange.
Главный риск миграции — не потеря писем, а рассинхронизация календарей: приглашения, отправленные из Outlook на старом сервере, могут не попасть в новый календарь пользователя. Поэтому календари переносят последними, максимально близко к моменту переключения ящика.
Клиентские приложения — второй по частоте источник проблем. Хорошая новость: полная поддержка MS Outlook и других распространённых почтовых клиентов реализована в ряде решений через собственный коннектор или ActiveSync, так что пользователю не приходится менять привычный интерфейс. Проверить это стоит заранее — на версиях Outlook, реально установленных в компании. Такую совместимость, работу в кластере и встроенные средства миграции с Exchange заявляют почтовые сервера российского производства, и почтовые сервера российского производства в этом смысле удобны тем, что режим сосуществования у них предусмотрен штатно. Подробнее можно узнать на сайте разработчика.
Администрирование после переезда
Ролевая модель администрирования разгружает основную команду: помощнику службы поддержки достаточно прав на сброс пароля и просмотр очереди, а операции с хранилищем остаются у инженеров. Готовые шаблоны конфигураций ускоряют развёртывание типовых узлов и позволяют быстро вернуть рабочее состояние сервера после неудачного изменения — восстановление из шаблона обычно быстрее, чем ручной разбор конфигов.
Старый Exchange не выключают сразу. Разумно оставить его в режиме только для чтения, пока не пройдёт хотя бы один полный цикл отчётности и не закроются вопросы по недостающим письмам.
Что делать, если после миграции пропали письма или не работает календарь
- Сверьте количество объектов. Сравните число писем в каждой папке на источнике и приёмнике до отключения Exchange — большинство миграторов ведут лог с расхождениями по каждому ящику.
- Проверьте лимиты. Письма с вложениями больше разрешённого размера на новом сервере не переносятся молча — они попадают в отчёт об ошибках. Временно поднимите лимит и повторите перенос только для проблемных ящиков.
- Повторный прогон дельты. IMAP-синхронизацию и EWS-перенос можно запускать повторно: инструменты сверяют идентификаторы сообщений и докачивают только новое, не создавая дублей.
- Календари. Если встречи не отображаются, выгрузите календарь в ICS из Outlook, подключённого к старому серверу, и импортируйте в новый. Повторяющиеся события с исключениями переносятся хуже всего — их иногда проще пересоздать.
- Делегирование и общие ящики. Права доступа почти никогда не мигрируют автоматически в полном объёме. Составьте список пар «владелец — делегат» до переезда и восстановите их вручную.
- Автозаполнение адресов. Кэш получателей в Outlook хранит старые X500-адреса, из-за чего письма коллегам «отбиваются». Очистка кэша автодополнения решает это за минуту.
Если после переключения объём недоставленной почты растёт, верните MX на прежнее значение — очередь на новом сервере при этом сохранится и будет доставлена после устранения причины.
