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

Стоит добавить, что дополнительным источником моего «сакрального» знания для написания материала стала боль от работы с некоторыми частями инфраструктуры О365 в процессе миграции (раздел «переключение»).

Конечно же, у Майкрософт (МС) существует довольно большая подборка информации для подготовки к миграции, однако, лишний субъективный, эмоциональный опыт из первых рук точно не помешает. Это моя первая «статья-исповедь». Поскольку я очень ранимый человек и не люблю критику, просьба не сильно «зверствовать» в комментариях. Жду вас под катом.

Зачем

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

Тенанты О365 это абсолютно независимые островки в инфраструктуре МС и часть относящаяся к «совместно» решается технологией Azure B2B (guest users).

Из коробки у МС нет функционала, который создаст гостевого пользователя в вашем тенанте для вновь принятого сотрудника из другого тенанта (или удалит, если его уволили). Контакт тоже автоматом никто не создаст, а значит с новым сотрудником не смогут переписываться или смотреть в его календарь free busy.

Мы написали программу синхронизации гостевых аккаунтов и контактов в GAL для автоматической поддержки адресной книги и гостевых аккаунтов. Мы пытались работать совместно в Teams через гостевые аккаунты. Мы пытались не путаться в какой аккаунт нужно переключиться, чтобы настроить корректно МФА так как их становится много (ведь для гостевого пользователя тоже нужен МФА). Мы пытались не путаться с доступами к файлам SPO двух тенантов. После года работы с гостевыми аккаунтами мы поняли, что это совместная, но очень неудобная работа. Так было принято решение перевезти все О365 ресурсы одной компании в тенант другой.

Вендор

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

Требования простые:

• минимальное влияние на бизнес-процессы, файловый доступ, почту, чаты, SSO, внутренние сервисы
• миграция не должна затронуть локальную АД (ну почти, трасты и перенастройка AAD Connect не в счет)
• 2 АД леса должны синхронизироваться в 1 О365 тенант (это поддерживаемый сценарий для AAD Connect)
• операция должна пройти за выходные (есть разные варианты, но мы выбрали самый быстрый)

Вендора мы выбирали скрупулезно, иностранного, в итоге остановились на ключевом игроке рынка миграционного софта и облачных переездов. В команде их экспертов (professional services) было 2 MVP (SPO и АД), специалист по миграционному софту и менеджер проекта.

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

Мы изначально представляли ситуацию так, что если нас ведет за руку лидер рынка переездов, а также учитывая за какие деньги он это делает, то нам ничего особенного и делать-то не придется. Стоит ли говорить, что мы ошибались?

Подготовка

Мы начали довольно расслабленно. Конечно же параллельно у нас была ежедневная работа и первый месяц подготовки пролетел незаметно, как один день:

• неделю потратили на изучение и подписание документации и согласование финансовых вопросов
• неделю на подготовку орудий производства, предоставление доступов там и сям, попытки заставить миграционный софт работать с МФА, хотя он этого не умел (спасибо conditional access), создание облачной подписки и развертывание там ВМок для миграционного софта
• еще неделю вендор изучал наши ресурсы, и мы согласовывали какие ресурсы и как должны быть «мигрированны»
• неделя ушла на старт предварительной миграции

Где-то к концу первого месяца мы начали что-то предчувствовать, но дороги назад уже не было.

Миграционный софт открывался нам с новой, неизвестной, не указанной в первоначальной документации стороны:

• софт не отслеживал перемещение папок и файлов, те вы создаете в исходной папке файл А, запускается пре-миграция (мы запускали ее несколько раз до основной миграции), потом вы переносите файл А в новое место, снова запускаете пре миграцию и вуаля у вас файл А в 2 местах и так для любого сервиса О365
• софт не мог переместить большие библиотеки СПО, зачекинить никогда не чекиненные файлы, показать какие файлы перенес, а какие нет, он ломал размер файлов при копировании
• на 2 неделе он просто поломался, и разработчики вендора пытались его починить (нам было сказано, что поломался API у МС, без подробностей, и мы конечно ждали)

На этапе подготовки было проделано очень много работы, я даже себе не представлял какой экспресс-курс английского языка мне предстоит пройти за 2 месяца подготовки.

Ребята в команде вендора были крутые, MVP по SPO нам помог скриптами собрать информацию о ресурсах и обратил внимание на то, какие проблемы необходимо исправить до переезда, а вместе с инфраструктурным MVP мы в лабе перепроверили все наши предположения по будущей конфигурации АД и AAD Connect, а также подготовились к переключению.

План

Мы все время добавляли и подправляли план, в итоге это была таблица excel на 75 пунктов. Я не буду описывать все пункты, а приведу последовательно все самые ключевые моменты.





«I wish you a boring weekend» – сказал главный менеджер вендора и мы все радостно посмеялись. Был вечер пятницы, закончилось последнее совещание перед миграционными выходными, мы были готовы почти ко всему.

Переключение

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

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

План был хорош и все шло, как по маслу до определенного момента. В 6 утра в субботу я убрал ненужные больше гостевые аккаунты и контакты, остановил наш AAD Connect, пользователи сконвертировались в облачных onmicrosoft.com, и я отключил их, а также сбросил активные сессии.

В 8 утра мы переключили MX записи и почта заморозилась, а я пошел делать элементарнейшую операцию – удалять домен из тенанта О365.

Добавление домена в О365 — это такая абстракция, вроде подтверждения владения этим доменом. Для добавления вас просят добавить некую запись в DNS, которую вы получите в О365 и после этого можно использовать ваш домен в О365.

Удаление домена тоже простая операция, нужно убрать все зависимости домена у объектов О365, учетных записей и групп и все.

Есть скрипты, я их запустил, проверил, что Exchange online не содержит зависимостей от домена, нет алиасов или логинов, использующих домен и мы радостно стали ждать, когда произойдет удаление домена. Но он не удалялся. О365 говорил, что зависимости все еще есть, что они связаны с группами, однако powershell в Exchange online явно говорил, что мы все сделали правильно.

В лабе в похожей ситуации мы делали заявку в поддержку О365 и инженеры запускали фоновую операцию – некую “диагностику”, которая решала проблему в течение получаса, я сделал заявку и стал ждать.

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

Нам пришлось ждать 8 часов в Субботу первого звонка из О365, все эти 8 часов мы не могли продолжать миграцию, тк нам нужен был наш домен в новом тенанте, а старый его не отпускал.
Обычно, в будние дни, звонок из МС поступает в течение часа максимум, но оказывается русский сегмент поддержки О365 не работает по выходным, а зарубежные коллеги отвечают далеко не так оперативно и авторитетно.

Мы сделали несколько заявок из разных тенантов, обрывали телефоны всех, кого могли найти, поддержка Azure не смогла ничем помочь и лишь сказала, что время запланированное МС на эту операцию может достигать 72 часов, поддержка CSP партнера просто отказалась помогать, наши менеджеры в МС ничего не могли сделать и отправляли обратно в поддержку, которая 8 часов нам не звонила.

В районе 17 наконец-то позвонил инженер из О365 и еще час я пытался ему объяснить, что происходит, что мы удаляем домен, что мы убрали зависимости, а О365 продолжает ошибочно считать, что они есть и сотню раз ему сказал, чтобы он запустил «диагностику», но он не понимал, о чем я говорю, а более опытных коллег поблизости у него не было. Где-то через час позвонил еще другой инженер О365, и он сразу понял, что за «диагностика», запустил, но сказал, что процесс может занять 72 часа и он ничего не может сделать.

Конечно же ни о каких 72 часах не могло быть и речи, у нас было 48 часов на всю миграцию, прошло уже 10, а мы были в самом начале. Наш план плавно рассыпался, так как «диагностика» не помогла ни через полчаса, ни через час, ни позднее.

Домен был намертво приклеен к старому тенанту и его никак нельзя форсировано привязать в новом, тк это все инфраструктура О365 и перед добавлением в новый тенант О365 проверяет, а нет ли его где-то в другом тенанте, а он был.

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

Всю субботу с разными инженерами О365, Azure, нашими коллегами и экспертами вендора мы наблюдали за состоянием злосчастных групп, созванивались, обсуждали планы и наблюдали, как утекает время, ждали и снова звонили в поддержку МС и снова получали ответ про 72 часа и понимали, что выход только один. Уже в ночи приняли решение ждать утро воскресенья в надежде, что группы таки удастся сохранить.

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

Мы потеряли сутки и в большой спешке делали запланированные шаги. Напоролись на проблемы с тем, что, понадеявшись на вендора, не проверили все аккаунты на предмет корректных immutableID и конечно же часть аккаунтов не склеилась, поправили.
Обнаружили, что из-за некорректных атрибутов в АД часть наших общих ящиков в облаке стали обычными, поправили.

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

Часть доступов в SPO мы потеряли, однако руками в следующие несколько дней все исправили.
Пожалуй, то воскресенье было самым плодотворным днем в моей жизни, я был зол, если не сказать больше, но мы все успели.

Последствия

Вот, о чем можно рассказать пользователям, если вам предстоит миграция между О365 тенантами:

• гостевые аккаунты (если ими пользовались) будут удалены, а значит нужно заранее скачать полезное из-под гостевого аккаунта, например, Teams чаты
• из-за особенностей миграционного софта нам пришлось просить людей по минимуму перемещать файлы и папки в О365, тк это порождало дубли
• всем придется заново настраивать профиль outlook и качать почту уже из нового тенанта

OneDrive и SPO

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

SPO

• корзина не переезжает
• все ссылки кроме прямых прав доступа теряются
• сохраняются 3 последние версии
• все документы будут зачекиненны
• меняются пути к сайтам

Teams

• митинги в календарях Teams не мигрировали и их пришлось пересоздать
• названия 1-1 чатов меняются на название технического миграционного аккаунта

Выводы/Советы

Я понимаю, что эти вещи очевидны, но, если бы такая статья попалась мне на глаза, мне было бы немножко легче.

На что обратить внимание:
1. По возможности заручитесь поддержкой экспертов в миграциях и запланируйте общение с МС на выходных, если у вас есть такая возможность.
2. Проинформируйте пользователей коротко и ясно, держите наготове подробную инструкцию.
3. Сделайте подробный план, распределите и обсудите обязанности.
4. Проведите подготовительную работу и заранее выполните в боевой инфраструктуре все шаги, которые возможны.
5. Проведите подробное тестирование ваших шагов в лабе.
6. Будьте готовы к тому, что дело пойдет не по плану.

P.S. Я знаю, что этого никогда не произойдет, но я все-таки хочу попросить коллег из МС сделать возможность удалять домены из О365 форсировано в течение вменяемого времени. 72 часа для продуктовой инфраструктуры совершенно нереальное время ожидания.