Exchange 2010 Cross-Forest Mailbox Moves

External Source:

After reading this post, you should have better understanding of:

  • How to plan your migration by understanding your current forest configuration and your desired configuration.
  • Different ways for you to synchronize user data between different AD forests.
  • Networking and Administrator permissions required to perform a successful cross-forest mailbox move.

The trends we are seeing currently show that companies are having more trouble understanding the different scenarios than performing the migration. There are several scenarios here, and Microsoft has tools, documentation, and scripts to assist in each one of them.

There are many reasons companies choose to have multiple forests or maybe find themselves with multiple forests, requiring cross-forest moves of users and mailboxes. For instance:

  1. Companies that merge, are bought out, or have absorbed another company in some manner.
  2. Companies who want to start fresh and leave a lot of legacy issues behind.
  3. Companies that have subsidiaries; segment their environment by Department, Geography, or for Security considerations.

The common Active Directory topologies that are supported in Exchange 2010 are as follows:

  • Single forest, single Active Directory site
  • Single forest, multiple Active Directory sites
  • Multiple forest, multiple Active Directory sites

Exchange deployment topologies vary due to organizational size and business complexity. Variations may include Single Forest, Resource Forest, Hybrid Forest, and Cross Forest topology. For purposes of discussion the following forest definitions will be used going forward:

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


1.) AD Enabled Mailbox Enabled

2.) AD Disabled Mailbox Enabled

Both mailbox enabled and disabled objects

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.

  • This may be a hybrid-forest scenario, typical during inter-forest migrations, because the user is security principal in both.
  • Hybrid is when there are both enabled and disabled users in the same forest.

2. Move from Account Forest to Exchange Resource Forest.

  • Company is splitting Exchange off to its own forest. Maybe due to outsourcing it, complex business organization, or desire to de-couple the Exchange org (e.g. messaging services) from the other infrastructure.

3. Move from Exchange Resource Forest to Account Forest. This is the reverse of #2.

  • Company is bringing Exchange back into the same forest for simplicity, to better integrate with OCS (though they are not required to be in the same forest), or collapsing/consolidating previously separate Exchange orgs into one user forest.

Cross-forest is when all users from the same organization are only contacts or mail enabled user objects in the other forest.

  • This is not referenced as a common scenario because it's usually in place between two separate legal entities and there would not be much movement (e.g. migrations) between them.
Active Directory Forest Configuration examples:

Below are some AD forest configuration examples. The forest scenarios don't necessarily imply there is a "move" or migration going on, some are long-term configurations.

Resource Forest

A Resource Forest scenario is a deployment that has at least one Exchange Resource Forest that hosts user mailboxes (but not active user accounts or enabled user accounts) and at least one other forest that hosts the AD user accounts. In other words, Exchange is installed into an AD forest which is separate from the "user account" AD forest.

  • A one-way forest trust where the resource forest trusts the account forest is created.
  • Each mailbox in the Exchange forest must have a corresponding user in the account forest, which is granted access to logon to the mailbox. This is referred to as a "Linked Mailbox".

The user objects in the Exchange forest are never logged onto by an end user and are disabled.

Hybrid Forest

Typically this scenario is maintained initially for co-existence while migrating and decommissioning a forest. It is different from a typical cross-forest scenario because there may be both enabled and disabled users in both forests for the same organization. In some cases, an organization may actually need to maintain the Hybrid Forest scenario over the long-term. While this is a supported scenario, it comes with additional complexity that must be addressed:

  • Mastering User and Exchange attributes occurs on both sides.
  • A tool such as Forefront Identity Manager (FIM), is needed to maintain consistent data on both sides, including the GAL.
  • Free/Busy and Public Folder access requires additional configuration, tools, and in some cases maintaining an Exchange 2007 server. (Please note that the IOREPL tool isn't currently supported with Exchange 2010 as a target server and in fact follows the Exchange 2003 Product support life cycle.)
  • Free/Busy, over the long-term will be best managed using the new Federation services (Microsoft Federation Gateway)

For more information refer to Understanding Federation


Both forests contain mailboxes and user accounts and contacts. This type of configuration has user accounts always enabled and mailbox enabled, with a corresponding contact in the other forest. The following diagram depicts how different objects are represented in the corresponding forest:

For more information on forests related to Cross Org migrations, refer to

Three Migration paths you need to choose from:

Depending on the current topology you have employed, you may find yourself planning to move users into the new forest and then following with moving their mailboxes as well. There are essentially three ways of planning to move your resources:

  1. A customized deployment in which you write ILM rules extension code to create the target Mail Enabled User (MEU). You should already have a custom ILM deployment for cross forest GALSync. Microsoft Identity Lifecycle Manager Service Pack 1 Feature Pack 1 (ILM 2007 SP1 FP1) GALSync Management Agent (MA) doesn't include several attributes now required in Exchange 2010, most importantly, msExchMailboxGUID. The out of the box GALSync MA cannot be used since it creates contact object instead of user object required for Online Mailbox Move. The ILM sample code demonstrates how to sync source mailbox as Mail Enabled Users (MEU).

Note: Customers using "out of the box" GALSync MA may probably not know how to customize ILM.

  1. Use Prepare-MoveRequest.ps1 script to create the target MEU. It is important to note that the PrepareMoveRequest script works in conjunction with "out of the box" Exchange GALSync MA for ILM (or FIM). This means the script has built-in logic to convert target Mail Enabled Contact (MEC) created by ILM GALSync MA into the required MEU.
  2. Use Prepare-MoveRequest.ps1 script and then use ADMT to migrate the other attributes on the user object.

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:

    1. A correct GAL immediately for co-existence (short or long-term)
    2. Permissions for delegates and mailbox access are preserved during the move using the msExchMailboxGUID attribute. Since this is populated on the target object with PrepareMoveRequest.ps1 the permissions will be maintained in the cross-forest move.

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.

ILM and PrepareMoveRequest Scenarios broken-down:

There are basically 5 steps involved with moving a mailbox across a forest in Exchange 2010. They are: Preparing Active Directory, Network Prerequisites, Administrator Permissions, Moving Mailboxes and Clean-up. Each of these steps is series of smaller steps that need to be taken in order to move a mailbox from one Exchange forest to and Exchange 2010 forest.

The first step in Cross Forest mailbox moves is preparing Active Directory. In the target forest a mail enabled user account must be created with certain attributes. The method used for creating the target account and setting the mandatory attributes is up to the organization administrator. ADMT and ILM can be used to synchronize/pull over the attributes from the source forest.

Exchange Provisioning using ILM 2007

If you deployed ILM for cross-forest global address list (GAL) synchronization, the recommended approach to creating the mail-enabled user is to use ILM 2007 Service Pack 1 (SP1) Feature Pack 1 (FP1) or Forefront Identity Manager 2010 (FIM) GALSync MA. We've created sample code that you can use to learn how to customize ILM to synchronize the source mailbox user and target mail user.

For more information, including how to download the sample code, refer to this link.

To deploy Exchange 2010 in a cross-forest topology, you must first install Exchange 2010 in the new forest. Then, provision the mail-enabled users representing the source mailboxes so that Exchange 2010 can move the mailbox and migrated users can see all addresses.

Deployment steps:

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


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:

  1. Creating a brand new user in the local forest where the MBX will be moved to.
  2. A local recipient, either a MEU or MEC already exists, created by an external agent such as ILM - If the local forest object is a mail contact, the script will convert the mail contact to a mail user while persisting the contact's existing exchange-related attributes. If the local forest object is a MEU, the script will reuse this mail user and stamp the essential attributes on the local mail user object. The administrator must specify the -UserLocalObject switch in order to tell the script to use this scenario.

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

Process Overview: Run PrepareMoveRequest script first and then ADMT

  • Prepare MEU

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.

  • Run the below commands in the target forest

$Local = Get-Credential

Input the target forest's Administrator Credentials in "DomainUser" 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 "DomainUser" 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.

  • Run the PrepareMoveRequest script in the target 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.

    • If the local matching object is found, then the local object will be used.

          Note: If the local matching object is found and UseLocalObject is not defined, the script will throw an error.

    • If the local object doesn't exist, even if UseLocalObject is specified, the script will still create a new one.

If you are sure that you didn't prepare local object before, you could remove this parameter to ensure accidental overriding.

  • In the target forest, we get a new disabled mail-enabled user AD object created with some of the following Exchange attributes:

legacyExchangeDN, mail, mailnickname, msExchmailboxGuid, proxyAddresses, X500, targetAddress, userAccountControl, userprincipalName

  • SIDHistory is empty. This is expected because Exchange doesn't migrate SIDs. At this point all of the required attributes to perform a mailbox move have been synced into the target forest.
  • Run ADMT in the target forest.

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.

  • Check the results in the target forest: The user should now have SIDHistory matching the objectSid of the source object (all other attributes are left untouched)
Gotchas running ADMT first and then PrepareMoveRequest script:

Currently, several customers are running ADMT first and then running the PrepareMoveRequest script. When a user is created via ADMT, the PrepareMoveRequest script doesn't work since there are no proxyAddresses for the script to match the source forest user with the target forest user.

The recommended approach is to copy at least 1 proxy address using ADMT. However, if you use the -UseLocalObject parameter, the script will only copy the 3 mandatory parameters (msExchMailboxGUID, msExchArchiveGUID, msExchArchiveName). This is not very useful. Customers can simply copy these 3 themselves.

Important Note: In SP1, we are adding the OverwriteLocalObject parameter. This is designed for the ADMT case. ADMT can copy the SIDhistory, password, and proxyAddresses, and the PrepareMoveRequest script can sync the other email attributes. In this case, it will copy attributes from source to target, so it's the opposite of UseLocalObject.

ADMT and Exchange Attributes

ADMT transfers Exchange attributes (e.g. homeMDB, homeMTA, showInAddressBook, msExch*) which make the target user look like a legacy mailbox in the target domain. This leaves the target account in an invalid state (e.g. homeMDB still points to the old forest) which is unexpected for the

PrepareMoveRequest.ps1 script. To prevent this, Exchange attributes are excluded from ADMT.

The PrepareMoveRequest.ps1 script can identify and match existing accounts in the target forest based on their SMTP address (proxyAddresses attribute).

Note: It can also do this based on the MasterAccountSid, but this is only populated for accounts in a resource forest scenario.

More precisely, the script will use the existing target accounts if the following are true:

  • The target account has a value in proxyAddresses which matches one of the proxyAddresses of the source account.
  • The target account is a mail enabled user i.e. you can retrieve it with the Get-Recipient command. For this to succeed, it needs to have mail attributes like 'mail', 'targetAddress' etc.
  • You need to specify the -UseLocalObject parameter in the script

If all these are true, the script will copy further attributes needed (especially msExchMailboxGUID) to the target account so that the move request can process the accounts.

By default, ADMT 3.1 does NOT migrate "mail", "msExchMailboxGuid" and "proxyAddresses" attributes  because of security reasons. This is documented in the below article under "System attribute exclusion list"

Managing Users, Groups, and User Profiles

Important Note: When running ADMT second after ILM due to both forests having the same schema (attributes), unexpected Exchange attributes are brought over.  This can cause issues.  HomeMDB for example is brought over and causes the MEU to look like a legacy mailbox, and is unusable.

To resolve the problem of ADMT being run first, and leaving the user in an invalid state for the PrepareMoveRequest.ps1 script, you can create the following VB script/ADMT COM object model to exclude all Exchange attributes from being migrated by ADMT.

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

Network Prerequisites

When mailboxes are moved from one Exchange 2010 forest to another Exchange 2010 forest, the process is handled through Exchange 2010 Client Access Servers using the MRSProxy service. The only port required to be open between the forests for MRSProxy to use HTTPS traffic is port 443. This works even if the source mailboxes are on 2003 or 2007 MBX servers as long as an Exchange 2010 CAS server exists in both organizations.

Note: The whole forest doesn't need to be Exchange 2010 in order to use the MRSProxy. If there is at least one Exchange 2010 CAS in the forest (with access to the Mailbox Servers and AD), it can be used as the MRS Proxy for moves from a mostly Exchange 2003 or Exchange 2007 forest. This can be called the "Remote" scenario (or the "MRSProxy" scenario).

If the mailbox is being moved from legacy Exchange forest then the mailbox replication service will need to have the same TCP ports open that is needed for a normal local mailbox move. Listed are the TCP ports that are needed for a local mailbox move. These ports will be needed to be open both ways for mailboxes to be moved.

Note: This is more of the "Remote Legacy" scenario, but it can be used between two Exchange 2010 forests as well as between one Exchange 2010 forest and one Exchange 2003/2007 forest.



808 (TCP)

Mailbox Replication Service uses to communicate

53 (TCP)


135 (TCP)

RPC End Point

389 (TCP)




1024 > (TCP)

if mailbox store is not statically configured then 1024 higher ports need to be open

88 (TCP)


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.

Also it is necessary for servers in both forests to successfully perform name resolution using DNS.

For cross forest mailbox moves via the MRSProxy service, the source and target servers use certificates to encrypt the HTTPS traffic. The CAS Servers in the source and target forests must have installed a valid certificate that has been issued by a trusted certificate authority recognized by the server in the opposite forest.

Administrator Permissions

In order to move mailboxes across different Exchange forests the account used to initiate the move request in the target forest and the account used to access the mailbox and directory in the source forest must have the proper permissions. The permissions that are needed for the account in the source forest depend on the type of move.


The account must have the privileges made available by membership in the Recipient Administrators group.

Remote Legacy

The migration account must have the following permissions.

  • Exchange Server Administrators role
  • Exchange Recipient Administrators role
Destination Forest Permissions

In the target Exchange 2010 organization the account used to create and manage the move request must be a member of the Organization Management or Recipient Management role groups, or have the following RBAC roles assigned either directly or through group membership:

  • Move Mailboxes role
  • Mai