none
Миграция леса RRS feed

  • Вопрос

  • Добрый день.
    Задача - миграция леса с Exchange 2013 в лес с Exchange 2010.

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

    Я планирую сначала запустить prepare-moverequest и затем миграцию ADMT.

    Техническая часть примерно понятна, непонятно можно ли разбить миграцию на несколько этапов

    таких как миграция учёток, миграция ящиков, миграция компьютера с профилем или надо прогнать все эти три этапа на пользователе последовательно сразу?

    Если можно разбить на этапы то  как это происходит?

    например: мигрируется ящик в новый лес. Пользователь работает под старой учёткой в старом лесу а outlook сам переподключился на сервер с ящиком в уже новом лесу? Далее можно мигрировать учётку и комп с профилем?

    Или наоборот после Prepare-MoveRequest в созданные MEU сделать миграцию учёток и компьютеров. После этого пользователь работает в новом лесу с новой учёткой а почта на старом сервере в старом лесу и уже следующим этапом мигрировать ящики?

    Какова Best Practice?

    Спасибо.


    7 июня 2016 г. 10:37

Ответы

  • Исходя из того что смог найти видимо чаще всего миграция делается пачками пользователей целиком (к примеру пачка из 50 юзеров переносится учётка, комп с профилем, ящик последовательно за один раз) затем новая пачка  пользователей и так до победного конца. 

    Так всегда и делается - группами пользователей.

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

    Протестировать надо все компоненты: DNS, DFS (возможно надо будет перейти на FQDN имена), GPO (может у вас навороченные политики - их придется тоже мигрировать), shared printing, сертификаты внутреннего CA и т.д. - никто не укажет заранее все проблемы с ними - только тестирование в вашей среде.

    Составьте список, чем пользуются явно и не явно пользователи - и вперёд тестировать. А вот уже по каждому конкретному элементу вы найдете статьи по миграции. Или тут спросите.

    Кстати у меня в блоге были статьи с опытом миграции.


    Сазонов Илья

    https://isazonov.wordpress.com/

    9 июня 2016 г. 10:50
    Модератор

Все ответы

  • Ящик из 2013 нельзя мигрировать в 2010. Только экспорт\импорт PST
    7 июня 2016 г. 11:11
  • Если пользователей много и сразу их проблематично мигрировать всех, то вам нужно обеспечить сосуществование двух лесов, когда часть пользователей будет работать в старом, а часть уже в новом. Как минимум надо обеспечить синхронизацию адресных книг. Учесть наличие групп рассылок.

    Последовательность: сначала создание MEU, потом миграция пользователей, потом почтовых ящиков, потом компьютеров.


    Сазонов Илья

    https://isazonov.wordpress.com/

    7 июня 2016 г. 11:14
    Модератор
  • Илья, имелась в виду возможность пользоваться ящиком в другом лесу.

    Т.е. надо ли сразу все этапы миграции для одного пользователя прогнать? Или сначала мигрируют все пользователи, допустим это займёт 3 дня потом мигрируют ящики ещё 7 дней, вот в это время как работает сосуществование? Смигрированный пользователь цепляется за ящик в старом лесу? 

    7 июня 2016 г. 11:39
  • Да, надо все этапы прогнать и завершить мирацию для пользователя и его компьютера, чтобы он мог продолжать нормально работать.

    Сазонов Илья

    https://isazonov.wordpress.com/

    7 июня 2016 г. 12:59
    Модератор
  • Да, надо все этапы прогнать и завершить мирацию для пользователя и его компьютера, чтобы он мог продолжать нормально работать.

    Сазонов Илья

    https://isazonov.wordpress.com/

    Разве? Насколько мне известно, если пользователь мигрирует в новый лес, которому доверяет старый, с сохранением его SID в старом лесу в sIDHistory, то он без проблем может пользоваться всеми ресурсами в старом лесу, в том числе и почтовым ящиком, авторизуясь по сохранённому SID. Проблемы тут могут быть только с автообнаружением. Ну и, если не отключить фильтрацию SID для доверительных отношений.


    Слава России!



    • Изменено M.V.V. _ 7 июня 2016 г. 13:08
    7 июня 2016 г. 13:08
  • Это схема с почтовым ящиком в ресурсном лесу. И там хитрые заморочки начинаются с атрибутами AD, просто SID и SID History не прокатит.

    Сазонов Илья

    https://isazonov.wordpress.com/

    7 июня 2016 г. 13:16
    Модератор
  • Это схема с почтовым ящиком в ресурсном лесу. И там хитрые заморочки начинаются с атрибутами AD, просто SID и SID History не прокатит.

    Сазонов Илья

    https://isazonov.wordpress.com/


    Нет, насколько я понимаю, тут авторизация производится именно по SID пользователя из старого леса, который непосредственно  mailbox users (SID для этого берётся из SIDHistory), а не по SID пользователя из нового леса. А потому все эти заморочки, которые связаны с masterAccountSID, не начинаются, юлаго, в нынешние времена даже для п/я отключенного пользователя наличие masterAccountSID не требуется, как это было раньше во времена Exch2K/2K3.

    Слава России!

    7 июня 2016 г. 14:28
  • Вы все правильно говорите: учетку пользователя смигрировали, и она имеет по SID History доступ ко всем ресурсам в старом лесу.

    Дальше начинается бардак. Учетку смигрировали и - пользоваталь видимо должен с ней зарегистрироваться на компьютере? Если при этом его профиль не мигрировали с компьютером, то будет создан новый профиль. Это вариант. Только на кой он нужен? Руками потом профиль переносить... Значит надо мигрировать учетку, потом профиль с компьютером.

    Следующая фаза. Остался вопрос в почтой. Если учетку и профиль смигрировали, запустили Outlook - тут будут проблемы, тот же автодисковер, возможно еще что-то вылезет и придется профиль вообще пересоздавать. Ладно, допустим решили все эти проблемы.

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

    Вот и получается, что либо всё (учетки и почтовые ящики) разом мигрировать, либо мигрировать с обеспечением сосуществования и тогда мигрировать группами, и мигрировать при этом каждую учетную запись с почтовым ящиком плюс компьютер с профилем.


    Сазонов Илья

    https://isazonov.wordpress.com/

    7 июня 2016 г. 15:58
    Модератор
  • Илья, я об этом и спрашивал как лучше.

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

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

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

    Увы официальных рекомендаций от майкрософта я не нашёл поэтому и решил спросить коллег которые через это уже проходили.

    8 июня 2016 г. 11:20
  • Прежде всего надо ответить на ряд вопросов:

    1. Сколько учетных записей надо мигрировать

    2. Сохраняется ли почтовый домен или адреса будут новые

    3. Есть ли shared mailbox-ы и делегирование доступа, календарей

    4. Есть ли группы распространения и используются ли сведения о занятости

    5. Нужно ли мигрировать пароли

    6. Нужно ли мигрировать иные ресурсы (файловые и т.д.)

    Сама процедура миграции в общем стандартная https://blogs.technet.microsoft.com/meamcs/2011/06/10/exchange-2010-cross-forest-migration-step-by-step-guide-part-i/

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


    Сазонов Илья

    https://isazonov.wordpress.com/

    8 июня 2016 г. 17:01
    Модератор
  • 1) около 2 тысяч

    2) естественно сохраняется (в целевом лесу есть свой exchange со своим почтовым доменом, смигрировавшие будут иметь адреса как старого так и нового домена)

    3) есть, но проблемы с календарями не особо критичны хотя и нежелательны

    4) группы естественно есть, сведения о занятости не критичны

    5) Да нужно, проблем особых не вижу  - лишний раз прогнать миграцию с PES :)

    6) Да, куча файловых серверов, разнообразные 1с-ки, project-сервера и проч.

    Илья, я эту ссылку видел в качестве примера уже наверное тысячу раз. Интересно те кто эту ссылку дают сами до конца её читали и читали ли вообще? Материал в ней не дописан, и обрывается в третьей части. Там даже самой миграции нет только подготовка.

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

    Конечно буду отрабатывать сначала на тестовых учётках потом на не сильно критичных боевых, просто хотелось перед этим учесть опыт других и не наступить на хорошо известные грабли. 

    Спасибо.

  • Полного пошагового руководства не может быть, потому что есть база (которая по той ссылке), а дальше начинается специфика конкретного окружения.

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

    Если, например, вам календари не важны, то этот элемент можно игнорировать - вам проще, а кто-то массу времени тратит на отладку этого момента. Если группы рассылки маленькие, то можно их мигрировать вместе с польхователяями, но если группы большие, то возникнет дуальность (часть пользователей в старом лесе, часть в новом) и надо обеспечить работу таких групп. Потом вопрос: всякое ли используемое ПО переживёт миграцию в другоё лес? Может есть какой-то СЭД, скажем, или что-то еще криво-хитрое. Каждое приложение надо проверить как можно полнее.

    Вопрос про грабли. При простой миграции учетки все элементарно - все проблемы в специфике вашей инфраструктуры.

    Скорость миграции. Если у вас системы разлиты с эталонного образа, управляются исключительно групповыми политиками, а не криворучками, то пара человек сможет в день мигрировать по 100-200 учетных записей с компьютерами, профилями, почтой и Skype (кстати с ним свои заморочки). Если отбросить понедельники и пятницы, то потребуется не менее месяца на миграцию учеток.

    Потом составляете план миграции остальных ресурсов и приложений и офигиваете от сроков :-)


    Сазонов Илья

    https://isazonov.wordpress.com/

    Модератор
  • Да нет там никакой базы - там цикл статей недописанный :)

    Понятное дело что проблем во время самой миграции будет вагон.

    Сами видите по срокам это будет не быстро - поэтому необходимо обеспечить сосуществование.

    Поэтому и хотел разбить на этапы - чтобы хотя бы проблемы с почтой отложить.

    В общем видимо придётся методом проб и ошибок шишки набивать.

    Исходя из того что смог найти видимо чаще всего миграция делается пачками пользователей целиком (к примеру пачка из 50 юзеров переносится учётка, комп с профилем, ящик последовательно за один раз) затем новая пачка  пользователей и так до победного конца. 

  • Исходя из того что смог найти видимо чаще всего миграция делается пачками пользователей целиком (к примеру пачка из 50 юзеров переносится учётка, комп с профилем, ящик последовательно за один раз) затем новая пачка  пользователей и так до победного конца. 

    Так всегда и делается - группами пользователей.

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

    Протестировать надо все компоненты: DNS, DFS (возможно надо будет перейти на FQDN имена), GPO (может у вас навороченные политики - их придется тоже мигрировать), shared printing, сертификаты внутреннего CA и т.д. - никто не укажет заранее все проблемы с ними - только тестирование в вашей среде.

    Составьте список, чем пользуются явно и не явно пользователи - и вперёд тестировать. А вот уже по каждому конкретному элементу вы найдете статьи по миграции. Или тут спросите.

    Кстати у меня в блоге были статьи с опытом миграции.


    Сазонов Илья

    https://isazonov.wordpress.com/

    9 июня 2016 г. 10:50
    Модератор
  • Илья, спасибо за ответы. Не могу их отметить так как это уже сделал другой.

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

    27 июля 2016 г. 12:06