Миграция О365 или подождите 72 часа
Я думал над разными форматами этой статьи и решил сделать акцент на плане миграции, поскольку, как мне кажется, это ключевой элемент сохранения психологического здоровья и нервных клеток, которые, как известно, не восстанавливаются. От того, насколько тщательно проработан этот самый план, может зависеть приличная доля успеха всего предприятия (табличка в разделе «план»).
Стоит добавить, что дополнительным источником моего «сакрального» знания для написания материала стала боль от работы с некоторыми частями инфраструктуры О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 часа для продуктовой инфраструктуры совершенно нереальное время ожидания.
