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:

  • 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

Both

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

Cross-forest

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 http://msexchangeteam.com/archive/2006/11/02/430289.aspx

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
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:

  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 http://technet.microsoft.com/en-us/library/ee861103.aspx.

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 "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.

  • 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
http://technet.microsoft.com/en-us/library/cc974331(WS.10).aspx

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

http://support.microsoft.com/kb/937537

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). By default, MRSProxy is disabled. To start MRSProxy on the Client Access server in the remote forest, you must modify the Client Access server's Web.config file. For more information refer to http://technet.microsoft.com/en-us/library/ee732395.aspx. If CAS servers are behind the NLB, you should do this on all servers that can take the load.

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.

Port

Protocol

808 (TCP)

Mailbox Replication Service uses to communicate

53 (TCP)

DNS

135 (TCP)

RPC End Point

389 (TCP)

LDAP

3268

LDAP

1024 > (TCP)

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

88 (TCP)

Kerberos

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.

Remote

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
  • Mail Recipients role
  • Mail Recipient Creation role

Only the Move Mailbox role is required to have access to the New-MoveRequest command. However, the Mail Recipients and Mail Recipient Creation roles may also be required to creating and managing target accounts in preparation for mailbox moves.

Moving the mailbox

There are two methods to move a mailbox across forests using Exchange 2010. The method used depends on the type of cross forest move. Both Remote and Remote Legacy cross forest moves can be performed from the Exchange Management Shell, but only Remote moves can be performed from the Exchange Management Console.

Exchange Management Console

To create a new move request for a cross forest move using Exchange Management Console (EMC), the console must have a session open to both the target and source forests at the same time using the feature Add Exchange Forest. This makes it possible to maintain a connection to an Exchange 2010 server in the source forest, and an Exchange 2010 server in the target forest. With a connection to servers in both source and target organizations via the EMC, you will be able to identify a mailbox that is to be moved from the source forest, while initiating the move request on an Exchange 2010 server in the target forest.

To initiate a cross forest move with the Exchange Management Console, navigate to the Mailboxes folder in the Recipient Configuration node of the source forest, select the mailbox(es) to be moved, and then select New Remote Move Request. This starts the New Remote Move Request.

Exchange Management Shell

To initiate a cross forest mailbox move in the Exchange Management Shell a New-MoveRequest command must be issued with Remote* parameters. Move requests issued without Remote* parameters are local moves within the same Exchange forest.

The New-MoveRequest cmdlet requires certain attributes to be synchronized between the source MBX account and the target MEU account in order for the mailbox move to succeed. This is described in the previous steps.

In the target domain, perform the move request by running the below cmdlet

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

Clean-up

When the MRS completes the moving of mailbox data from the source forest to the destination forest it mailbox enables the target user account. If the user account is disabled it leaves the account disabled. The MRS mailbox disables the source account, and converts it into a MEU account with a target address that refers to the primary SMTP address of the target mailbox account. The New-MoveRequest takes the TargetDeliveryDomain parameter. This is what determines which targetAddress to stamp. MRS checks the list of proxyAddresses for one (not necessarily the primary SMTP) that matches the FQDN specified in the TargetDeliveryDomain. The MRS will stamp this address as the targetAddress on the MEU. We moved away from using the primary SMTP address because there is a need to maintain the primary STMP when moving mailboxes cross-forest since this is part of a user's identity. When the primary SMTP address is the same on both forests, mail flow becomes more difficult.

If the source account is to be retired and removed from the source forest, the administrator must plan for this manual operation outside of the mailbox move operation.

What's coming in Exchange 2010 SP1

As mentioned earlier, SP1, will include the PrepareMoveRequest script as part of the install. Additionally, we are fixing a couple of issues with that script:

  1. Requiring separate local and remote credentials to run the script.
  2. LegacyExchangeDN not set on the new user object after converting local contact to local user.
  3. When specifying TargetMailUserOU, we will only search OUs (instead of other object class).
Common Issues

The most common issues related to PrepareMoveRequest script are listed below. These are not relevant if you have deployed the customized ILM, or if you have already run PrepareMoveRequest.

  1. Not able to match source forest user with target forest user. This is mainly due to the fact the script relies on proxyAddresses to match objects, so the target forest user needs to have at least 1 proxy address that matches the source
  2. Inadequate AD permission to delete/add recipient objects. The script manipulates AD directly and invokes the Update-Recipient cmdlet at the end, so you need to have the appropriate permission to change AD and call Update-Recipient. Another thing you can check is whether the TargetMailUserOU is set correctly.
  3. The current script does not have good support for users created by ADMT. The updated PrepareMoveRequest script in SP1 will support a new parameter "OverwriteLocalObject" for users created by ADMT and it will copy attributes from the source forest user to the target user.
  4. "UseLocalObject" - This is the script logic where we assume ILM has already created the target forest MEC or MEU, and you want to keep the target forest attributes. So the script will convert the target forest MEU or MEC to the required MEU for MBX move.

Finally, a few words of thanks:

I had the privilege of working with several SMEs from the Product Group, Consulting, UE and Support who helped me visualize, plan, develop and complete this blog. I would like to call out Ian Liu (Program Manager) who was instrumental in sharing his vision and being accessible at all times while writing this blog. I also want to thank Daniel Talbot for his expertise on this subject and his many contributions to the blog. Other contributors that I'd like to express gratitude are Andrew Ehrensing and Huangjian Guo. Thanks to Ying Zhang, Ramon Infante, Jeff Kizner, Kweku Ako-Adjei , Ben Winzenz, Kristi Simmons, Bill Haenlin, Laura La Fleur, Nino Bilic, Jonathan Runyon and Ayla Kol for their review and feedback. Last but not the least, I'd like to thank William Rall for his innumerable thorough reviews and feedback that helped shape this blog.

- Nagesh Mahadev