Миграция почты из Microsoft Exchange в RuPost: гайд

Перенос корпоративной почты в условиях импортозамещения часто сопровождается рисками для инфраструктуры, сложностями с протоколами и угрозой простоя. Я подготовил подробное руководство о том, как выполнить миграцию почтовых ящиков из Microsoft Exchange на отечественное решение RuPost с помощью утилиты RuPost Migration Tools.

В этой публикации я пошагово разберу подготовку операционной системы Astra Linux, необходимые настройки IIS и PowerShell на стороне Exchange, открытие портов, а также настройку веб-интерфейса и реальный опыт тестового запуска.

1. Подготовка ВМ на Astra Linux

Для развертывания утилиты миграции я использую отдельную виртуальную машину под управлением Astra Linux. Первым делом на нее требуется установить среду выполнения .NET Core, чтобы обеспечить корректную работу всех компонентов софта.

Установка .NET и зависимостей

Сначала я добавляю официальный репозиторий Microsoft и устанавливаю ASP.NET Core Runtime 6.0 с помощью терминала:

wget https://packages.microsoft.com/config/debian/10/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
sudo dpkg -i packages-microsoft-prod.deb
rm packages-microsoft-prod.deb
sudo apt-get update
sudo apt-get install -y aspnetcore-runtime-6.0

После этого я инсталлирую обязательные библиотеки для поддержки аутентификации и работы с PowerShell:

sudo apt-get install -y gss-ntlmssp
sudo apt-get install -y powershell

Настройка модулей WS-Management и базы данных

Для правильного взаимодействия с удаленным управлением мне понадобятся дополнительные модули PowerShell, которые я устанавливаю командами:

sudo pwsh -Command 'Install-Module -Name PSWSMan -Force'
sudo pwsh -Command 'Install-WSMan'

Для хранения статусов и параметров миграции используется СУБД PostgreSQL. Я устанавливаю ее на виртуальную машину, после чего завожу отдельную служебную базу данных и пользователя для утилиты:

sudo apt-get install -y postgresql
sudo su postgres
psql
CREATE ROLE "rupost_migration" WITH SUPERUSER LOGIN PASSWORD 'Welcome';
CREATE DATABASE "rupost-migration";
\q
exit

На завершающем этапе подготовки я устанавливаю сам пакет миграционной утилиты:

sudo apt-get install -y ./rupost-migration-tool_3.0.0_amd64.deb

2. Настройка Active Directory и Microsoft Exchange

Корректный перенос данных невозможен без предварительной настройки прав на стороне исходного сервера. Я создаю в Active Directory служебную учетную запись, которая будет выполнять операции чтения и экспорта.

Служебная учетная запись и роли

На сервере Exchange мне нужно назначить специальные группы ролей и включить в них созданный аккаунт:

• ApplicationImpersonation — необходима утилите для получения доступа к почтовым ящикам сотрудников и извлечения писем.
• Mail Recipients — применяется на финальной стадии миграции для автоматической настройки пересылки входящей корреспонденции на новый сервер RuPost.

Настройка IIS и PowerShell Remoting

Далее я настраиваю удаленное управление PowerShell на сервере Microsoft Exchange. Для этого я открываю консоль Internet Information Services (IIS).

В настройках провайдеров аутентификации по пути Default Web Site → Powershell → IIS (Authentication) → Windows Authentication (Enabled) → Providers я выстраиваю провайдеров в строго определенном порядке: сначала Negotiate:Kerberos, затем Negotiate и в конце NTLM.

После этого я выполняю команду для активации удаленного доступа:

Enable-PSRemoting

Конфигурация доверенных хостов

Чтобы сервер Exchange доверял запросам от утилиты, я добавляю IP-адрес виртуальной машины с миграционным инструментом в список доверенных хостов:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value '<IP_адрес_утилиты>' -Concatenate

3. Настройка RuPost

Целевой почтовый сервер также требует подготовки. Чтобы утилита могла обращаться к ящикам пользователей, я создаю мастер-аккаунт олицетворения (имперсонации) через консоль управления RuPost.

Для этого я применяю следующую команду в терминале:

rupost impersonation set -u <первичный_адрес_электронной_почты> -p <пароль>

4. Сетевые требования

Перед запуском процессов я проверяю сетевые экраны. Между серверами должны быть открыты порты для стабильной связи:

• Порт 993 (IMAP) — для почтового сервера RuPost.
• Порт 443 (DAV, SOGo API) — для RuPost.
• Порт 5000 (RuPost API) — для RuPost.
• Порт 465 (SMTP) — для RuPost.
• Порт 443 (EWS) — для сервера Microsoft Exchange.
• Порты 80 и 5985 (PowerShell HTTP) — для Microsoft Exchange.
• Порт 443 (HTTPS) — для веб-интерфейса утилиты (порт можно изменить при установке).

5. Работа с веб-интерфейсом утилиты

Управление процессом переноса данных реализовано через удобную веб-панель. Я открываю браузер и перехожу по адресу https://<хост_утилиты>/, после чего попадаю на стартовый экран первичной настройки.

Для настройки интеграций я последовательно заполняю параметры в разделах конфигурации:

• Подключение к Exchange (EWS): указываю URL-адрес службы, логин и пароль служебной учетной записи.
• Подключение к PowerShell: прописываю URL для Exchange PowerShell, хост Active Directory PowerShell, контроллер домена, а также учетные данные администратора.
• Подключение к RuPost (CardDAV / CalDAV): ввожу реквизиты для миграции пользовательских контактов и календарей.
• Подключение к SOGo API: заполняю параметры доступа к API.
• Подключение к RuPost (SMTP): указываю хост, порт, имя пользователя и пароль для отправки почты.
• Уведомления: настраиваю рассылку отчетов администраторам, добавляя почтовые ящики через значок плюса и удаляя неактуальные адреса корзиной.

6. Тестирование и запуск миграции

Я настоятельно рекомендую не пренебрегать предварительным тестированием. Перед стартом массового переноса я запускаю системную проверку связности.

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

Опыт пилотной миграции и подводные камни

Основываясь на собственном опыте тестового развертывания, я выделил несколько ключевых моментов, с которыми сталкиваются администраторы:

• Объемы и сроки. На пилотном этапе я перенес 10 почтовых ящиков суммарным объемом около 10 ГБ (в среднем по 1 ГБ на пользователя).
• Права делегирования и общие папки. Поскольку Exchange и RuPost были интегрированы с единым контроллером Active Directory, все права доступа и делегирования ящиков (например, доступ секретаря к почте руководителя) сохранились автоматически без ручной донастройки.
• Вопрос SSL/TLS сертификатов. Использование валидных сертификатов Let’s Encrypt избавило меня от проблем с безопасностью. Если вы применяете самоподписанные сертификаты, заранее добавьте их в доверенные корневые центры на виртуальной машине с утилитой, иначе получите ошибки соединения.

Профессиональная помощь в миграции почты

Эту задачу вполне реально выполнить самостоятельно по инструкциям выше. Однако при наличии сотен ящиков, жестких требований к простоям или нежелании разбираться с тонкими настройками сетевых экранов, логично привлечь экспертов.

Команда Cloud4U специализируется на бесшовном переносе корпоративных систем, включая миграцию с Microsoft Exchange на российские платформы вроде RuPost. Специалисты выполняют полный цикл работ: аудит инфраструктуры, планирование, безопасную пересылку данных и настройку отказоустойчивости для бесперебойной работы бизнеса.