Миграция почтовой инфраструктуры в рамках импортозамещения — это всегда стресс для системного администратора: риск потери писем, простои в работе компании и несовместимость протоколов. В этой статье мы разберем пошаговый процесс переноса почтовых ящиков из Microsoft Exchange в RuPost с использованием специализированной утилиты RuPost Migration Tools.
Мы подробно рассмотрим подготовку окружения на Astra Linux, тонкие настройки IIS и PowerShell на стороне Exchange, а также сам процесс миграции через веб-интерфейс. Делимся рабочим конфигом, списком необходимых портов и реальным опытом пилотного запуска.
1. Подготовка ВМ на Astra Linux
Утилита RuPost Migration Tools разворачивается на отдельной виртуальной машине. В нашем примере используется Astra Linux. Для начала на ВМ нужно установить среду выполнения .NET.
Добавляем репозиторий Microsoft и устанавливаем ASP.NET Core Runtime 6.0:
wget https://packages.microsoft.com/config/debian/10/packages-microsoft-prod.deb -O packages-microsoft-prod.debsudo dpkg -i packages-microsoft-prod.debrm packages-microsoft-prod.debsudo apt-get updatesudo apt-get install -y aspnetcore-runtime-6.0
Устанавливаем необходимые библиотеки для аутентификации и PowerShell:
sudo apt-get install -y gss-ntlmsspsudo apt-get install -y powershell
Далее устанавливаем дополнительные модули PowerShell для корректной работы с WS-Management:
sudo pwsh -Command 'Install-Module -Name PSWSMan -Force'sudo pwsh -Command 'Install-WSMan'
Устанавливаем и настраиваем базу данных PostgreSQL, которая будет хранить состояние миграции:
sudo apt-get install -y postgresql
Создаем пользователя базы данных и служебную БД для утилиты:
sudo su postgrespsqlCREATE ROLE "rupost_migration" WITH SUPERUSER LOGIN PASSWORD 'Welcome';CREATE DATABASE "rupost-migration";\qexit
Наконец, устанавливаем саму утилиту миграции:
sudo apt-get install -y ./rupost-migration-tool_3.0.0_amd64.deb
2. Настройка Active Directory и Microsoft Exchange
Служебная учетная запись и группы ролей
В Active Directory, где работает Microsoft Exchange, необходимо создать служебную учетную запись. Затем на сервере Exchange создаем отдельные группы ролей и добавляем в них нашу учетку:
-
ApplicationImpersonation — для осуществления доступа в почтовые ящики пользователей и извлечения из них необходимых для экспорта данных.
-
Mail Recipients — используется утилитой при завершении миграции для настройки переадресации входящих сообщений на сервер RuPost.
Настройка IIS и PowerShell Remoting
На сервере Microsoft Exchange нужно разрешить удаленное выполнение PowerShell.
-
Запустите оснастку Internet Information Services (IIS).
-
Перейдите в настройки провайдеров аутентификации:
Default Web Site→Powershell→IIS (Authentication)→Windows Authentication (Enabled)→Providers. -
Задайте провайдеры в следующей последовательности:
Negotiate:Kerberos,Negotiate,NTLM.
Выполните в PowerShell на сервере Exchange:
Enable-PSRemoting
Настройка доверенных хостов
Добавьте IP-адрес утилиты миграции в доверенные IP-адреса на сервере Exchange:
Set-Item WSMan:\localhost\Client\TrustedHosts -Value '<IP_адрес_утилиты>' -Concatenate
3. Настройка RuPost
Для работы с почтовыми ящиками пользователей на целевом сервере 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 |
Почтовый сервер Micrisoft Exchange |
|
80, 5985 |
PowerShell HTTP |
Почтовый сервер Microsoft Exchange |
|
443* |
HTTPS |
Веб-интерфейс утилиты миграции |
*Порт веб-интерфейса может быть изменен при установке.
5. Работа с веб-интерфейсом утилиты
Откройте браузер и перейдите по адресу утилиты: https://<хост_утилиты>/. Откроется окно первоначальной настройки (Рис. 1).
Для настройки подключения к системам перейдите в соответствующие разделы настроек:
1. Подключение к Exchange (EWS): Заполните URL-адрес, имя пользователя и пароль служебной учетной записи (Рис. 2).
2. Подключение к PowerShell: Заполните «URL-адрес Exchange PowerShell», «Хост Active Directory PowerShell» (Remote PowerShell), домен контроллер, имя пользователя и пароль (Рис. 3).
3. Подключение к RuPost (CardDAV / CalDAV): Заполните URL-адрес, имя пользователя и пароль для переноса контактов и календарей (Рис. 4).
4. Подключение к SOGo API: Заполните URL-адрес, имя пользователя и пароль (Рис. 5).
5. Подключение к RuPost (SMTP): Заполните URL-адрес (или хост), порт подключения, имя пользователя и пароль (Рис. 6).
6. Уведомления: Утилита позволяет отправлять уведомления администраторам о статусе миграции. Добавляйте почтовые адреса администраторов нажатием значка «+». Если почтовый ящик уже не актуален, вы можете удалить его нажатием значка корзины (Рис. 7).
6. Тестирование и запуск миграции
Перед запуском обязательно проведите тест подключения. Утилита проверит доступность всех сервисов и корректность введенных учетных данных (Рис. 8).
Если тест прошел успешно, можно приступать к миграции. Если тест закончился с ошибками — внимательно изучите логи и устраните неполадки. После успешного теста запускайте процесс переноса данных (Рис. 9).
Опыт пилотной миграции и подводные камни
Мы решили не ограничиваться сухой инструкцией и делимся результатами нашего пилотного запуска, чтобы вы могли учесть наш опыт.
1. Объемы и сроки. На текущий момент мы находимся на этапе пилотного проекта. В рамках теста мигрировали 10 почтовых ящиков общим объемом около 10 ГБ (в среднем по 1 ГБ на ящик).
2. Права делегирования и общие папки. Один из главных страхов при миграции — потеря прав делегирования (когда секретарь имеет доступ к ящику руководителя) и общих папок. В нашем случае RuPost и Microsoft Exchange подключены к одному контроллеру Active Directory. Благодаря этому права доступа и делегирование ящиков перенеслись корректно и прозрачно, без необходимости ручной перенастройки.
3. Вопрос SSL/TLS сертификатов. Частая проблема при миграции — ошибки валидации сертификатов. В нашей инфраструктуре на серверах использовались валидные сертификаты от Let’s Encrypt, поэтому утилита отработала без нареканий. Совет: если вы используете самоподписанные сертификаты во внутренней сети, заранее подготовьтесь к добавлению исключений в доверенные корневые центры сертификации на ВМ с утилитой, иначе получите ошибки SSL при подключении к EWS или IMAP.
Нужна помощь с миграцией или надежный хостинг для RuPost?
Миграция почты — задача, которую вполне можно решить своими силами, опираясь на инструкцию выше. Однако если у вас сотни ящиков, строгие SLA по времени простоя или нет желания самостоятельно разбираться с подводными камнями EWS, PowerShell и сетевых экранов, имеет смысл доверить эту задачу профессионалам.
Команда Cloud4U помогает бизнесу не только с размещением инфраструктуры, но и с бесшовной миграцией корпоративной почты, включая переход с Microsoft Exchange на отечественные решения (в том числе RuPost). Мы берем на себя аудит текущей среды, планирование, безопасный перенос данных и настройку отказоустойчивости, чтобы ваши сотрудники даже не заметили «переезд».
Узнать подробнее о корпоративной почте и услугах миграции от Cloud4U
P.S. Коллеги, а какой опыт миграции с Microsoft Exchange на отечественные почтовые решения был у вас? С какими сложностями сталкивались при переносе больших объемов?
ссылка на оригинал статьи https://habr.com/ru/articles/1090542/