Я не умею писать вводное слово, потому сразу к делу.
Краткое описание методики миграции:
Миграция происходит side-by-side, те необходимо разворачивание параллельной инфраструктуры AD DSExchange и сопутствующих сервисов. Этапы:
1. Разворачивание целевой инфраструктуры.
2. Двустороннее доверие между доменами и установка ADMT.
3. Синхронизация гглобальных адресных книг и настройка сосуществования почтовых организаций.
4. Собственно миграция, которая состоит из миграции почты, пользователей и компьютеров.
Подробнее под катом.
Для миграции пользователей и компьютеров — ADMT 3.2, для миграции почтовых ящиков — powershell, для синхронизации глобальной адресной книги — FIM, для синхронизации freebusy информации — Inter-Organization Replication Tool. Таким образом, все инструменты используемые при миграции являются бесплатными. Я производил миграции порядка 600 пользователей с помощью данных инструментов и каких-либо существенных проблем не встретил. Решение масштабируется без каких-либо проблем.
Успех миграции на 50% (минимум) зависит от стадии планирования, на этом этапе Вам необходимо продумать все заранее.
Больше всего внимания следует уделить сосуществованию почтовых организаций, так как этот сервис обычно очень критичен для организации и проблемы с этим сервисом крайне быстро «всплывают».
1. Пространство имен.
Вам нужно продумать стратегию пересылки почты между почтовыми организациями на время сосуществования почтовых организаций. Один из вариантов — маршрутизация всей почты через Exchange 2010 и relay (переадрессация) почты для «старой» почтовой организации. Для этого Вам необходимо добавить почтовый домен «старой» почтовой организации в «accepted domains» «новой» почтовой организации и сконфигурировать этот домен как «internal relay», после чего сделать сконфигурировать новый Exchange Сервер на пересылку почты на старый Exchange (фактически указать куда пересылать, тк новый Exchange ничего не знает про старый). В этом случае почтовый сервер Exchange 2010 при получении письма для пользователя из этого домена будет искать у себя пользователя с данным адресом — в случае отсутствия данного пользователя письмо будет перенаправленно на почтовый сервер «старой» почтовой организации.
2. Публикация новой почтовой организации в старом домене (SCP запись) и запрет доступа к ней не мигрированным пользователям.
В командной строке Exchange новой почтовой организации необходимо выполнить команду «Export-AutoDiscoverConfig -TargetForestDomainController домен_контроллер_целевого_домена (те старого) -MultipleExchangeDeployments $true -TargetForestCredential $targetcredentials». Данная команда создает в старом домене SCP запись новой почтовой организации. Клиенты Outlook найдут её раньше чем SCP запись старой почтовой организации, тк она ближе к корню домена, для того чтоб не мигрированные пользователи старого домена не могли считать информацию с этой SCP записи необходимо создать группу безопасности, добавить туда мигрированных пользователей (и добавлять по мере миграции) и разрешить им доступ на чтение к данной SCP и убрать разрешение на чтение данной SCP у группы «Authenticated Users».
Troubleshooting:: Правой кнопкой мыши с зажатым ctrl на значок Outlook в панели задач и выбрать пункт «Test E-Mail Autoconfiguration». Так же можно включить дополнительное логгирование в Outlook.
3. Синхронизация GAL'ов и freebusy информации.
Для синхронизации GAL'ов будет использоваться FIM 2010 R2. Для синхронизации контактов необходимо убрать из всех организацицонных единиц контакты которые не нужно синхронизировать (можно, конечно, тоже самое сделать фильтрами FIM, но это, во-первых, сложнее, во-вторых, хуже).
Для синхронизации freebusy информации будет использоваться Inter-Organization Replication Tool (подробнее тут).
4. Стратегия миграции почты.
Вернемся к пространству имен, если вы мигрируете из домена xxx.company.com в домен company.com, Вам необходимо будет мигрировать через промежуточный домен (только почту) например firm.com. Это необходимо по той причине что Exchange сервер «думает» что это дочерний домен и будет возвращать ошибку даже не смотря на то что все сделанно правильно.
В общем и целом у Вас 2 варианта:
— Вначале ADMT потом Prepare-MoveRequest (порядок: Prepare-MoveRequest, ADMT, New-MoveRequest)
— Вначале Prepare-MoveRequest потом ADMT (порядок: ADMT, Enable-MailUser, Prepare-MoveRequest, New-MoveRequest)
Первый сценарий предпочтительей в случае если Вы мигрируете в новый доменлес и в нем нет копий этих пользователей. Подробнее дальше по тексту.
5. Стратегия миграции пользователей.
Миграция пользователей осуществляется после миграции почты (на самом деле это не совсем так, пользователь может быть членом нового доменалеса, а почту использовать из старого доменалеса. Просто этот вариант мне кажется наиболее логичным). Процесс очень прост и интуитивен. Все операции проделываются с помощью ADMT. Единственные советы которые тут можно дать — заранее придумать плансписки мигрирующих по дням и согласовать с бизнесом.
6. Стратегия миграции компьютеров.
Миграция компьютеров осуществляется в последнюю очередь, так как в этом случае мигрируются все профили пользователей которые когда-либо работали на комьютере. Поясню, если Вы мигрируете компьютер на котором работают 2 пользователя и только один из них мигрирован в новый доменлес, то после миграции компьютера «старый» профиль будет доступен (те скопирован в «новый» профиль, фактически) только этому пользователю. У второго пользователя будет пустой профиль.
Кратко (относительно) освещу каждый пункт кроме первого.
Доверие между доменами:
Данный этап важен не только потому что необходим для непосредственной миграции, но и потому что если Вы мигрируете количество пользователей отличное от 100 процесс миграции займет больше чем одни выходные и Вам необходимо чтобы пользователи из нового домена имели доступ к ресурсам и сервисам из старого домена. Данный момент довольно подробно описан в интернете и 99% тем на форумах и постов в блогах ссылаются на вот эту статью. Но карантин SID'ов запрещает администраторам из доверенного домена управлять доверяемым доменом, а не открывает доступ к ресурсам из старого домена. Для этого необходимо включить SID History для траста (возможно я тугой, но я потратил массу времени пока понял что карантин SID'ов делает не то что везде описано). Подробнее тут.
Для удобства: SID History — Netdom trust TrustingDomainName /domain:TrustedDomainName /enablesidhistory:Yes /userd:domainadministratorAcct /passwordd:domainadminpwd и карантин SID'ов — Netdom trust TrustingDomainName /domain:TrustedDomainName /quarantine:No /usero:domainadministratorAcct /passwordo:domainadminpwd
Установка ADMT происходит путем нажимания на кнопку далее некое количество раз (на SQL Express 2008 оно не встало, на 2005 легко). Если необходим экспорт паролей нужно ставить Password Export Service на PDC Emulator старого домена (после установки нужно запустить службу или переставить её на авто запуск, по умолчанию она стоит в ручном режиме и выключена).
Кроме этого необходимо исправить ключ реестра на контроллере домена с ролью PDC в новом домене. HKLMSystemCurrentControlSetServicesNetlogonParametersAllowNT4Crypto для поддержки миграции рабочих станций под управлением ОС Windows XP, Vista (до SP1) и 2000. Гуглим по запросу AllowNT4Crypto.
3.Синхронизация глобальных адресных книг
Для этого нам потребуется SQL сервер, 1 штука, FIM Synchronization Service 1 штука, консоль Exchange 2010 на сервере FIM 1 штука (необходима для павершела). Процесс установки сводится к нажиманию кнопки далее и указания вполне очевидных параметров (адрес SQL сервера и тд). Единственное — советую сделать отдельный сервисный аккаунт для FIM Synchronization Service.
Настройка FIM'а производится через графический интерфейс.
Вначале необходимо включить provisioning. Закладка Tools > Options > «Enable Provioning Rules Extension».
Далее необходимо создать 2 менеджмент агента, один будет синхронизировать контакты из старого домена в новый, а второй наоборот.
По умолчанию GALSync менеджмент агент не синхронизирует следующих пользователей: пользователей скрытых из глобальной адресной книги или с не заполненым параметром «legacyExchangeDN» или с не заполнеными параметрами (одновременно) «msExchangeHomeServerName» и «targetAddress» или в случае когда не заполнен параметр «proxyAddresses», кроме того, если это «Mailbox Plan», «Arbitration Mailbox» или «Discovery Mailbox».
Приступим к созданию менеджмент агентов для синхронизации адресных книг.
Необходимо создать 2 менеджмент агента (создаются идентично), на первом экране нерьходимо выбрать «Active Directory global address list (GAL)» и дать название агенту.
На следующем экране необходимо указать лесдомен и учетные данные для подключения к нему.
На следующем экране необходимо выбрать организационные единицы из которых FIM будет забирать данные и контейнер куда он будет складывать crossforest контакты (кнопка «Containers»).
Следующий экран самый интересный ;). Необходимо указать smtp суффиксы и самое главное, указать FIM'у куда класть контакты и откуда брать контакты. Для указания организационной единицы где будут создаваться контакты необходимо нажать кнопку «Target», Кнопка «Source» позволит Вам настроить организационные единицы содержащие пользователей которых необходимо синхронизировать. “Support cross-forest delegation (Exchange 2007 or 2010 only)” будет создавать параметры енобходимые для делегации полномочий на Mail-enabled user objects (например чтение календарей).
Далее необходимо много раз нажать на кнопку далее ;) На последнем экране необходимо указать версию сервера эксчендж (для нового домена) адрес по которому расположен повершел Exchange'а 2010 (http://exchangeFQDN/powershell).
При настройке агента для старого домена Вы столкнетесь с проблемами ;) Дело в том что в Active Directory просто нет некоторых параметров которые FIM по умолчанию ищет там, и в определенный момент Вы не сможете продолжить настройку агента из-за ошибки связанной с отсутствием параметра «msExchRecipientTypeDetails». Для исправления данного печального факта Вам необходимо на шаге «Configure Connection Filter» выбрать сущность user и удалить все упоминания «msExchRecipientTypeDetails». Но это только начало, на шаге «Configure Join and Projection Rules» необходимо выбрать параметр «Object Type: User» и в св-вах данной сущности найти и удалить «msExchRecipientTypeDetails», а для сущности «Object Type: contact» удалить «msExchRecipientDisplayType» и «msExchRecipientTypeDetails». Дальнейшая настройка идентична (кроме указания адреса повершела, этого делать не нужно).
Далее необходимо запускать агенты каждй раз когда Вам необходимо синхронизировать глобальные адресные книги или настроить расписание. Очередность запуска агентов не принципиальна, вначале необходимо запустить полный импорт агентов, потом полную синхронизацию, потом экспорт. После чего необходимо сделать подтверждающий импорт, это необходимо чтобы FIM убедился что все изменения успешно внесены в целевые системы.
Для траблшутинга необходимо использовать «Журнал Событий». Но помните что если у Вас возникает проблема с конкретным пользователемконтактом лучше изменить информацию в целевой системе чем пытаться средствами FIM'а решить проблему.
4. Миграция
Я не буду освещать миграцию пользователей и компьютеров поскольку она делается через графический интерфейс и интуитивно понятна. Я относительно подробно освещу процесс миграции почты.
Для начала я рассмотрю принцип по которому скрипт «Prepare-MoveRequest» находит контакты в целевом домене. Так как Вы уже создали почтовые контакты FIM'ом этот процесс необходимо понимать, иначе если что-то пойдет не так у Вас будет 2 одинаковых сущности в домене и Вы не будете понимать почему это так. Итак:
— Параметр «proxyAddresses» контакта совпадает с хотя бы одним из значений параметра «proxyAddresses» исходного контакта.
— Контакт является «Mail Enabled User'ом» и у него заполнены все поля в Active Directory которые должны быть заполнены у «Mail Enabled User'а».
— Скрипт должен быть запущен с параметрами "-UseLocalObject" и "-OverwriteLocalObject".
Если эти условия выполняются скрипт будет использовать уже созданные контакты. В целом для контактов созданных FIM'ом это всегда правда (я не встречал проблем).
Соответственно если Вы будет вначале запускать ADMT, а потом скрипт ваши действия должны быть приблизительно такими:
— Удалить мейл контакты тех пользователей которых Вы собираетесь мигрировать созданные FIM'ом.
— Мигрировать пользователей с помощью ADMT.
— Сделать мигрированных пользователей «Mail Enabled User'ами» и задать им параметр "-ExternalEmailAddress" таким чтобы он совпадал с одним из адесов исходных пользователей.
Теперь у Вас так или иначе есть пользователи которые могут принять себе почтовый ящик старого домена. Далее приведу Вам повершелл скрипты которыми можно произвести миграцию почты используя CSV файл.
Запускайте повершел эксченджа и… cd «C:Program FilesMicrosoftExchange ServerV14Scripts»
$c = (Get-Credential ВашСтарыйДоменАдминистраторПочтовойОрганизации)
Import-Csv c:_.csv | ForEach {.Prepare-MoveRequest.ps1 -Verbose -Identity $_.Identity -UseLocalObject -OverWriteLocalObject -RemoteForestDomainController имя_домен_контроллера_старого_домена -RemoteForestCredential $c}
Import-Csv c:_.csv | ForEach {New-MoveRequest -Identity $_.Identity -Verbose -TargetDeliveryDomain вашновыйдомен.com -TargetDatabase имя_базы_данных -RemoteLegacy -RemoteCredential $c}, так же рекомендую параметры "-BadItemLimit" и "-AcceptLargeDataLoss". Еще хотелось бы обратить Ваше внимание на свитч "-RemoteLegacy", дело в том что кроме него есть свитч "-Remote" и если Вы случайно вставите его, а не правильный свитч, эксчендж будет просить от Вас MRSProxy сервер, те фактически сервер с ролью CAS Exchange 2010.
Я использовал CSV файлы которые состояли только из списка ФИО, в моем случае этого было достаточно, в вашем может быть не достаточно.
Помните что почтовый ящик, который мигрирует в почтовую базу, должен отвечать требованиям базы (те размер ящика к примеру).
На данный момент я не могу вспомнить других подводных камней, если появятся интересные вопросы и ответы я дополню статью.
пс. полезные ссылки:
— Очень хорошая статья про FIM и сосуществование почтовых организаций
— Подробная статья про миграцию почты
— Полезная статья про автодисковер, scp и сосуществование почтовых организаций.
— Статья которая пригодится для понимания работы «Мув реквестов» и еще одна.
Автор: 4c74356b41