Друзья, всем привет! В очередной статье цикла про управление Яндекс 360 для бизнеса я расскажу, как можно скопировать почту из очень популярного почтового сервера Microsoft Exchange Server в Яндекс Почту. 

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

Эта статья будет полезна администраторам почтовых инфраструктур, которым предстоит выполнить миграцию писем на сервис Яндекс Почта. А ещё тем, кто пока только планирует подготовку к такому важному процессу, и всем интересующимся облачными сервисами.

План:

1. Этапы миграции

2. Что должно быть готово в организации Яндекс 360 для бизнеса

3. Подготовительные шаги на стороне Microsoft Exchange Server

4. Проверка доступа Мигратора к почте

5. Подготовка CSV-файла

6. Выполнение миграции

7. Частые вопросы по миграции

8. Миграция как резервное копирование почты

Этапы миграции

В Яндекс Почте есть сервис миграции, назовём его Мигратор. Он умеет разными способами подключаться и забирать почту из других источников. 

Мигратор использует протокол IMAP, чтобы подключиться к почтовым ящикам в Microsoft Exchange Server. Обычно, когда облачные сервисы забирают почту по протоколу IMAP, они запрашивают пароли для всех учётных записей. Но это очень неудобно, да и небезопасно. Далеко не каждый пользователь согласится поделиться паролем. Поэтому в Яндекс Почте разработали Мигратор таким образом, чтобы для его работы не требовалось прописывать пароли пользователей. 

Администратор указывает имя Exchange-сервера, на котором работает служба IMAP. Затем скармливает Мигратору подготовленный CSV-файл со списком логинов пользователей Яндекс Почты и ящиков на Exchange-сервере. После чего запускается миграция, которая работает в пакетном режиме. Мигратор создаёт сборщики, которые инициируют клиентские подключения по протоколу IMAP со стороны Яндекс Почты к каждому ящику на сервере Exchange.

В результате все письма собираются в почтовые ящики и автоматически продолжают синхронизироваться, пока администратор не нажмёт «Завершить миграцию».

Сбор данных одного ящика занимает от нескольких минут до нескольких часов. После этого письма из исходных ящиков начнут появляться в ящиках Яндекс Почты. Структура папок из исходных почтовых ящиков также копируется в целевые почтовые ящики. 

Этапы миграции в кабинете администратора и детализации

Проверка на ошибки

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

Если в процессе проверки что-то пойдёт не так, в детализации будет написано error с указанием причины. Если всё пройдёт успешно, то начнётся подготовка к миграции.

Подготовка к миграции

Идёт поэтапное подключение в пакетном режиме ко всем почтовым ящикам в списке CSV. Оно происходит под учётной записью с правами на почтовые ящики. Выгружается структура папок и списки элементов в ящиках.

Первоначальная синхронизация

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

Синхронизация новых сообщений

После того как выполнена первичная синхронизация содержимого почтового ящика, ничего не останавливается. С определённой частотой начинает запускаться досинхронизация новых писем, которые пришли в ящик на стороне Exchange-сервера. Это происходит индивидуально для каждого ящика в фоновом режиме. В детализации этот этап миграции будет отображаться как Sync_newest.

Остановка миграции

Когда администратор нажимает кнопку «Завершить миграцию», миграция полностью останавливается. Заново её можно запустить только с самого начала. В статусе будет stopping или stopped.

Во время миграции напротив соответствующего этапа будет отображаться 0. Если на этапе «Миграция» вы видите 0, значит, перенос старых писем из ящиков завершён. Если вы хотите перенести только старые письма и не собирать новые, на этом этапе можно завершить миграцию вручную кнопкой «Остановить».

Что должно быть готово в организации Яндекс 360 для бизнеса

Чтобы запустить миграцию в Яндекс 360 для бизнеса, нужно сделать следующие шаги:

1. Создать организацию Яндекс 360 для бизнеса.

2. Добавить как минимум один основной домен в эту организацию. В нашем случае это будет example.com. Как это сделать, читайте в первой статье из цикла.

3. Создать учётные записи для пользователей в организации Яндекс 360. Это нужно сделать, так как инструмент миграции автоматически не создаёт пользователей. Если вы мигрируете из Microsoft Exchange Server, то у вас есть развёрнутый лес Active Directory и, скорее всего, вы будете синхронизировать пользователей из этого леса. Читайте, как это сделать, во второй статье цикла. 

Подготовительные шаги на стороне Microsoft Exchange Server

Чтобы выполнить миграцию по IMAP-протоколу без сбора паролей пользователей, нужно на стороне Microsoft Exchange Server настроить IMAP, создать учётную запись и выдать ей права полного доступа на содержимое переносимых ящиков. Ниже привожу пошаговые действия.

1. Нужно убедиться, что IMAP-служба запущена на том сервере, который вы будете указывать в мастере миграции на стороне Яндекс 360. Чтобы корректно это настроить, следует обратиться к документации Microsoft Exchange: Enable and configure IMAP4 on an Exchange server | Microsoft Learn.

Как минимум следует запустить в автоматическом режиме соответствующие службы:

Set-Service MSExchangeIMAP4 -StartupType Automatic
Set-Service MSExchangeIMAP4BE -StartupType Automatic

2. Опубликовать IMAP-службу по портам 993/IMAPS или 143/IMAP. Это нужно сделать хотя бы для IP-адресов Мигратора:

5.45.234.240/28
5.255.219.176/28
5.45.248.32/28
141.8.128.192/28
93.158.165.192/27
37.9.118.96/27
77.88.30.0/27
93.158.141.128/27

3. В компаниях, как правило, выключена возможность подключения к таким клиентским протоколам, как POP3/IMAP/SMTP, для пользователей. Поэтому необходимо проверить статус и разрешить использование сервиса IMAP.

   Команда для проверки статуса IMAP на пользователе:

   Get-CASMailbox -Identity "John Smith" | ft IMAPEnabled

   Команда для активации IMAP доступа для пользователя:
   Set-CASMailbox -Identity "John Smith" -IMAPEnabled $true

4. Создать отдельную учётную запись с почтовым ящиком. Например, назовём её migrator@example.com. Это должна быть просто учётная запись с почтовым ящиком без прав администратора. Не стоит испытывать судьбу и выдавать этой учётной записи права администратора организации Exchange или другие роли.

5. Выдать права Full Mailbox Access — полный доступ на содержимое почтовых ящиков, которые планируете перенести. Именно полные права на ящики, а не роль администратора позволят добраться Мигратору от его учётной записи до содержимого ящиков нужных пользователей.

Add-MailboxPermission -User <migration@example.com> -AccessRights Fullaccess -InheritanceType all -AutoMapping $false

Выдать полные права на содержимое всех ящиков можно следующим командлетом:
get-mailbox -ResultSize unlimited | Add-MailboxPermission -User <migration@example.com> -AccessRights Fullaccess -InheritanceType all -AutoMapping $false

Теперь на стороне Exchange Server всё выполнено.

Как проверить, что Мигратор сможет получить доступ к почте, или самое интересное место

Сейчас мы попробуем подключиться к почтовому ящику пользователя user, используя учётную запись и пароль пользователя migrator по протоколу IMAP. Для этого необходимо настроить почтовый клиент по протоколу IMAP. Раз мы говорим о Microsoft, то Outlook нам в помощь. 

Нужно настроить профиль в Outlook, как указано на скрине ниже.

Обращаю ваше внимание на поле «Пользователь». Данные нужно указать именно в таком виде: example.com/migrator_account/user. Что это за атрибуты:

• example.com — домен, под которым Exchange Server авторизует пользователя;

• migrator_account — username учётной записи, под которым будет работать Мигратор;

• user — атрибут Alias или Mailnickname исходного (мигрируемого) почтового ящика сотрудника Microsoft Exchange Server.

В поле «Пароль» требуется указать пароль от учётной записи migration@example.com.

Далее нужно указать SMTP-параметры в соответствии с тем, как у вас настроена служба SMTP. Это нужно только для того, чтобы настроить профиль. Для IMAP это вообще не имеет никакого значения, но профиль без этого не настроится в Outlook.

Если Outlook подключился к почтовому ящику пользователя, указанного в поле user, и вы увидели список папок — всё успешно. Мигратор Яндекс Почты эмулирует ровно такое же подключение. Можно двигаться дальше.

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

Подготовка CSV-файла

Теперь, когда вы настроили Exchange-сервер и проверили подключение, остаётся создать CSV-файл.

Образец приведён ниже:

"yandex_login";"external_email";"external_password"
"user1";"example.com/migration/user1";"Password"
"user2";"example.com/migration/user2";"Password"
"user3";"example.com/migration/user3";"Password"

Структуру файла надо обязательно сохранить в кодировке UTF-8. Первую строчку и названия заголовков не трогаем.

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

• Во втором столбце указываем особую конструкцию example.com/migration/user1, которая позволит подключиться к почтовому ящику user1 от имени учётной записи Мигратора. Подробнее смотрите в разделе «Проверка доступа Мигратора к почте».

• Прописываем пароль учётной записи Мигратора. Да, его нужно продублировать в каждой строчке.

Выполнение миграции

Все подготовительные шаги мы прошли, остаётся запустить мастер миграции.

1. Переходим в портал управления Яндекс 360 для бизнеса.

2. Находим раздел «Миграции» в общих настройках.

3. Указываем, что хотим перенести, — письма.

4. Жмём «+Новая миграция».

5. На этапе «Подготовьте аккаунты» подтверждаем, что аккаунты уже созданы, и жмём «Готово» → «Дальше».

6. На этапе «Выберите, откуда хотите мигрировать письма» выбираем «Другой сервер».

7. Указываем имя своего Exchange-сервера, на котором настроена IMAP-служба. Указываем порт 143 или 993 и ставим галочку SSL.

8. Загружаем CSV-файл со списком почтовых адресов пользователей, который мы делали в предыдущем разделе. Жмём «Дальше».

Я рекомендую в первый раз указать небольшое число пользователей, чтобы проверить, всё ли в порядке с синтаксисом и секретом.

9. Наконец, осталось нажать «Запустить миграцию».

10. Наблюдаем за цифрами и при необходимости скачиваем детализацию. Если что-то идёт не так, читаем причину ошибки в детализации и устраняем её. Если не получается, то заводим обращение в техническую поддержку. 

11. Когда всё успешно запустилось с маленьким тестовым набором пользователей, самое время нажать «+Новая миграция». Подкидываем новый большой CSV-файл, чтобы запустить всех за раз.

Если у вас в компании более 20 000 сотрудников, то учтите, что придётся подготовить несколько файлов на каждые 20 000 строк (aka пользователей).

12. Когда все письма мигрируют и настанет час икс, остаётся переключить MX с Exchange Online Protection на Яндекс 360. Нажимаем кнопку «Остановить миграцию» — это приводит к отключению Мигратора.

Частые вопросы по миграции

В своей предыдущей статье про миграцию из Exchange Online я ответил на актуальные вопросы — они в полной мере касаются и миграции из Microsoft Exchange Server.

Добавлю некоторые уточняющие моменты:

• Какие данные переносятся? 

Переносятся только письма. Контакты, календарные события и т. д. этим способом не переносятся.

• Почему не переносятся корректно календарные события? 

Как известно, в Exchange особая структура хранения календарных событий: они хранятся непосредственно в ящиках пользователей. В ящике можно создать разные папки и задать тип сохраняемых в них объектов: письма, календари, контакты, задачи и т. д. 

IMAP-протокол далёк от календарных событий, по нему не получишь и/или не передашь информацию о встречах. Тем не менее, когда IMAP-клиент «стучится» по IMAP-протоколу к Exchange Server и запрашивает весь список папок, то Exchange без толики стеснения отдаёт в клиента папки всех типов, а не только те, в которых указан тип «для писем».

В итоге какой-нибудь IMAP-клиент, например Thunderbird или Мигратор Яндекс Почты, видит все папки и пытается их все синхронизировать. Но если в обозначенном Thunderbird пользователь может исключить папки из синхронизации, то в Миграторе пока нельзя задать такие исключения. 

В результате календарные события переезжают в виде артефактов.

• Может ли Мигратор удалить письма в ящике Exchange Server? 

Нет, Мигратор не удаляет письма. В Миграторе нет команд delete в принципе.

Кроме этого, важно помнить про следующие нюансы:

• Если в папке «Входящие» есть письма-приглашения с календарным событием в формате ics, которое должно состояться в будущем, то во время импорта такого письма будет выполнена стандартная обработка. Это приведёт к созданию календарного события из такого письма.

Подчеркну ещё раз, что календарные события не переезжают. А вот при переезде писем-приглашений с ics создаются встречи на их основе.

• Не переносятся письма более 35 МБ. 

• Не переносятся письма из дополнительного архивного ящика Exchange Online Archiving. Причина проста: Exchange Server не предоставляет доступ к архивному ящику по протоколу IMAP. Если нужно перенести такие письма, то рекомендую заранее перенести их из архивного ящика в основной (primary).

• У писем есть две важные даты: когда получено (received) и отправлено (sent). После миграции письма складываются в ящик с помощью внутренней службы транспорта. В результате дата отправления остаётся такой же, какой была на момент отправки письма, а вот дата получения меняется на дату, когда Мигратор, точнее служба транспорта, положила (aka доставила) письмо в ящик.

Кстати, отмечу такую вещь для пользователей Outlook: если выберете дату «Создано (created)», то она будет в клиенте датой синхронизации письма. Не забываем, что в сладкой парочке Exchange/Outlook по своему проприетарному протоколу MAPI синхронизируется дата создания объекта класса «письмо» IPM.Note — это дата появления письма в Exchange Server, и в клиенте Outlook видна именно она. А вот когда используется протокол IMAP, дата создания письма в Outlook — это уже imap savedate, или дата, когда клиент Outlook создал у себя локальную копию объекта класса «письмо».

Миграция почты как инструмент резервного копирования

Иногда заказчики Яндекс360 для бизнеса используют Диск, Телемост, Мессенджер и другие продукты цифровой среды, кроме Почты и Календаря. Они предпочитают сохранить почту для части или для всех сотрудников на локальном Exchange Server. В таком случае можно использовать описанные в этой статье шаги для настройки резервирования почты.

Администратор настраивает синхронизацию. Пользователи ничего не замечают: они как работали в Outlook с почтовым ящиком в Exchange Server, так и продолжают работать. А администратор и бизнес получают фактически дублированную почту в инфраструктуре Яндекс Почты. При этом:

• почта разложена по пользователям;

• у пользователей сохранена структура папок с письмами. Важно: это не какой-то бэкап, который надо восстанавливать;

• почта актуальна на момент последней фоновой синхронизации. Напомню, что после полной синхронизации Мигратор автоматически синхронизирует новые письма. Максимальная дельта — пара часов.

У этого подхода есть только одна особенность. Цель Мигратора — упростить и реализовать перенос писем. Так что это всё-таки не инструмент резервного копирования и в течение долгого времени его использовать не получится.

Кроме того, нужно учитывать, что Мигратор лишён команд delete. Он не применяет их ни в ящике-источнике, ни в ящике получателя. Если пользователь удалил письмо в своём ящике в Exchange Server, то в Яндекс Почте это письмо будет продолжать лежать. Чем дольше будет синхронизация и чем чаще пользователь удаляет письма в ящике-источнике, тем больше будет разница между ящиками в Яндекс Почте и Exchange Server.

Заключение

Уважаемые читатели, в этой статье я поделился деталями миграции из Microsoft Exchange Server в Яндекс Почту. Вы узнали, как она работает, что она может, а что не может. Я показал, как использовать сценарий миграции для резервного копирования. Буду рад обратной связи и вопросам про миграцию, я или мои коллеги обязательно ответим на них.

Лично я давно поверил в облачные сервисы: как можно заметить из пошаговой инструкции выше, начать использовать Яндекс Почту вместо Exchange Server не так сложно, как кажется.

В следующей статье я расскажу про детали конструкции domain/migrator/user1 и почему Microsoft Exchange Server так позволяет забрать почту.