Cross-forest migration

[narga]

В сети полно мануалов по кросс-форест миграции, а это для моей записной книжки.
Уровень леса и там и там 2008r2, exchange 2010.

1. В target лесу делаем Prepare-move-request
Синтаксис:

$local =Get-Credential - таргет
$remote =Get-Credential - исходный
C:\Program Files\Microsoft\Exchange Server\V14\Scripts>.\Prepare-MoveRequest.ps1 -Identity user@domain.com -RemoteForestDomainController dc.sourcedomain.com -RemoteForestCredential $remote -LocalForestDomainController dc.targetdomain.com -LocalForestCredential $local -UseLocalObject -Overwrite -verbose

2. Запускаем ADMT
Миграция пользователя.
User account migration wizard – source domain, target domain
User selection option – select users from domain
User selection – добавляем выбранного пользователя
Organization unit selection – выбираем нужное ou
Password options – Migrate passwords – Password migration source DC DC with PES
Account Translation Options – Target Account State – Target same as source, Sourse account disabling оставляем пустым. Обязательно ставим галку Migrate user SIDs to target domain.
На запрос аудита отвечаем YES (если не включили политику)
User account - Вводим логин-пароль администратора исходного домена
User options – Translate roaming profiles – Update user rights – Fix users group memberships
Exclude specific object properties from migration. Выбрать и исключить (тип user):

HomeMDB
HomeMTA
mDBUseDefaults
msExchHomeServerName
msExchMailboxSecurityDescriptor
msExchMDBRulesQuota
msExchPoliciesIncluded
msExchRecipientDisplayType
msExchRecipientTypeDetails
msExchUserAccountControl
msExchVersion
showInAddressBook

Conflict Management – Migrate and merge conflicting objects – отметить move merged object to the specified target Organization unit
Finish

3. Перемещаем локальный профиль.
Security Translation Wizard
Previosly migrated objects
Sourse domain, target domain
Select computers from domain
Add – выбрать компьютер
Translate objects – user profiles
Security Translation Options – add
Finish
В появившемся окне нажать run pre-check and agent operation

4. Move-request. Выполняется в целевом домене. Синтаксис следующий:
New-MoveRequest -Identity user@domain.lan -Remote -TargetDatabase databasename -RemoteHostName cas.sourcedomain.lan -RemoteCredential

$remote -TargetDeliveryDomain stg.ru -DomainController dc.target.lan


Дополнения

Проверить, что SID-хистори перенеслась после миграции пользователя, можно либо просмотрев лог ADMT, либо посмотрев атрибут sIDHistory у

пользователя в перенесённом домене. Атрибут не должен быть пустым.

При выполнении prepare-moverequest можно получить следующее:
ould not find the default Administrative Group 'Exchange Administrative Group (FYDIBOHF23SPDLT)'.
+ CategoryInfo : NotSpecified: (0:Int32) [Update-Recipient], DefaultAdminist...tFoundException
+ FullyQualifiedErrorId : 27C11212,Microsoft.Exchange.Management.RecipientTasks.UpdateRecipient

В этом случае у нас не пройдет Invoke Update-Recipient, следовательно, атрибут legacyExchangeDN не будет установлен. При попытке сделать move-request получим отлуп:  critical property 'LegacyExchangeDN' is missing in the UserMailbox object

В этом случае либо делать самому Update-Recipient, либо прописывать LegacyExchangeDN вручную.

Если при попытке сделать move-request получаем:
The target recipient user' must be a mail-enabled user when the primary mailbox is moving cross forest.
+ CategoryInfo : InvalidArgument: (user@domain.com:MailboxOrMailUserIdParameter) [New-MoveRequest], RecipientTaskException
+ FullyQualifiedErrorId : CBF0E63A,Microsoft.Exchange.Management.RecipientTasks.NewMoveRequest

Значит в ADMT не были исключены определённые атрибуты. Смотрим пользователю в атрибуты, атрибут msExchHomeServerName. Если там ссылка на MBX-сервер из старого домена, значит так и есть. Удаляем атрибут, запускаем заново. После того, как пройдет move-request, в msExchHomeServerName появится имя нового сервера.

Если вы по какой-то причине сначала сделали переезд ADMT до prepare-move request, при попытке выполнить prepare получите следующую ошибку:
Cannot create mail enabled user because an existing object with type already has the same proxy addresses/MasterAccountSid

В этом случае вам придётся прибить всё из атрибута proxyAddresses и сделать учетку mail-enabled:
Enable-MailUser -DomainController dc.domain.lan -Identity user
ExternalEmailAddress – user@target.local, дополнительно proxyaddress user@domain.com
В исходном домене учетке сделать дополнительный proxyaddress user@target.local

После этого осуществить prepare-moverequest, где в качестве user необходимо написать user@target.local
Дальше move-request – как обычно.

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