Импортозамещение. 6 ошибок при переходе на отечественный сервер электронной почты и как их избежать

В поисках отечественного решения

Переходя с зарубежного сервера электронной почты на российский, мы в первую очередь искали решение с собственным плагином MAPI-провайдера (Microsoft Messaging API). Нам было важно временно сохранить полную работоспособность Outlook, и именно MAPI позволяет на другом сервере комфортно пользоваться календарями и планировать встречи. Тут происходит определенный «обход»: Outlook считает, что ничего не изменилось и он все так же подключен к прежнему серверу.

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

Типовой план перехода между серверами

В апреле 2022 года iFellow мигрировала с иностранного сервера на российский продукт за 30 дней: мы перенесли суммарно свыше 1 ТБ данных и перевели на отечественное решение 1000 сотрудников. Делали все самостоятельно, но периодически обращались в техподдержку вендора за нюансами.

Основные шаги:

1. Подготавливаем серверную часть: создаем динамический домен, разворачиваем отечественный сервер, настраиваем антиспам, готовим зарубежный продукт к миграции.
2. Настраиваем синхронизацию паролей, чтобы проходить авторизацию с перенесенной почтой.
3. Создаем профили пользователей на новом сервере и переносим данные. Для небольших объемов делаем это через внутреннюю вспомогательную программу (утилиту). А для больших — через протокол IMAP (протокол для доступа к электронной почте): по нему можно передавать до 150 ГБ данных в сутки. Миграцию данных проводим маленькими группами пользователей: по 10-20-50 человек за поток. Если их будет больше 100, придется долго анализировать текстовые файлы с информацией о пользователях и их контакте с сервером (логи) при ошибках и каждый раз начинать заново.
   
   

После выполнения основных шагов мы сформировали пилотную группу — 10% от всего штата — и постепенно переводили ее на отечественный сервер. Когда пользователи работали в новой системе, мы искали ошибки и проблемы. После того как все заработало корректно и стабильно, настроили аутентификацию со старым паролем пользователя и постепенно перешли на отечественное решение.

План выглядел просто и логично, но даже с ним не получилось все сделать идеально. Делимся опытом нашей команды.

Ошибки при миграции между серверами

1. Неправильно выбрали инструмент для переноса почты

Мы использовали встроенную утилиту нового сервера для переноса большого объема почты — свыше 1 ТБ. У нас не получилось скопировать данные, поэтому мы обратились к вендору — и оказалось, что проблема заключалась в операционной системе. После того, как вендор выдал альтернативный скрипт на Perl (программа для взаимодействия клиента с сервером на языке программирования Perl), мы смогли все оперативно перенести.

Вывод из этой ошибки: через встроенную утилиту можно перенести только календари и маленькие объемы почты. Для больших проще и быстрее это сделать через Mail IMAP Sync.

2. Не оставили места для больших файлов с детальным описанием ошибок

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

Вывод из этой ошибки: важно выделить место для расширенных логов — это сильно сэкономит время при миграции.

3. Не проверили все надстройки от связанных с прежним сервером программ

Когда мы развернули пользователям MAPI-коннектор через групповые политики на всех сотрудников, оказалось, что у кого-то из коллег Outlook просто не открывается — требовались перенастройки и дополнительная конфигурация. После консультации с техподдержкой вендора выяснилось, что проблема была в дополнительных надстройках, которые ставит TeamViewer на Outlook — они не сочетаются с MAPI-коннектором. Когда программа была удалена, все заработало.

Вывод из этой ошибки: необходимо обратить внимание на все надстройки — некоторые из них могут конфликтовать с MAPI-коннектором.

4. Провели тесты только на одной сборке приложения

Основные моменты с нестабильной работой Outlook мы решили, но периодически у сотрудников программа зависала или даже внезапно закрывалась. При этом точно не были виноваты ни TeamViewer, ни конфигурация MAPI-коннектора. Выяснили следующее — поскольку MAPI-провайдер заставляет Outlook думать, что у нас стоит прежнее решение, с одними сборками это работало, а с другими — нет. При очередном обновлении часть функций перестает работать, потому что «раскрывается» обход системы.

Вывод из этой ошибки: стоит проводить тесты на разных сборках Outlook, прежде чем переустанавливать программу на весь штат.

5. Выбрали универсальный путь

Мы выбрали один вариант работы с Outlook в классическом формате — через обход системы. В итоге, когда возникали какие-либо проблемы с конфигурацией, надстройкой и обновлением, сотрудники теряли доступ к почте и другим функциям.

Команда это быстро поняла и реализовала три направления работы с Outlook. Помимо MAPI-коннектора возможна работа через браузеры или клиент Samoware — либо через почтовый клиент для Unix-подобных систем, но его нужно дополнительно настраивать.

Вывод из этой ошибки: всегда необходимо иметь запасной план — нет никаких гарантий, что все пойдет гладко, независимо от известности выбранного вами решения.

6. Тестировали работу на слишком больших группах

Мы изначально определили очень большие группы сотрудников для теста работы почты, поэтому с разными ошибками сталкивалось большое количество сотрудников. Сам вендор для крупных компаний рекомендует делать выборки на 50-60 человек.

Вывод из этой ошибки: формировать небольшие группы для тестов и применять рекомендации вендора.

Особенности переноса календарей и адресной книги

Если вся миграция проходит на Windows, с переносом адресной книги и календарей не должно возникать трудностей: с этим справляются MAPI-коннектор, Samoware или протокол Active_Sync. На macOS ситуация посложнее — для работы с Outlook необходимо настраивать стандартный почтовый клиент через протоколы card.dav или cal.dav.

С cal.dav все просто, а вот на card.dav по умолчанию общей адресной книги нет. Тут необходимо создавать отдельного пользователя с названием Shared_AdressBook на стороне нового сервера, на который переходим. Через Sсheduler копируется список всех контактов, они переводятся в формат vCard (файлы визиток) и добавляются в список контактов пользователя. Далее адресную книгу можно рассылать всем сотрудникам, то есть перенос получается наполовину ручной.

Итоги: как с минимумом проблем мигрировать с одного сервера на другой:

• Для большого объема переносимой почты используйте IMAP — это быстрее.
• Выделяйте больше места под логи, в идеале используйте расширенные — выше шансы увидеть ошибки миграции.
• Делайте небольшие выборки пользователей для тестов.
• Обращайте внимание на надстройки, которые могут конфликтовать с MAPI-коннектором.
• Тестируйте новый сервер на разных сборках Outlook.
• Всегда готовьте несколько запасных планов.

Фото на обложке: Unsplash.