GD Bloggers

This is the blog site for Microsoft Global Delivery Communities focused in sharing the technical knowledge about devices, apps and cloud.
Follow Us On Twitter! Subscribe To Our Blog! Contact Us

Exchange 2010 Cross-Forest Migration Step by Step Guide – Part III

Exchange 2010 Cross-Forest Migration Step by Step Guide – Part III

  • Comments 23
  • Likes

In this part of Cross-Forest Migration Guide we will solve the second challenge but before that let’s take a look again on the current environment:



Second Challenge: Move Mailbox Error:

As explained in Part II, we will use ADMT first to migrate SID History, Password and other AD attributes then we will use Prepare-MoveRequest, the idea of these steps is to get healthy Mail Enabled User (MEU) that will be used later to move the mailbox from the source forest to the target forest, after finishing Part II now we have the healthy MEU and we can check the LDAP properties for the mandatory attributes required for the move to succeed.


The following snapshot shows the LDAP attributes:



Now this is the time to run New-MoveRequest to migrate the mailbox from the source forest to the target forest.

The following snapshot shows the result of running New-MoveRequest:


The error is: Cannot find a recipient that has mailbox GUID


The error is clearly saying that there is no MEU with the mandatory attribute msexchmailboxguid, however when we check the MEU LDAP property:


The mailbox GUID is there (of course it’s there because Prepare-MoveRequest migrated this attribute, check Part II), so what’s the problem?!


We have MEU with the required msexchmailboxguid and each time we try to migrate the mailbox we will get the same error: Cannot find a recipient that has the mailbox GUID.


The problem here that when the remote forest implies a child name relationship, Exchange 2010 will think that this is a child domain and then the strange error will be returned. In our case the source forest name is and the target forest name is so Exchange will think that the target is child domain from the source forest and it will fail.


So what’s the solution?

We have two painful options:

1. Export all mailboxes as PST files from the source forest and then import it in the target forest: this option is based on big bang approach where there is no co-existence. This option might be considered in small companies where we can disconnect the source forest, export the PSTs and import it to the target forest in reasonable downtime.

2. Co-Existence: when co-existence is required in enterprise companies with thousands of users the only option will be creating Intermediate Forest.


Intermediate Forest:

As you might guess this will be our option as co-existence is required, in this option we will do the migration on two steps.

First we will need to create a new Active Directory Forest with a different name in our scenario we will use This forest will contain Exchange 2010 server we can use single server with HUB/CAS/MBX installed on the same server, as this forest will be intermediate and will not serve any users you may decide that high availability is not required.


Now the migration will be done on two steps as following:

1. Move the mailbox of the user (batch of users) from the source forest to the intermediate forest

2. Move the mailbox of the user (batch of users) from the intermediate forest to the target forest


After implementing the intermediate forest it’s very important to complete the following tasks before starting the migration:

1. Apply SSL certificate on the intermediate forest that can is trusted and can be validated from the target forest. If Exchange 2010 server in the target forest can’t validate the certificate moving mailbox will fail.

2. Enable the MRS Proxy service: this service responsible of moving the mailboxes from/to Exchange 2010, as the intermediate Exchange server will be 2010 then moving mailboxes will not work without enabling the MRS Proxy service.


The following section contains the detailed steps required to prepare the intermediate forest:

1. Install SSL Certificate

This certificate must be trusted and validated from the CAS servers in the target forest. The certificate could be generated from internal Certification Authority trusted by the CAS servers in Corp forest.

The steps to request to install the certificate as follow (on Intermediate Forest Exchange Server):

a. Request certificate:

I. Open Exchange Management Shell:

II. $data = New-ExchangeCertificate -GenerateRequest –domainname,, -FriendlyName Int-CAS

II. Set-Content -path "C:\CertRequest.req" -Value $Data

b. Import the Certificate:

I. Import-ExchangeCertificate -PrivateKeyExportable:$true -FileData ([Byte[]]$(Get-Content -Path C:\cert.cer -Encoding Byte -ReadCount 0)) | Enable-ExchangeCertificate -Services IIS


2. Enable MRSProxy Service

This step should be completed before moving the mailboxes from the Intermediate forest to the target forest.

a. On the Client Access server in the Intermediate Forest (, open the following file with a text editor such as Notepad:

C:\program files\microsoft\Exchange\V14\ClientAccess\ExchWeb\EWS\web.config

b. Locate the following section in the Web.config file:

<!-- Mailbox Replication Proxy Service configuration -->

DataImportTimeout="00:01:00" />

c. Change the value of IsEnabled to "true".

d. Save and close the Web.config file.


In this part we addressed the second challenge and now we are ready to start the migration, in the next part we will start by configuring co-existence between the three forests.


Exchange 2010 Cross-Forest Migration Step by Step Guide – Part I

Exchange 2010 Cross-Forest Migration Step by Step Guide – Part II

Exchange 2010 Cross-Forest Migration Step by Step Guide – Part III

  • Wow ! Very useful. Waiting for the next one. When?

  • Hi,

    Great post, as the next one been posted yet?

  • Nice n crisp article series, waiting curiously for part IV.........

  • dude where's part 4? I really really need the co-existence aspect of the migration!!! :-) Shared namespace, free/busy between the forests, etc...

    Great work so far, but it seems like with part 3 you focused on a potential "gotcha" that most companies who are migrating (due to an acquisition or merger) won't encounter! I'm sure it helped some folks out there and they really appreciated the help, though!

    I appreciate your effort on this!

  • next one pls

  • Same as others really need co-existence information and how to do so migrated mailbox users can still communicate with each other

  • Well I just found this page a year after it was made but still no sign of any other parts. Can someone else pick it up as it was getting good !

  • Very useful..can't wait for part IV

  • It is really Good Article, thanks for sharing

    Best Regards,


  • A year and a half later and nothing additional. Will this ever be completed? This would be a very useful source of information.

  • Great write up. I would love to see scenario 1

  • Great write up. I would love to see scenario 1 or even a part 4 here.

  • Thanks for the series...very helpful. Still no Part IV?

  • amazing information. still waiting part IV. Please write for us :)

  • Thanks for sharing the useful information for Cross forest migration. It's really very complicated and time consuming process. It's require proper planning before starting the migration. To make the migration process faster and easy, there are some third party tools available in the market. You may also take help from them like us. We successfully migrated from Exchange 2010 SP2 server to Exchange 2013 server with the help of this migration utility:

    One of the best aspects of this advance program is that it repairs and rebuilds the corrupted items in information store database during the migration so that all data could be easily available to all users in destination forest. You may also take a look at all its features !

    Good Luck !

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment