Друзья, всем привет! В очередной статье цикла про управление Яндекс 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.

Machine generated alternative text: Mtcrosott 365 О Подготовка сервер-источник Сбор данных из источника перенос старых писем из ящиков Сбор новых писем перенос новых писем, которые пришли в ящики после миграции Завершено полностью или остановлено администратором О Ошибки • не созданы аккаунты для переноса писем на яндекс почту другие ошибки миграции Аккаунты 2 4 4

Во время миграции напротив соответствующего этапа будет отображаться 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

  1. Опубликовать 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

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

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

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

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

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

  3. Выдать права 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-файл со списком почтовых адресов пользователей, который мы делали в предыдущем разделе. Жмём «Дальше».

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

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

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

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

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

  1. Когда все письма мигрируют и настанет час икс, остаётся переключить 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 так позволяет забрать почту.