Почему бизнес уходит с Exchange на RuPost и что теряет при переезде
Переход на RuPost приходит в двух ситуациях: либо лицензии Microsoft Exchange истекли и продлить их легально уже нельзя, либо служба безопасности запрещает держать корпоративную почту на западном стеке. Мы в IT For Prof прошли через оба сценария и разобрали, где переезд идёт гладко, а где без сюрпризов не обходится.
Что такое RuPost и при чём здесь реестр
RuPost — почтовая система от «Группы Астра». Помимо почты включает календари, задачи и адресные книги. Продукт внесён в Единый реестр российского ПО (запись №14647, класс «Почтовые приложения»). Это формальное основание для участия в закупках по 44-ФЗ/223-ФЗ. Юристы заказчика, как правило, требуют не маркетинговое заявление, а выписку из реестра: её стоит приложить к техническому заданию с самого начала.
Про сертификацию скажем прямо: сам RuPost сертификата ФСТЭК не имеет, но работает на сертифицированной ФСТЭК ОС Astra Linux Special Edition. Для большинства регуляторных требований этого достаточно.
RuPost — управляемая платформа от единого вендора с поддержкой, библиотекой готовых конфигураций и регламентом обновлений. Это плюс для SLA и минус для тонкой настройки. Бизнесу без требования «реестр», которому нужна гибкость, больше подойдут Mailcow или Stalwart.
Outlook, мобильные клиенты и кластер
В поставку входит кроссплатформенный клиент RuPost Desktop для Astra Linux, Alt, RedHat и Windows (версия для macOS на момент написания в разработке). Поддерживаются веб-доступ и мобильные клиенты по стандартным протоколам.
Про Outlook стоит сказать отдельно. Он подключается через плагин: почта идёт по IMAP/SMTP, календари и контакты синхронизируются по CalDAV/CardDAV. Нативной поддержки MAPI/EWS у RuPost нет. На одном из проектов заказчик заложил «100% совместимость с Outlook по MAPI» без проверки, и на этапе опытной эксплуатации пришлось переводить часть пользователей на IMAP-профиль и веб-клиент.
Система работает с AD, LDAP, FreeIPA, ALD Pro. В редакции Enterprise поддерживается кластер Active-Active с балансировкой нагрузки.
Что переедет без потерь, а что придётся переделать
Честная картина по сущностям Exchange:
- Почтовые ящики: переносятся полностью, структура папок и флаги сохраняются через IMAP-синхронизацию.
- Контакты: переносятся полностью через экспорт vCard/CSV.
- Глобальный адресный список: перестраивается из AD/ALD Pro, прямого импорта формата Exchange нет.
- Календари: базовые события переносятся, повторяющиеся серии требуют проверки часового пояса.
- Публичные папки: переносятся частично, только как общие ящики.
- Серверные правила Outlook: не переносятся, создаются заново.
- Делегирование (Send As): настраивается вручную через ACL на стороне RuPost.
- Архивные ящики и In-Place Hold: не переносятся, архивы выгружаются в PST.
- Плагины Outlook и кастомные формы: не переносятся, бизнес-логику нужно переписывать.
Публичные папки — отдельная боль. В крупном штате на Exchange их часто используют как хранилище почтовых треков за десятилетие. До миграции мы инвентаризируем все папки, выделяем актуальные (использовались за последние 12 месяцев) и переносим только их в виде общих ящиков. Остальное уходит в PST и холодный архив. Один раз мы перенесли всё скриптом без сортировки, потом две недели разбирались в 800 папках.
Пять этапов миграции
Для штата на несколько сотен ящиков мы разбиваем проект на пять этапов. Попытка «переехать за выходные» без поэтапного плана почти всегда заканчивается продлёнными работами в понедельник.
- Аудит. Снимаем инвентарь: число ящиков, объём, активные правила, делегирования, публичные папки, мобильные профили. Согласуем список «как есть» с заказчиком.
- Развёртывание стенда. Поднимаем сервер, подключаем к каталогу, настраиваем DNS, проверяем приём и отправку с тестовых ящиков.
- Параллельная работа. RuPost поддерживает режим сосуществования со старым сервером. Маршрутизация строится через SMTP-релей. Запускаем пилотный отдел из 5–10 человек на 1–2 недели: ловим неочевидные сценарии с подписями, переадресациями, вложениями в Outlook.
- Массовая миграция. Переносим пользователей пакетами по 20–50 ящиков с паузой 1–2 рабочих дня. Если жалоб на потерю писем больше 10% в пакете, останавливаем и разбираемся.
- Отключение Exchange. Переключаем MX только после того, как все ящики переехали и прошла 1–2 недели без жалоб. Старый сервер держим в режиме «только чтение» ещё месяц.
Когда выбирать RuPost, а когда Mailcow или Stalwart
RuPost подходит в трёх ситуациях. Первая: есть формальное требование «ПО из реестра» — госсектор, объекты критической информационной инфраструктуры, заказчики с регламентом импортозамещения. Mailcow и Stalwart в реестре не числятся. Вторая: у клиента уже развёрнут стек «Группы Астра» и новые решения должны работать без лишней настройки. Третья: нужна вендорская поддержка, обучение администраторов, SLA на инциденты.
Mailcow и Stalwart уместны, когда штат небольшой (десятки ящиков), бюджет на лицензии ограничен, формального требования по реестру нет, а команда умеет читать логи и чинить проблемы без эскалации к вендору.
Мы видели обе ошибки. Заказчик на 80 ящиков ставил «тяжёлую» платформу ради галочки в безопасности и жаловался на стоимость администрирования. И наоборот: 500+ пользователей жили на самосборном Mailcow без коммерческой поддержки и упёрлись в первый серьёзный инцидент с потерей писем, который вендор закрыл бы по SLA. Соответствие платформы масштабу и регуляторике важнее экономии на лицензиях.
Если планируете переход на RuPost или другую отечественную почтовую систему, IT For Prof помогает с аудитом, развёртыванием и переносом данных.