Миграция с Microsoft Exchange на RuPost 4.2: план перехода без потери почты и простоев

Миграция Exchange на RuPost 4.2 — это поэтапный перенос корпоративной почты с сохранением непрерывности сервиса за счёт параллельного запуска систем и настройки двойной доставки. Переход позволяет заменить зарубежную инфраструктуру на отечественное решение без потери писем, календарей и контактов.

Для российских компаний отказ от Microsoft Exchange становится вопросом не только импортозамещения, но и контроля над данными в соответствии с 152-ФЗ «О персональных данных». Ключевой риск проекта — простой бизнес-процессов при переключении DNS-записей. Новая версия RuPost 4.2.0 снижает эти риски благодаря встроенным механизмам геокластеризации и оптимизации очередей, что делает плановый переход предсказуемым и безопасным для ИТ-инфраструктуры.

RuPost 4.2 — выпуск корпоративной почты от «Группы Астра», в котором ключевые изменения касаются геокластеризации, транспортных правил и производительности ядра, и именно эти изменения снижают риски миграции Exchange на RuPost 4.2 для компаний с распределённой инфраструктурой. Компания «РуПост» выпустила новую версию корпоративного почтового сервера RuPost 4.2.0, и для проекта миграции с Exchange это означает другой набор возможностей, который стоит учесть ещё на этапе проектирования.

Главное для нас как инженеров — появление сайтов типа «Резервный» в геокластере. В версии RuPost 4.2.0 появилась возможность создавать в геокластере сайты специального типа «Резервный», которые реплицируют данные пользовательских ящиков и локальные настройки. Для компаний, которые уходят с Exchange и привыкли к DAG (Database Availability Group), это ближайший аналог по назначению, но с важными отличиями. Резервный сайт работает «зеркалом» основного, а переключение на него выполняет администратор вручную, с правкой записей DNS. Базы данных реплицируются раз в 60 минут, поэтому при переключении можно потерять почту за последний час, а архивы и записи (records) на резервный сайт не реплицируются. DAG переключает базы автоматически — это различие стоит заложить в план аварийного восстановления.

Второе изменение, которое снимает типичную боль при расследовании инцидентов после переноса пользователей, — сквозной поиск. В RuPost 4.2.0 реализован сквозной поиск сообщений по всем сайтам геокластера сразу. На практике это значит, что когда администратор ищет письмо после миграции, он не привязан к конкретной площадке и не прыгает между консолями — ровно та задача, которую в локальном Exchange решает поиск In-Place eDiscovery в EAC.

Третий блок — производительность и управляемость. В RuPost 4.2.0 ядро компонента почтовых очередей перенесено в оперативную память, что ускорило обработку почты. В одноузловой установке с локальным диском очереди остаются на диске, так что выигрыш получает кластерная конфигурация. Это особенно важно в день X, когда через новую систему проходит пиковый трафик — одновременные доставки от Exchange по dual-delivery, перенос ящиков инструментом миграции и обычная рабочая переписка. Чем выше запас по очередям, тем мягче пройдёт переключение MX.

Отдельно отметим упрощение архитектуры. В RuPost 4.2.0 функции сервера кеширования выполняет один из узлов кластера, а при его выходе из строя перенастройка происходит автоматически. Для проектов миграции это минус один компонент в схеме, минус отдельная ВМ и минус отдельная точка отказа — прежние версии RuPost требовали для кластера отдельный сервер rupost-cs (Memcached), и спланировать параллельный запуск становится проще.

Для миграции Exchange на RuPost 4.2 это складывается в единый вывод: у привычных блоков Exchange — DAG, поиска по всем ящикам и правил транспорта — в RuPost 4.2 есть собственные аналоги: резервный сайт, сквозной поиск и транспортные правила. Аналоги не полные: резервный сайт переключают вручную, и это нужно учесть в проекте.

Планирование миграции с Exchange на RuPost начинается с инвентаризации почтовой инфраструктуры: точный список ящиков, их размеры, календари, делегирования, публичные папки, правила Outlook и журналы — именно эти объекты определяют трудоёмкость проекта, а не версия сервера-источника. Без письменного аудита любая оценка сроков превращается в гадание, а любой «день X» — в источник потерянных писем.

Первый артефакт дорожной карты — таблица ящиков. На каждый ящик фиксируем владельца, объём, тип (user/shared/resource/room), количество делегатов и наличие правил пересылки. Отдельная строка — публичные папки: в Exchange они нередко разрастаются годами, и перенос «как есть» не всегда оправдан, часто дешевле заменить их общими ящиками. По итогу аудита становится видно, какие ящики требуют индивидуального подхода (руководители, бухгалтерия, юристы), а какие уйдут в пакетные волны по 20–50 штук.

Второй артефакт — карта интеграций. Exchange редко стоит в вакууме: с ним связаны Active Directory, ActiveSync-клиенты на телефонах, многофункциональные устройства, отправляющие сканы по SMTP, CRM и 1С с модулями уведомлений, антиспам-шлюз (нередко KSMG), архивный сервис, система журналирования. Для каждой интеграции в карте указываем протокол (SMTP, IMAP, EWS, MAPI), учётную запись и критичность. На этом этапе становится понятно, что часть интеграций придётся перенастраивать параллельно с ящиками, и это закладывается в календарный план.

Третий артефакт — реестр DNS-записей и сертификатов. MX, Autodiscover, SPF, DKIM, DMARC, PTR на выходящем IP, TLS-сертификаты на SMTP и веб-клиент — всё это фиксируем с текущими TTL. Снижение TTL на MX до минимума за 48 часов до переключения — простая процедура, которую легко забыть, и платить за это приходится лишним окном переадресации в день X.

Дорожная карта по итогам аудита складывается в четыре фазы: подготовка инфраструктуры RuPost 4.2 и тестовая миграция пилотной группы, параллельный запуск с dual-delivery, волновая миграция ящиков, переключение MX и Autodiscover. Для каждой фазы — критерий выхода, а не только дата: пилот считается пройденным, когда 10–15 ящиков работают в RuPost неделю без обращений, параллельный запуск — когда почта доставляется в оба адресата без расхождений.

Собирательный пример по нашим проектам, детали изменены: для компании на 200 ящиков с 4 ТБ почтовой базы аудит занимает 3–5 рабочих дней, карта интеграций — ещё 2 дня, итоговая дорожная карта согласуется на четвёртой неделе проекта. Эти сроки — не маркетинг, а время, которого реально хватает, чтобы потом не ловить сюрпризы в день X.

Параллельный запуск Exchange и RuPost 4.2 — это режим, при котором оба сервера принимают почту для одного домена, а пользователи постепенно переезжают с одного на другой без общей точки отказа и без простоя. Схема строится на двух принципах: входящая почта доходит до адресата в любом из серверов, а исходящая почта из обоих серверов проходит одинаковую проверку SPF/DKIM/DMARC.

Классическая схема сосуществования — Exchange остаётся «мастером» на период миграции, а RuPost 4.2 подключается как смежный почтовый сервер. MX продолжает смотреть на пограничный шлюз или напрямую на Exchange, а для связи с Exchange у RuPost есть штатный шаблон конфигурации «Интеграция RuPost с Microsoft Exchange» (только в редакции Enterprise): на Exchange настраивается Receive Connector, принимающий почту от узла RuPost, а RuPost регистрируется в Exchange как Send Connector типа Smart Host. Внешнюю почту RuPost отправляет через релей; если отдельного релея нет, эту роль выполняет Exchange. На Exchange для перенесённых пользователей отключается локальный почтовый ящик, а вместо него заводится почтовый пользователь (mail user) с внешним адресом на RuPost — таким образом внутренняя почта автоматически маршрутизируется в новую систему.

Dual-delivery (двойная доставка) — отдельная тактика, применимая на пике миграции. Для группы пользователей, которые уже работают в RuPost, но ещё не отключены от Exchange, настраивается правило: входящее письмо копируется в оба ящика. Это даёт обратимость: если после переключения часть писем «не долетела» или пользователь обнаружил проблему с клиентом, вторая копия письма лежит на старом сервере и доступна для расследования. Правило включается на уровне транспортного агента Exchange (Transport Rule с действием BCC) или на уровне внешнего SMTP-релея, если такой есть в инфраструктуре. Пока ящик в RuPost находится в статусе «Миграция», почту по SMTP он не принимает — так штатный инструмент миграции исключает дубли, поэтому двойную доставку включают для уже перенесённых ящиков.

Важная деталь — SPF и DKIM для исходящего трафика. Пока оба сервера отправляют почту, в SPF-записи домена должны быть перечислены IP обоих, а DKIM-подписи должны валидироваться для доменов отправителей на обоих серверах. Иначе часть писем начнёт попадать в спам у получателей, и причину будут искать в самой миграции, хотя на деле это элементарная ошибка DNS.

Отдельно обрабатываются общие ящики, календари и ресурсы (переговорные). В период сосуществования они живут только в одной системе — обычно продолжают оставаться в Exchange до своей волны миграции. Поэтому владельцев общего календаря и тех, кто с ним работает, удобнее переносить одной волной.

Параллельный режим — не постоянное решение, а окно, обычно от 2 до 6 недель. Как только все пользователи переведены и dual-delivery отработал, схема переходит в финальную фазу: MX переключается на RuPost, Exchange остаётся принимающим только для разбора «хвостов» и журнальных писем.

Основной путь переноса — штатный инструмент миграции RuPost (RuPost Migration Tool). С версии 2.5.0 у него есть веб-панель, в которой настраивают, запускают и контролируют перенос почтовых ящиков, календарей и адресных книг из Microsoft Exchange; открывается она кнопкой «Миграция» на странице «Почтовые ящики» панели управления RuPost. На время переноса инструмент ставит ящику статус «Миграция»: ящик доступен по IMAP, но не принимает почту по SMTP, поэтому письма не дублируются, а по окончании статус сам меняется на «Активен». Пользователь всё это время работает в Exchange и может зайти в новый ящик, чтобы проверить, как идёт перенос.

Запасной путь для рядовых ящиков — IMAP и IMAPSync. Включаем IMAP на Exchange, если он отключён, выдаём миграционной учётной записи право FullAccess на переносимые ящики (Add-MailboxPermission) и запускаем IMAPSync параллельными потоками по 5–10 ящиков. Папки переносятся с сохранением структуры, флаги прочитано/непрочитано сохраняются, но календари и контакты IMAP не копирует — это ограничение протокола, а не инструмента. Их переносит штатный инструмент миграции.

Выгрузка в PST нужна прежде всего для архивной копии на стороне Exchange. Её делает командлет New-MailboxExportRequest (документация Microsoft): ему нужна роль Mailbox Import Export, которая по умолчанию не назначена никому, а PST-файл он записывает в сетевую папку по UNC-пути. Рабочий перенос строим на инструменте миграции, а PST оставляем для архива.

Календари и контакты требуют отдельного внимания. В Exchange календарь — это специальный тип элементов в ящике со своими разрешениями (Reviewer, Editor, Delegate). Календари и адресные книги переносит инструмент миграции, а права доступа к общим календарям и делегирования после переноса стоит проверить на стороне RuPost. Корпоративную адресную книгу (GAL) RuPost формирует автоматически из подключённой службы каталогов, в том числе Active Directory, — переносить её не нужно.

Кейс IT For Prof: на проекте для юридической компании «Альтер-2» мы перенесли 200 почтовых ящиков с VK Workspace на собственный сервер Selectel: 4 ТБ данных, ноль потерянных писем (подробный разбор проекта). Ежемесячные расходы снизились с 92 000 ₽ до 15 000 ₽. Перед переносом мы провели полную инвентаризацию ящиков: размеры, структура папок, активность. Ящики синхронизировали по IMAP в несколько потоков, и после переноса каждого ящика автоматически сверяли количество папок и сообщений. Исходной системой там было облако, а не локальный Exchange, но инвентаризация и сверка каждого ящика при переходе на RuPost нужны точно так же.

Проверка после миграции — не формальность. Берём случайную выборку по 2–3 письма из каждого ящика (включая вложения, встречи и прочитанные/непрочитанные), сверяем с оригиналом в Exchange, подписываем акт пользователем. Без этого проект нельзя закрывать: расхождения всплывают через недели, когда откатиться уже сложно.

Команды Exchange Management Shell для обоих путей — доступ миграционной учётной записи к ящику для IMAPSync и архивная выгрузка в PST:

Переключение MX и Autodiscover — финальная операция миграции, при которой почтовый поток окончательно уходит с Exchange на RuPost 4.2, а почтовые клиенты переводятся на новый сервер. Правильно подготовленное переключение занимает окно в 1–2 часа и проходит без видимого простоя: входящая почта продолжает доставляться.

За 48 часов до дня X снижаем TTL на MX-записях и записях Autodiscover до минимума (обычно 300 секунд). Это необходимо для того, чтобы в момент переключения новые значения разошлись по DNS-резолверам провайдеров за минуты, а не за часы. Параллельно проверяем, что на RuPost 4.2 корректно работают: приём SMTP на 25-м порту с TLS, Submission на 587 с аутентификацией, IMAP/POP для клиентов, HTTPS для веб-клиента и Autodiscover.

В день X последовательность операций такая. Первое — объявляем окно пользователям и переводим Exchange в режим «только отправка внутренней почты», отключая исходящие коннекторы наружу. Второе — переключаем MX-запись на внешний IP RuPost 4.2 (или на пограничный шлюз, если он есть). Третье — обновляем Autodiscover: CNAME autodiscover.domain.ru переводим на хост RuPost, а SRV-запись _autodiscover._tcp правим в тон. Четвёртое — обновляем SPF (убираем из списка IP Exchange, оставляем IP RuPost), публикуем новый DKIM-ключ, если он отличается, и проверяем DMARC-отчёты в первые сутки.

Отдельный блок чек-листа — клиенты. Outlook с профилем Exchange не переконфигурируется автоматически на другой почтовый сервер — профиль пересоздают. Автонастройка Outlook 2013 и новее в RuPost работает для почты по IMAP, а календари, контакты и корпоративную адресную книгу подключает плагин RuPost для Outlook. На телефонах учётную запись Exchange удаляют и подключают ящик заново — во встроенном почтовом клиенте или в WorksPad X. МФУ и системы, которые отправляют почту по SMTP, перенастраиваются по заранее подготовленному списку из карты интеграций.

После переключения на Exchange оставляем работающим SMTP-приём — часть писем от «забывших» внешних отправителей будет приходить по старому MX из-за кеша DNS. Эти письма либо автоматически пересылаем на RuPost через правило переадресации, либо сверяем вручную по журналу. Сколько держать приём, решает журнал доставки — об этом в разделе о выводе Exchange из эксплуатации.

Критерий успешного переключения — три параметра: отсутствие bounces по домену в журналах обоих серверов, положительные DMARC-отчёты за первые сутки, отсутствие пользовательских тикетов по теме «не приходит почта». Если хотя бы один из них проседает, откатываем MX обратно и разбираем причину — именно для этого TTL снижают заранее.

Миграция с Exchange на RuPost 4.2 для компании на 100–300 ящиков занимает в среднем 6–10 недель календарного времени: 1–2 недели на аудит и подготовку, 1 неделя на пилот, 2–4 недели на волновую миграцию ящиков и dual-delivery, 1 неделя на день X и стабилизацию, 1–2 недели на вывод Exchange из эксплуатации. Для организаций с несколькими площадками и собственным геокластером RuPost 4.2 срок увеличивается на 2–4 недели — за счёт настройки резервных сайтов и сквозного поиска по площадкам.

Самая частая ошибка — попытка выполнить миграцию «за выходные». Для 20 ящиков это работает, для 100 и выше — нет: не хватает времени на сверку, пользователи приходят в понедельник с претензиями, а откатить переключённый MX быстро невозможно из-за кеша DNS. Правильный подход — волновая миграция в рабочие дни с dual-delivery, при которой каждый пользователь переходит на RuPost в своё окно, а не весь офис одновременно.

Вторая ошибка — игнорирование Autodiscover. Админы меняют MX, забывают про Autodiscover, и клиенты Outlook начинают беспорядочно переподключаться к старому серверу, выдавая пользователям окна с запросом пароля. Autodiscover переключается синхронно с MX, иначе эффекта «без простоя» не будет.

Третья ошибка — отсутствие проверки SPF и DKIM после переключения. Исходящая почта с нового сервера начинает попадать в спам у Gmail, Yandex и корпоративных получателей, и причину ищут сначала в RuPost, хотя на деле в SPF просто остался старый IP Exchange или не прописан новый. Проверка через dig TXT domain.ru и первые DMARC-отчёты закрывают этот риск.

Четвёртая ошибка — перенос публичных папок «как есть». Публичные папки Exchange часто разрастаются до сотен гигабайт нерелевантного контента, и копировать их целиком — значит повторять проблему на новом сервере. На этапе аудита большинство публичных папок разумнее архивировать и заменить общими ящиками или общими каталогами в файловом хранилище.

Пятая ошибка — экономия на обучении пользователей. RuPost — не Outlook, веб-клиент выглядит иначе, часть привычных функций находится в других пунктах меню. Пятнадцатиминутная видеоинструкция и FAQ по типовым операциям (отправить вложение, настроить правило, работать с календарём) заметно сокращают поток обращений в первые две недели после переключения.

Отдельная категория ошибок связана с лицензированием. Для миграции Exchange на RuPost 4.2 важно, что все сайты геокластера используют единый пул лицензий: лицензии добавленного сайта попадают в общий пул. Закупать лицензии отдельно под каждую площадку больше не нужно — это прямая экономия, и её стоит учесть на этапе планирования.

После завершения миграции Exchange не выключается сразу — он остаётся в эксплуатации ещё 2–4 недели в режиме «только приём и архив», после чего плановый decommissioning выполняется по чётко прописанной процедуре с сохранением архивной копии всех данных. Выключать работающий Exchange в день X — ошибка: часть писем ещё идёт на старый MX из-за DNS-кеша, часть пользователей разбирается с клиентами, часть внешних систем помнит старые адреса.

На первой неделе после переключения Exchange продолжает принимать входящую почту по SMTP (на случай отставшего DNS-кеша) и автоматически пересылает её на RuPost по правилу Transport Rule. Исходящая почта с Exchange уже заблокирована на уровне коннекторов. На этой фазе важно следить за журналом доставки: если в течение 7 дней на старый адрес ничего не приходит, можно отключать SMTP-приём.

На второй-третьей неделе Exchange переводится в режим архивного доступа. Пользователи больше не подключаются к нему как к рабочему серверу, но администратор сохраняет возможность экспортировать любой ящик в PST — на случай, если после миграции у пользователя не обнаружилось письма или папки. Эта возможность критична: претензии «а где письмо от 2023 года» всплывают в первые месяц-два, и наличие работающего Exchange под рукой экономит часы расследований.

Параллельно готовим архивную копию. Со всех ящиков делаем экспорт в PST командлетом New-MailboxExportRequest и складываем в выделенное хранилище с ограниченным доступом — обычно это файловый сервер с правами только для админа почты и уполномоченного юриста. Для компаний, подпадающих под 152-ФЗ, архив должен находиться на территории РФ и быть защищён от несанкционированного изменения; удобный вариант — шифрование архивных файлов с хранением ключа отдельно.

Decommissioning серверов Exchange выполняется в правильном порядке, чтобы не оставить «висящих» объектов в Active Directory. Сначала переносятся или удаляются общие ящики и ресурсы, которые ещё не мигрированы. Затем удаляются базы данных Mailbox Database (Remove-MailboxDatabase), затем Exchange удаляют с серверов штатной программой установки, последним — последний сервер организации. Часть объектов организации Exchange в Active Directory после этого остаётся. Ручную очистку через ADSI Edit Microsoft не поддерживает, поэтому её делают только при необходимости и только после резервной копии Active Directory.

Финальный пункт — обновление документации и карты инфраструктуры. В реестре серверов отмечаем дату вывода Exchange из эксплуатации, в DNS удаляем остаточные записи (autodiscover, owa, mail старого образца), в системах мониторинга убираем датчики Exchange. Через 6–12 месяцев после миграции архивные PST можно либо удалить (если законодательство позволяет), либо передать на долгосрочное хранение — но это уже решение не ИТ, а юридической службы.

Ответы на часто задаваемые вопросы по теме статьи.

Константин Тютюнник — основатель и инженер IT For Prof. Сопровождает корпоративную ИТ-инфраструктуру российского бизнеса: серверы, почтовые системы, мониторинг, корпоративные мессенджеры и платформы вроде Битрикс24. Делится практикой импортозамещения и self-hosted-решений в блоге и GitHub-организации IT-for-Prof. В рубрике о корпоративной почте пишет о миграциях, отказоустойчивости и защите почтовых серверов. Кейс по теме: Миграция корпоративной почты: 200 ящиков с VK Workspace на свой сервер.