«Cross forest» миграция: Active Directory 2003 > 2008 r2, Exchange 2003 > 2010, пользователи и компьютеры. Синхронизация адресных книг

Я не умею писать вводное слово, потому сразу к делу.

Краткое описание методики миграции:
Миграция происходит side-by-side, те необходимо разворачивание параллельной инфраструктуры AD DS\Exchange и сопутствующих сервисов. Этапы:
1. Разворачивание целевой инфраструктуры.
2. Двустороннее доверие между доменами и установка ADMT.
3. Синхронизация глобальных адресных книг и настройка сосуществования почтовых организаций.
4. Собственно миграция, которая состоит из миграции почты, пользователей и компьютеров.

Подробнее под катом.

Для миграции пользователей и компьютеров — ADMT 3.2, для миграции почтовых ящиков — powershell, для синхронизации глобальной адресной книги — FIM, для синхронизации free\busy информации — 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'ов и free\busy информации.
Для синхронизации GAL'ов будет использоваться FIM 2010 R2. Для синхронизации контактов необходимо убрать из всех организацицонных единиц контакты которые не нужно синхронизировать (можно, конечно, тоже самое сделать фильтрами FIM, но это, во-первых, сложнее, во-вторых, хуже).
Для синхронизации free\busy информации будет использоваться Inter-Organization Replication Tool (подробнее тут).

4. Стратегия миграции почты.
Вернемся к пространству имен, если вы мигрируете из домена xxx.company.com в домен company.com, Вам необходимо будет мигрировать через промежуточный домен (только почту) например firm.com. Это необходимо по той причине что Exchange сервер «думает» что это дочерний домен и будет возвращать ошибку даже не смотря на то что все сделанно правильно.
В общем и целом у Вас 2 варианта:
— Вначале Prepare-MoveRequest потом ADMT (порядок: Prepare-MoveRequest, ADMT, New-MoveRequest)
— Вначале ADMT потом Prepare-MoveRequest (порядок: 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 /userd:domainadministratorAcct /passwordd:domainadminpwd
Установка ADMT (на домен контроллер в новом домене) происходит путем нажимания на кнопку далее некое количество раз (на SQL Express 2008 оно не встало, на 2005 легко). Если необходим экспорт паролей нужно ставить Password Export Service на PDC Emulator старого домена (после установки нужно запустить службу или переставить её на авто запуск, по умолчанию она стоит в ручном режиме и выключена).
Кроме этого необходимо исправить ключ реестра на контроллере домена с ролью PDC в новом домене. HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\AllowNT4Crypto для поддержки миграции рабочих станций под управлением ОС 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». Дальнейшая настройка идентична (кроме указания адреса повершела, этого делать не нужно). Ну или запустить в старом домене инсталлер Exchange сервера 2010 с ключем /PrepareAD ;)
Далее необходимо запускать агенты каждый раз когда Вам необходимо синхронизировать глобальные адресные книги или настроить расписание. Очередность запуска агентов не принципиальна, вначале необходимо запустить полный импорт агентов, потом полную синхронизацию, потом экспорт. После чего необходимо сделать подтверждающий импорт, это необходимо чтобы 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 Files\Microsoft\Exchange Server\V14\Scripts»
$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
  • +5
  • 20,5k
  • 9
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 9
  • 0
    Таким образом, все инструменты используемые при миграции являются бесплатными.

    А FIM разве бесплатен?
    • 0
      : О как-то совсем выпустил это из головы.
      Нет FIM платный. Ну чисто теоретически триал можно использовать 120 дней не покупая, это должно хватить. Я вам этого не говорил ;)
      Я поищу вариант синхронизации GAL'ов бесплатный.
      • 0
        Поищите пожалуйста — вопрос очень интересный! Мне в своё время пришлось PowerShell скрипт сваять, контакты создающий в соответствии с пользователями соседнего домена — но этот вариант мне как-то не очень нравится, с удовольствием сменил бы этот скрипт на что-то более «ровное».
        • 0
          Ну, я, конечно, не могу тестировать все найденные продукты, но вот что я нашел (не работает bb code):
          www.netsec.de/en/products/galsync — GalSync (вроде после заполнения формы оно бесплатное) есть еще Quest One Quick Connect Sync Engine, если Вы найдете где-то версии 4.7 или 5.0 — они бесплатны и по словам очевидцев — работают.
          www.wapshere.com/missmiis/a-galsync-powershell-script — Есть еще прекрасный MVP Carol Wapshere, она предоставила скрипт, но нужно допиливать + под хромом страничка грузиться не корректно: О
          www.microsoft.com/en-us/download/details.aspx?id=11149 — Если у Вас 2 ченджа 2003 то вот эта штука (Identity Integration Feature Pack) Вам поможет.
      • 0
        Данная стратегия IMHO имеет смысл только в ситуации крайней «ушатанности» исходной структуры AD.
        Мы мигрировали в том же домене.
        Сначала перенести всю структуру на стенд, (p2v ---> Hyper-V 2012). Отработали сценарий сосуществования Exchange 2003 + Exchange 2010. Исправили мелкие баги в AD. Задокументировали все действия. Повторили на стенде. Проверили. Повторили на рабочей среде. Всё прошло штатно. По завершению миграции всех почтовых ящиков на 2010 (около месяца) вывели Exchange 2003 из работы. Вместо него для старых приложений оставили SMTP-Relay на IIS на Windows 2003.
        А потом, по мере вывода 2003-х контроллеров ничего не помешало поднять уровень схемы до 2008-й.
        • 0
          Не вполне понимаю, в статье не идет речь про миграцию почты (исключительно) вопрос в миграции пользователей и почты из домена в домен. Зачем, кому и почему это нужно вопрос второй ;)
          • 0
            — Ну, Вы основной упор сделали всё же на почте :-) К тому же, если я правильно понял, имнно смена почтового домена подтолкнула к радикальному решению миграции?
            А так, да, миграция — тема мало освещённая, особенно личным опытом. Спасибо, было очень и очень познавательно и полезно!
            • 0
              Я сделал основной упор на почте потому что это единственное что заслуживает внимания, по сути.
              Остальное — далее, далее, далее. ну почти.
              И нет, не смена домена, я в интеграторе работаю.
              • 0
                Вариант сначала обновить почтовый сервис, а потом переименовать домен не рассматривали, или были ограничения в начальных условиях? Трудозатраты могли бы оказаться и меньше, как мне кажется.

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое