Миграция почты из Exchange Online в Яндекс 360 для бизнеса27.05.2024 18:45

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

950dec6a60ae88ec7bf80a9bc95b90c2.png

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

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

План:

  1. Необходимые вводные перед миграцией.

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

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

  4. Подготовительные шаги на стороне Microsoft 365.

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

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

  7. Частые вопросы.

  8. Как настроить права только на определённые ящики.

Необходимые вводные перед миграцией

  • Имеется тенант Microsoft 365 с именем {{tenant_name}}.onmicrosoft.com.

  • В тенанте добавлен почтовый домен вида example.com. Возможно, добавлены ещё домены.

  • В тенанте есть пользователи. У них созданы почтовые ящики с адресом вида username@example.com.

  • У вас есть права глобального администратора в тенанте, или вы знаете того, у кого есть такие права и кто может выполнить все необходимые шаги.

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

В Яндекс 360 есть сервис миграции — назовём его «мигратор». Он подключается к Exchange Online с помощью REST API, получает информацию о почтовых ящиках пользователей и забирает их содержимое, а именно письма.

В Exchange Online сервис миграции стучится в виде приложения (App registration), зная его ID и секрет (это что-то вроде пароля). Далее вы передаёте мигратору список адресов, и он начинает работать с ним.

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

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

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

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

Происходит поэтапное подключение в пакетном режиме ко всем почтовым ящикам в списке CSV. Подключение идёт от имени App registration, загружается структура папок и список элементов в ящиках.

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

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

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

Структура папок из исходных почтовых ящиков копируется в целевые ящики. Копируются все элементы почтового ящика, о которых была получена информация на этапе подготовки.

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

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

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

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

833b122afe8dacde74c1e129de9dd22f.png

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

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

Если вы хотите остановить миграцию, например когда вы переключили MX запись на Яндекс 360, на этапе «сбор новых писем» нужно завершить миграцию вручную кнопкой «Остановить».

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

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

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

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

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

После шагов выше Организация Яндекс 360 готова для приёма писем с помощью инструмента миграции.

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

Начнём с того, что у вас есть тенант Microsoft 365, в котором у пользователей существуют почтовые ящики, и вы являетесь глобальным администратором.

Для запуска миграции нужно создать App registration на портале Microsoft Entra. Этот процесс подробно описан в справке Яндекс 360 для бизнеса:

По сути, нужно:

  1. Создать App Registration, с помощью которого инструмент миграции Яндекс Почты будет подключаться к Exchange Online через Rest API и забирать данные. Цель этапа — получить Application (client) ID вида:

abcd1234-a1b2-1111-123a-absdfe

  1. Получить секрет. Нужно, чтобы мигратор доказал, что он — это он, а не «тварь дрожащая», и право имеет, так как знает Client ID и секрет. Вид Client Secret:

ABCD2XYZ032-xyzXYZ032

  1. Выдать права Application permission. Обязательно именно Application, а не Delegated Permission. Мигратор разработан из расчёта, что ему выдан доступ на уровне службы Exchange Online, а не делегированный доступ.

Необходимые права для успешной миграции писем:

  • User.Read.All, чтобы идентифицировать по почтовому адресу, к ящику какого пользователя надо подключиться.

  • Mail.readbasic.All, чтобы получить доступ к структуре всех почтовых ящиков, списку всех писем и всех свойств, кроме тела письма.

  • Mail.read, чтобы получить содержимое всех писем во всех ящиках. Отдельно расскажу, как ограничить такое право.

  1. Выгрузить Client ID и Client Secret, чтобы сформировать файл в формате JSON. Он понадобится для мастера миграции.

{
  "client_id": "abcd1234-a1b2-1111-123a-absdfe",
  "secret": "ABCD2~XYZ032-xyzXYZ032"
}

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

В мастере миграции вам необходимо передать список пользователей. Сам список прост, как говорится, как дрозд:

  • В первом столбце нужно указать Yandex_login. Это то, что называется Username, или nickname, — основное имя пользователя в Яндекс 360 без указания домена, например username без @example.com

    Во втором столбце нужно указать почтовый адрес пользователя в Exchange Online. При этом важно, чтобы в адресе использовался почтовый домен, который добавлен в Яндекс 360.

Пример шаблона: 

"yandex_login";"external_email"
"ivan.ivanov";"i.ivanov@example.com"
"marina.makarova";"m.makarova@example.com"

Подробнее смотрите в статье: https://yandex.ru/support/business/migration/mail/microsoft.html.

Вы можете добавить до 20 000 логинов сотрудников в один файл. Если в организации больше сотрудников, можно создать ещё несколько файлов, воспользоваться кнопкой »+ Новая миграция» и докинуть ещё пользователей в «топку» миграции. Все миграции будут выполняться параллельно.

Сохраните CSV-файл в кодировке UTF-8: для этого в Microsoft Excel нажмите «Сохранить как» → CSV-UTF8. Важно: если сохранить файл в другой кодировке, он будет распознан неправильно.

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

После долгого подготовительного этапа осталось запустить мастер миграции. А если вспомнить времена на заре туманной юности, когда снег горел, а его соломой тушили, то это был бы не мастер, а wizard — волшебник миграции. Тогда скажем: «Абракадабра» :)

  1. Переходим в панель управления Яндекс 360 для бизнеса: https://admin.yandex.ru.

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

  3. Выбираем пункт «Писем».

  4. Нажимаем «Новая миграция».

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

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

  7. Загружаем в формате JSON секрет, который сделали по инструкции в разделе «Подготовительные шаги на стороне Microsoft 365». Нажимаем «Дальше».

    Обратите внимание: секрет применяется ко всем запущенным миграциям. Если вы уже запустили миграцию ранее и после этого загружаете новый секрет, то он применится к текущей и новой миграции. При этом учитываются разрешения секрета: если новый секрет имеет доступ только к письмам (в разрешениях API добавлено Mail.Read и Mail.ReadBasic.All) и у вас запущена миграция файлов, она остановится.

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

  9. Наконец, осталось нажать «Запустить миграцию». Прямо как «Включить энергию» :) Кто угадает, из какого очень древнего сериала эта цитата?

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

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

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

  12. Когда все письма перенесутся и настанет час Х, останется переключить MX-запись с Exchange Online Protection на Яндекс 360. А если нажать кнопку «Остановить миграцию», то мигратор отключится и перестанет что-либо синхронизировать.

Частые вопросы

Во время миграции дьявол, конечно же, кроется в деталях: есть то, что переезжает и сохраняется, а есть то,  что немного меняется или фактически не едет. Об этих нюансах расскажу ниже.

  • При миграции из Exchange Online мигратор получает список всех папок. Он перенесёт все элементы, но «переварить» и корректно отобразить сможет только письма. А вот, например, с календарными событиями придётся искать другие способы: это может быть ручная миграция через веб-интерфейс, Яндекс Коннектор или написание скриптов через CalDAV API.

  • Важно сказать, что мигратор переносит папки «Задачи», «Контакты» и «Календарь», но внутри все объекты отображаются «кривовато». Фактически в Exchange Online и Exchange Server прямо в ящике хранятся все сущности, а не только письма. В Exchange эти сущности — письма, календарные события, контакты и задачи — разделяет на объекты разных классов и подклассов. А мигратор Яндекс 360 умеет разбирать письма, а остальные объекты он кладёт, как смог распарсить.

На картинке как бы «календарные события».

На картинке как бы «календарные события».

  • Если в папке «Входящие» есть письма-приглашения с календарным событием в формате ICS, то во время импорта такого письма будет выполнена стандартная обработка. Это приведёт к созданию календарного события из такого письма. Подчеркну, календарные события не переезжают, а вот при переезде писем-приглашений создаются встречи на их основе. Этот механизм отработает для встреч, которые запланированы на будущее. Речь идет про объекты класс IPM.Schedule.Meeting.Request

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

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

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

    Думаю, здесь наглядно видно, почему на текущий момент теряется дата доставки письма, которую видит пользователь в веб-интерфейсе Яндекс Почты или в почтовом клиенте по протоколу IMAP.

    Received: from 5rvcduy467kgh5zd.vla.yp-c.yandex.net (5rvcduy467kgh5zd.vla.yp-c.yandex.net [2a02:6b8: c0d:2b05:0:5e2b:9cba:0])
    by mail-nwsmtp-mxback-production-main-14.vla.yp-c.yandex.net (mxback/Yandex) with HTTP id atPBZW07k8c0-oJ7cQhdY
    for username@example.com; Sat, 23 Mar 2024 00:55:36 +0300
    X-Yandex-Fwd: 1
    X-Yandex-Spam: 1
    Received: from username@outlook.office365.com ([])
    by mail.yandex.ru with POP3 id trPsEMFMu0U0
    for 1130000080508462@8000722836; Sat, 23 Mar 2024 00:55:36 +0300
    X-yandex-pop-server: outlook.office365.com
    X-yandex-rpop-id: 8000722836
    X-yandex-rpop-info: username@outlook.office365.com
    X-yandex-rpop-foldername: SW5ib3g=
    X-Yandex-Skip-Calendar-Event: true
    Received: from BN6PR11MB1971.namprd11.prod.outlook.com (2603:10b6:404: ff::10)
    by BL0PR11MB3155.namprd11.prod.outlook.com with HTTPS;  Tue, 23 Feb 2021  20:08:36 +0000

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

    Выше приведена верхушка (header) письма, которое было доставлено в ящик пользователя Exchange Online в давно забытом 2021 году. Потом, при переносе письма, в нём отметилась и Яндекс Почта. Обратите внимание на «артефакты», которые подсказывают, что письмо досталось нам через REST API — якобы от адреса username@outlook.office365.com. Сама миграция была выполнена в марте 2024 года.

  • При миграции личные  контакты начинают наполняться на основе анализа адресов получателей в письмах в папке «Отправленные». Потом они будут использоваться как suggested contacts. Пользователь может отключить такое поведение в настройках контактов — для этого нужно, чтобы пользователь снял галочку «Автоматически собирать» в своих контактах.

  • Как докинуть ящиков в топку миграции? Нужно подготовить новый CSV-файл с ещё одной группой пользователей, нажать »+Новая миграция» и указать новый файл. При этом не нужно останавливать всю миграцию — просто докидываете CSV-файлы с новыми, неповторяющимися пользователями.

  • Можно ли перезапустить всю миграцию? Да, это можно делать. Если решите в процессе миграции нажать «Остановить», то остановится миграция у всех пользователей. Потом можно нажать »+Новая миграция». При этом не обязательно загружать новый секрет.

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

  • Процесс миграции работает параллельно на несколько десятков ящиков. Общее число зависит от размера ящиков, количества элементов в них, скорости отдачи со стороны Exchange Online. Этот процесс полностью автоматизирован.

Выдача гранулярных прав для мигратора в сервисе Exchange Online

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

Какие это могут быть ситуации:

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

  • У вас группа компаний, которая имеет единый тенант под управлением головной компании. В результате сценариев M&A ваша организация (одна из многих) отделяется и планирует мигрировать содержимое сотрудников только вашей организации. Опять же, головная компания обладает правами глобального администратора и не горит желанием выдавать права на все почтовые ящики.

С точки зрения ИБ, они абсолютно правы, так как через App registration с заданными выше правами можно скачать содержимое всех ящиков.

Как в такой ситуации поступить? Предложите глобальному администратору урезать права App registration на уровне самого сервиса Exchange Online. Об этом есть подробная статья: https://learn.microsoft.com/en-us/graph/auth-limit-mailbox-access. Здесь я приведу ключевые шаги и пояснения.

Итак, приложение, под которым подключается мигратор, подключается от себя, а не из-под учётных записей пользователей. Оно использует для аутентификации Oauth 2.0 и креды, которые мы загружаем через JSON-файл.

Приложение получает доступ на уровне всего сервиса ко всем почтовым ящикам. Именно такие права появляются, когда мы выдаём mail.read и mail.readbasic.all.

Давайте ограничим права со стороны Exchange Online. Порядок действий:

  1. Создаём в Microsoft 365 mail-enabled security группу и наполняем её пользователями, чьи ящики надо мигрировать, или группами, в которых уже состоят такие пользователи.

  2. Подключаемся к Exchange Online PowerShell.

  3. Ограничиваем права для Application ID только этой группы, запуская командлет: 

New-ApplicationAccessPolicy -AppId e7e4dbfc-046f-4074-9b3b-2ae8f144f59b -PolicyScopeGroupId migrationusers@example.com -AccessRight RestrictAccess -Description "Restrict this app to members of distribution group EvenUsers."

В нём:

  • AppID — тот самый AppID, который мы получили, когда конфигурировали App registration

  • PolicyScopeGroupId — почтовый адрес только что созданной группы

  • -accessRight — нужно указать RestrictAccess только к почтовым ящикам группы, указанной в параметре PolicyScopeGroupId

  1. Проверяем наличие или отсутствие доступа к почтовым ящикам. Для этого запускаем командлет: 

Test-ApplicationAccessPolicy -Identity user1@example.com -AppId e7e4dbfc-046-4074-9b3b-2ae8f144f59b

Результат красноречиво укажет на то, есть ли какие-то права на искомый почтовый ящик у указанного приложения.

Используя эту незамысловатую процедуру, ряд бывших представительств зарубежных организаций смогли централизованно мигрировать почту из Exchange Online в Яндекс 360 для бизнеса. Хотя изначально головная компания не горела желанием выдавать полные права.

Заключение

В этой статье я комплексно описал важные шаги, необходимые для выполнения миграции почты из Exchange Online в Яндекс 360 для бизнеса. Вы узнали, как работает миграция, как запустить её централизованно и как ограничить мигратор в правах.

Если у вас остались ещё вопросы, то обязательно задавайте в комментариях, с радостью отвечу. А в следующей статье я расскажу, как мигрировать файлы с OneDrive for Business и SharePoint Online на Яндекс Диск.

© Habrahabr.ru