Недавно поставили перед мной задачу: произвести миграцию с древнего Exchange 5.5, живущего в домене Windows 2000 на Exchange 2003, развернутого новой организацией в свежем домене 2003. Я понимаю, что и 2003 экченж и 2003 сервер не особо актуальны в 2012 году, но задача есть задача и ее надо решать.

Что не рассматривается в этой статье:
• Настройка и подробное использование утилиты ADMT
• Миграция ресурсов кроме Exchange

Дальше много слов, много картинок и, я очень надеюсь, полезная инофрмация:

У нас два домена. Старый Old.com и новый Contoso.com. Оба они имеют маршрут в Интернет. Но старый домен славно потрудился и теперь пора его перевозить на другую платформу.

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

Главное условие заказчика: сохранить работоспособность пользователей и максимально избегать перерывов в работе. Максимальное допустимое время простоя пользователя: не более двух часов. В остальном полная свобода действий. Раз такое условие, значит нам потребуется SIDhistory.

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

1. Экспертиза инфраструктуры заказчика для подготовки ее к миграции:

• Определить, какие ресурсы в Old.com используются по полному доменному имени (FQDN)
• Определить, какие встроенные доменные группы используются для предоставления доступа к ресурсам
• Определить, какие учетные записи владеют более чем одним почтовым ящиком в Exchange 5.5
• Определить, какие ОС используются на рабочих станциях

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

Очень важно определить, используются ли FQDN в качестве ссылок на сетевые ресурсы. Если мы пропустим этот пункт, то можем столкнуться с неприятностью такого вида, что пользователь не сможет из нового домена получить доступ к ресурсу после того, как сервер держатель этого ресурса мигрирует в новый домен и его FQDN изменится.

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

Очень важно определить, есть ли в Exchange 5.5 почтовые ящики, которые принадлежат одной учетной записи в количестве больше одного. Тут нам на помощь придет утилита ldifde, с помощью которой можно выгрузить список почтовых ящиков с именами владельцев, экспортировать в Excel и изучить. Проблема в том, что начиная с Exchange 2000 появилось условие: одна учетная запись – один почтовый ящик.

Очень важно определить, какие ОС используются на клиентских машинах. От этого зависит версия Active Directory Migration Tool и использование дополнительных ресурсов. В моем случае мы видим, что у клиентов есть как и Windows ХР, так и 7. А это значит, что ADMT версии 3.0 не подходит, т.к. не поддерживает миграцию клиентов с windows 7, а версия ADMT 3.1 требует для своей работы Windows 2008. Версия ADMT 3.2 не поддерживает домен версии 2000

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

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

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

• Создание доверительных отношений
• Настройка групповых политик
• Настройка дополнительных ресурсов и ПО для проведения миграции

На этом этапе нам над подготовить инфраструктуру заказчика к проведению миграции. Т.к. для проведения миграции существует замечательный инструмент Active Directory Migration Tool, то настоятельно рекомендую ознакомиться с документацией к этому инструменту. Она поможет снять большинство вопросов, возникающих на этапе планирования.

Я же заострю внимание на некоторых общих моментах.

Для успешного проведения миграции необходимо создать между доменами доверительные отношения.
Чтобы избежать ненужной путаницы у пользователей, а так же создания пустых профилей на рабочих станциях, на этом этапе необходимо создать и применить политики в обоих доменах, которые будут запрещать вход в домен под учетной записью из другого домена. Т.е. в домене Old.com должно быть запрещено входить под учетной записью из Contoso.com и наоборот. Делается это через создание групповой политики и настройки параметра Deny Lon on locally в Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesUser Rights Assignment на OU для мигрируемых компьютеров.

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

Т.к. мы будем использовать SIDhistory, то придется сделать некоторую подготовку к этому использованию. А именно убедиться, что целевой домен (куда мы будем проводить миграцию) находится в native mode. И желательно добавить в группу BuilinAdministrators исходного домена учетную запись Administrator из целевого домена. Тогда утилита ADMT произведет все необходимые изменения в настройке доменов для миграции SID самостоятельно.

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

• netdom trust trustingDomain /domain:trustedDomain /quarantine:no
• netdom trust trustingDomain /domain:trustedDomain /enableSIDhistory:yes

И, наконец, т.к. у нас клиенты на Windows 7, нам потребуется в целевом домене мембер-сервер с установленной Windows 2008 (не R2!) ОС, чтобы на ней поднять утилиту ADMT 3.1. Не забываем, что для миграции рабочих станций в новый домен утилиту ADMT необходимо запускать от имени учетной записи, являющийся администратором домена в исходном домене и там же являющийся администратором рабочих станций. И проверяем, что эта же учетная запись должна входить в группу локальных администраторов мембер-сервера и быть членом группы BuilinAdministrators целевого домена.

3. Проведение миграции доменных ресурсов (за исключением Exchange):

• Миграция групп
• Миграция пользователей
• Миграция рабочих станций

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

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

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

После этого мы можем переходить к основной части статьи, а именно миграции с Exchange 5.5

4. Проведение миграции Exchange 5.5

• Создание shared SMTP
• Active Directory Connector
• Exchange Migration Wizard
• Миграция общих папок
• Миграция групп рассылок
• Перенастройка Outlook пользователей

Первым шагом нам надо предусмотреть непрерывность получения пользователем почты. Т.е. надо сделать настройку, чтобы независимо от того, где находится почта пользователя – или в исходном домене или в целевом – она всегда нашла адресата. Делается это через настройку механизма Shared SMTP. В результате мы получим следующий механизм: экченж получает почту и проверяет, есть ли получатель этой почты в его каталоге. Если нет, то экченж проверяет является ли он ответственным за доставку на этот доменный адрес всей почты. И если нет, то дальше он смотрит есть ли коннктор для этого домена, если нет, то пытается сделать доставку по MX из DNS, потом просто по DNS и только после этого генерирует ответ отправителю о невозможности доставки. А теперь более подробно:

На Exchange 2003 запускаем оснастку управления экченжем, переходим в раздел Recipients – Recipient Policies и редактируем либо существующую дефолтовую политику или создаем новую (см. рисунок). Добавляем второй SMTP суффикс и снимаем выделение с параметра, что экченж отвечает за всю корреспонденцию на этот доменный адрес

Жмем ОК

Далее идем в группы маршрутизации и находим там папку Connectors. Нажимаем на ней правой клавишей, выбираем New – SMTP Connector и настраиваем. Набираем имя коннектора, указываем адрес смартхоста (наш Exchange 5.5) и добавляем сервер бриджхэд (наш Exchange 2003).

Переходим на закладку Address Space и добавляем наш почтовый суффикс и ставим галочку разрешить пересылку

Жмем ОК

После этого надо перезапустить сервисы Exchange Routing Engine и SMTP, но я предпочитаю перезапустить сервер целиком.

Теперь проводим настройку Exchange 5.5. Она менее логична, т.к. в Exchange 5.5 можно использовать только один коннектор SMTP на один сервер.

Запускаем оснастку управления Exchange 5.5, переходим в конфигурация сайта и находим папку Connections. У нас только один коннектор для Internet Mail. Выбираем свойства коннектора (да, через основное меню. Правый клик в те времена был еще не в моде) и переходим на закладку Connections. Нажимаем кнопку E-mail Domain и добавляем текущий для исходного домена почтовый суффикс с указанием адреса, куда делать пересылку (адрес нашего нового Exchange 2003). Дважды нажимаем ОК

Переходим на закладку Routing и переключаем с не перемаршрутизировать SMTP почту на перемаршрутизировать. Больше ничего в нашем случае настраивать не надо. Нажимаем ОК и перезагружаем Exchange 5.5

В результате у нас получилось общее адресное пространство между двух экченжей. На этом этапе я обычно еще переключаю входящую из вне почту с Exchange 5.5 на Exchange 2003. Единственная проблема, которая может возникнуть: приход почты для несуществующего адресата. Т.к. ни один из экченжей не отвечает полностью за область, они будут пересылать письмо друг дружке. Но это будет не бесконечно, а с установленным количеством максимальных прыжков (hops) в настройках SMTP сервера… По-умолчанию это значение равно 30. Я его не трогаю.

Теперь переходим к настройке Active Directory Connector. Этот инструмент идет в поставке Exchange 2003 и находится на диске дистрибутива. Его задача состоит в том, чтобы перенести информацию из каталога Exchange 5.5 в каталог Active Directory. Работает он достаточно просто. Но надо учитывать, что если у нас Exchange 5.5 развернут в сети с AD и находится на контроллере домена, то подключиться к порту LDAP 389 Exchange 5.5 не получится. Для решения данной проблемы надо просто в настройках Exchange 5.5 изменить порт LDAP на любой другой доступный (для простоты я изменяю на 3891).

В целевом домене запускаем Active Directory Connector. Создаем новый коннектор и настраиваем его согласно приведенной ниже параметрам

General	From Exchange to Windows DC на котором запущен ADC
Connections	Адрес и учетные записи для доступа к DC целевого домена и Exchange исходного домена
Scheduler	Always
From Exchange	Путь к папке со списком получателей на Exchange 5.5 Путь к OU в целевом домене куда ранее были смигрированы учетные записи из исходного домена. Тип ресурса: Mailboxes
Advanced	Выбрать This is an Inter-Organizational…

 

Нажимаем ОК.

И происходит т.с. наполнение ранее смигрированных учеток атрибутами Exchange. Если необходимо, в свойствах коннектора можно задать уровень логгирования и следить за процессом работы через Event Viewer.

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

Выбираем что миграция будет производиться с Microsoft Excahnge

указываем на какой Exchange и в какое хранилище,

указываем FQDN адрес Exchange 5.5 (если у LDAP на Exchange 5.5 менялся порт, то не забываем указать и новый порт через двоеточие после адреса) и учетную запись для доступа к экченжу в исходном домене,

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

выбираем почтовые ящики

указываем OU где хранятся ранее смигрированные утилитой ADMT и заполненные атрибутами утилитой ADC учетные записи из исходного домена

Убеждаемся, что утилита Migration Wizard нашла совпадения учетных записей с ящиками

Если это не так, то проверяем, в чем ошиблись. И если все нормально, выполняем перенос

После этого у нас остается только одна задача в этом шаге: переключить пользовательский Outlook на новый сервер. Это можно сделать как вручную, так и при помощи логон скрипта с файлом PRF. Документация по настройке данного способа находится здесь technet.microsoft.com/ru-ru/library/cc179062 ^[1]

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

Миграция контактов производится так же ADC согласно таблицы настроек для миграции почтовых ящиков, где в настройках мы указываем где брать контакты на Exchange 5.5 и куда их складывать (в какое OU) в новом домене. Не забываем указать в настройках ADC, что тип мигрируемых ресурсов – Contacts.

Миграция групп рассылок утилитой миграции не производится. Есть два способа: либо полностью вручную или через скприпт. Вручную это, собственно, в целевом домене создается группа рассылки и в нее добавляются пользователи по аналогии с исходным доменом. Скриптом это можно следующим способом: при помощи утилиты ldifde.exe выгрузить в файл CSV названия групп и их участников в исходном домене, а в целевом при помощи скрипта на VBS создать и добавить участников групп из данных этого файла. Но готового решения по экспорту у меня нет. Делал вручную. Полезную информацию почерпнул из этой статьи msmvps.com/blogs/ehlo/pages/52855.aspx ^[2]

5. Завершение миграции:

• Тестирование работоспособности нового домена
• Устранение недочетов
• Удаление старого домена и вывод из эксплуатации

Завершение миграции никаких хитростей не имеет. Проверяем все и вся, слушаем пользователей и их жалобы. Устраняем. После того, как все успокоились, выводим старый домен из эксплуатации. Включаем фильтрацию SID обратно (дабы кабы чего не вышло т.с.) и удаляем старый SMTP суффикс, если он нам больше не потребуется. Но имейте ввиду, что пользователи любят откапывать письма многолетней давности и писать адресатам ответы через Replay.

Собственно, все.

Автор: sudden_buben