Лучший отвечающий
Миграция леса

Вопрос
-
Добрый день.
Задача - миграция леса с 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/- Предложено в качестве ответа Vasilev VasilMicrosoft contingent staff 20 июня 2016 г. 5:31
- Помечено в качестве ответа Vasilev VasilMicrosoft contingent staff 22 июня 2016 г. 8:46
9 июня 2016 г. 10:50Модератор
Все ответы
-
Ящик из 2013 нельзя мигрировать в 2010. Только экспорт\импорт PST7 июня 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-сервера и проч.
Илья, я эту ссылку видел в качестве примера уже наверное тысячу раз. Интересно те кто эту ссылку дают сами до конца её читали и читали ли вообще? Материал в ней не дописан, и обрывается в третьей части. Там даже самой миграции нет только подготовка.
Странно, но полного степ-бай-степ гайда по кросс-форест миграции я не нашёл вообще, везде кусками и отрывками.
Конечно буду отрабатывать сначала на тестовых учётках потом на не сильно критичных боевых, просто хотелось перед этим учесть опыт других и не наступить на хорошо известные грабли.
Спасибо.
9 июня 2016 г. 8:11 -
Полного пошагового руководства не может быть, потому что есть база (которая по той ссылке), а дальше начинается специфика конкретного окружения.
Поэтому сначала отлаживаете базу и учитесь, а потом пошагово усложняете, тестируя свою специфику.
Если, например, вам календари не важны, то этот элемент можно игнорировать - вам проще, а кто-то массу времени тратит на отладку этого момента. Если группы рассылки маленькие, то можно их мигрировать вместе с польхователяями, но если группы большие, то возникнет дуальность (часть пользователей в старом лесе, часть в новом) и надо обеспечить работу таких групп. Потом вопрос: всякое ли используемое ПО переживёт миграцию в другоё лес? Может есть какой-то СЭД, скажем, или что-то еще криво-хитрое. Каждое приложение надо проверить как можно полнее.
Вопрос про грабли. При простой миграции учетки все элементарно - все проблемы в специфике вашей инфраструктуры.
Скорость миграции. Если у вас системы разлиты с эталонного образа, управляются исключительно групповыми политиками, а не криворучками, то пара человек сможет в день мигрировать по 100-200 учетных записей с компьютерами, профилями, почтой и Skype (кстати с ним свои заморочки). Если отбросить понедельники и пятницы, то потребуется не менее месяца на миграцию учеток.
Потом составляете план миграции остальных ресурсов и приложений и офигиваете от сроков :-)
Сазонов Илья
https://isazonov.wordpress.com/9 июня 2016 г. 8:57Модератор -
Да нет там никакой базы - там цикл статей недописанный :)
Понятное дело что проблем во время самой миграции будет вагон.
Сами видите по срокам это будет не быстро - поэтому необходимо обеспечить сосуществование.
Поэтому и хотел разбить на этапы - чтобы хотя бы проблемы с почтой отложить.
В общем видимо придётся методом проб и ошибок шишки набивать.
Исходя из того что смог найти видимо чаще всего миграция делается пачками пользователей целиком (к примеру пачка из 50 юзеров переносится учётка, комп с профилем, ящик последовательно за один раз) затем новая пачка пользователей и так до победного конца.
9 июня 2016 г. 9:35 -
Исходя из того что смог найти видимо чаще всего миграция делается пачками пользователей целиком (к примеру пачка из 50 юзеров переносится учётка, комп с профилем, ящик последовательно за один раз) затем новая пачка пользователей и так до победного конца.
Так всегда и делается - группами пользователей.
Ускориться можно только имея дополнительные ресурсы. Например, тестирование можно распределить между подразделениями ответственными за конкретное корпоративное приложение: делается для них тестовое рабочее место, проверяется работа тестового пользователя, потом миграция и снова проверка в соответствии с программой испытаний.
Протестировать надо все компоненты: DNS, DFS (возможно надо будет перейти на FQDN имена), GPO (может у вас навороченные политики - их придется тоже мигрировать), shared printing, сертификаты внутреннего CA и т.д. - никто не укажет заранее все проблемы с ними - только тестирование в вашей среде.
Составьте список, чем пользуются явно и не явно пользователи - и вперёд тестировать. А вот уже по каждому конкретному элементу вы найдете статьи по миграции. Или тут спросите.
Кстати у меня в блоге были статьи с опытом миграции.
Сазонов Илья
https://isazonov.wordpress.com/- Предложено в качестве ответа Vasilev VasilMicrosoft contingent staff 20 июня 2016 г. 5:31
- Помечено в качестве ответа Vasilev VasilMicrosoft contingent staff 22 июня 2016 г. 8:46
9 июня 2016 г. 10:50Модератор -
Илья, спасибо за ответы. Не могу их отметить так как это уже сделал другой.
В общем мигрировал всё-таки поэтапно - сначала юзеров с профилями (почта в старом домене), потом отдельным этапом мигрировал почту. Просто такой сценарий в данном конкретном случае был удобней.
27 июля 2016 г. 12:06