EDIT 8/12/2010: Added a note about the necessity to manually enable MSProxy in remote forest. We are seeing some trends where quite a few customers are migrating mailboxes to a new Exchange organization, in a different Active Directory (AD) forest. This blog post is aimed at helping to explain the fundamentals of what is required to move mailboxes across forests so that you can be prepared with the correct data, make better plans, and successfully perform a migration without encountering painful problems. The blog post doesn't cover how to setup and configure shared address space or Free/busy. After reading this blog post, you should have better understanding of:
Most of the Cross-Org Move Mailbox scenarios are closely related to the Active Directory Forests involved in the migration. There are 3 major scenarios to be considered: 1. Move from Exchange Forest A to Exchange Forest B. This means that the user is a security principal in forest A and after he is moved to forest B, he is a security principal in forest B as well.
Forest Name Active Directory user object status Mailbox Status Exchange Forest Enabled User Object Mailbox Enabled Account Forest Enabled User Object No mailbox enabled objects Resource Forest Disabled User Object (linked to a separate enabled user object in an Account Forest) Mailbox Enabled Hybrid Forest Both 1.) AD Enabled Mailbox Enabled 2.) AD Disabled Mailbox Enabled Both mailbox enabled and disabled objects
Note: Customers using "out of the box" GALSync MA may probably not know how to customize ILM.
Important Note: Our recommendation on working with ADMT is to rely on the PrepareMoveRequest script to create the local user object for mailbox move, and then use ADMT to migrate SIDHistory and password and merge this into the MEU created by PrepareMoveRequest.ps1 script.
The point of doing ILM or the script first is to ensure the MEUs are all created with the correct msExch* attributes. This also ensures the following benefits:
At this point it doesn't matter if ADMT is used to migrate/merge the user objects all at once or in "batches" of user objects. ADMT can be controlled better to ensure only merging of SIDhistory and certain other mandatory attributes if it's not already populated. Running ADMT first, without ensuring exclusions on msExch* attributes, can cause corrupted objects which the script cannot correctly convert with the -UseLocalObject switch. Important Note: When SP1 ships, we will support running ADMT first and then the PrepareMoveRequest script later.
Note: The main purpose of the sample code is to encourage customers to customize, or add more functions to the sample code. The sample code is very basic and it only copies very basic attributes. Customers who rely on this sample code may find many attributes missing.
Note: The Availability service is supported only for Outlook 2007 clients and newer. If Outlook 2003 clients still exist in one of the forests, the only solution will be to deploy Exchange 2007 first in the Exchange 2010 organization (because adding it late is not possible if Exchange 2010 is deployed first) and implement the IOREPL tool to replicate Free/Busy system public folders to the Exchange 2007 server. The Free/Busy system public folder replicas can then be replicated using PF replication to your Exchange 2010 server. IOREPL will not replicate a public/system folder directly to an Exchange 2010 server.For more information review: Exchange Provisioning using ILM 2007 and FIM 2010 http://technet.microsoft.com/en-us/magazine/ff472471.aspx Prepare-MoveRequest.ps1 It may be difficult for some customers to synchronize the prerequisite attributes for performing mailbox moves without using ILM. You may have some other solution in place that does not synchronize the required attributes, and does not allow customization. Small companies may not have a solution at all and simply wish to transition users from an existing forest (that is set to be obsolete) to a new, clean Exchange 2010 forest. To solve this problem, the PrepareMoveRequest script has been written to prepare the AD target object and synchronize the required attributes for cross-forest moves to work. The script creates the target MEU if necessary, or synchronizes an existing MEU when possible. The PrepareMoveRequest script prepares Exchange 2003, Exchange 2007, and Exchange 2010 mailbox users for migration to an Exchange 2010 forest. For more information about using the sample script, refer to the following link. The PrepareMoveRequest script supports 2 scenarios:
Note: The scenario that the script doesn't support is that some external process created a local user object and relies on the script to copy all the attributes and links from the remote MBX to the local user. This is the ADMT scenario described after this scenario.In order to run New-MoveRequest cmdlet to move a mailbox from an Exchange 2003/2007/2010 source forest to an Exchange2010 target forest, the target forest must contain a valid MEU account with the set of AD attributes described in this section. These attributes are synchronized by the PrepareMoveRequest script. There are certain mandatory attributes that should be present on the target mail user for New-MoveRequest to run properly. These attributes are always set by the PrepareMoveRequest script, either as they are taken from the source MBX, or as determined by the script. The attributes are listed here http://technet.microsoft.com/en-us/library/ee861103.aspx. Process Overview: Run PrepareMoveRequest script first and then ADMT
To create the target mail enabled user account in an Exchange 2010 forest from the source mailbox enabled account in the source Exchange forest, the PrepareMoveRequest script must be executed in the target Exchange 2010 forest. The script pulls the mailbox enabled account attributes from the source forest.
The script can be used to provision one target MEU account at a time, but can also take data that is passed by pipeline as input to provision MEUs in bulk.
Since PrepareMoveRequest script relies on Update-Recipient task that exists only in Exchange Management Shell, all the below commands need to be run in Exchange Management Shell. Running in PowerShell will only result in error.
$Local = Get-Credential
Input the target forest's Administrator Credentials in "Domain\User" and Password format.
Note: The account used should have permissions to call Update-Recipient which is available only to Exchange Enterprise Admin.
$Remote = Get-Credential
Input the Source forest's Administrator Credentials in "Domain\User" and Password format.
Note: Since the PrepareMoveRequest script will also update the source object's proxyAddresses to include the target object's legacyDN as X500 address, the account used to run this command should have Read and Write access for the source forest.
[PS] C:\>.\Prepare-MoveRequest.Ps1 -Identity "DN of a user from SourceForest" -RemoteForestDomainController "FQDN of Source DC" -RemoteForestCredential $Remote -LocalForestDomainController "FQDN of Target Forest DC" -LocalForestCredential $Local -TargetMailUserOU "Distinguished name of OU in TargetForest" -UseLocalObject
Note 1: You can use the -Verbose flag to check which attributes have been set if you want to get a detailed list of the attributes that were touched.
Note 2: You can use the -UseLocalObject parameter here.
Note: If the local matching object is found and UseLocalObject is not defined, the script will throw an error.
If you are sure that you didn't prepare local object before, you could remove this parameter to ensure accidental overriding.
legacyExchangeDN, mail, mailnickname, msExchmailboxGuid, proxyAddresses, X500, targetAddress, userAccountControl, userprincipalName
Note: Currently the Active Directory Migration Tool (ADMT) v3.1 is not supported on Windows 2008 R2 Servers. If you plan to use ADMT v3.1, it must be installed on Windows 2008 server.
Set O = CreateObject("ADMT.Migration"). o.SystemPropertiesToExclude = " HomeMDB,HomeMTA,showInAddressBook,msExchHomeServerName, mail, proxyAddresses, msExch*"This allows update-recipient to find the target object and match it with the source account and merge the two together. For more information, refer to the below article: You will find that several custom attributes are missing when you use ADMT to migrate users between two forests http://support.microsoft.com/kb/937537
|808 (TCP)||Mailbox Replication Service uses to communicate|
|135 (TCP)||RPC End Point|
|1024 > (TCP)||if mailbox store is not statically configured then 1024 higher ports need to be open|
|445 (TCP)||Microsoft-DS Service|
|443 (TCP)||Mailbox Replication Proxy service uses port 443 to communicate with other Exchange 2010 client access server via HTTPS.|
New-MoveRequest -Identity "Distinguished name of User in Target Forest" -RemoteLegacy -TargetDatabase "E2K10 Mailbox Database Name" -RemoteGlobalCatalog "FQDN of Source DC" -RemoteCredential $Remote -TargetDeliveryDomain "Target domain name"After the move completes, the proxyAddresses and targetAddress attributes should have changed in the target forest. If the accounts are disabled in the target forest, enable it, set a password and log into OWA and test. After Online Mailbox Move (OMM), the source object is changed from MBX to MEU and target object is changed from MEU to MBX For more information on performing cross forest moves in Exchange 2010, refer to Managing Move Requests
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.