Moving mailboxes between different Exchange organizations (which means different AD forests) is not something that is easy thing to do. Luckily, it’s not something you do every day, but when you need it, it’s better to have procedure ready and tested. While authoring 20342 MOC course (Exchange 2013 Advanced Solution) I was making a lab for moving Exchange mailboxes between different Exchange organizations, and I must admit that I spent quite amount of time to make it work. That’s why I decided to pull some important parts and make them available to all my readers.
First, why would you want to do this? As I said, occasions for this procedure are not often, but sometimes you just have to do this. For example, if you merge two organizations or if you want to have a fresh start with new AD DS and new Exchange, while all your resources are still in old AD DS. Whichever reason you have, you’ll have the same starting point which is – accounts and mailboxes in one organization (Let’s call it OrgA) and (fresh) AD DS and Exchange in another organization (Let’s call it OrgB). When saying organization, I mean Exchange organization, not necessarily another company (but mandatory another AD DS forest). Let’s presume that OrgA has Exchange Server 2010 deployed, while OrgB has Exchange Server 2013, and we want to move mailboxes from OrgA to OrgB.
Since Exchange Server is very deeply integrated with AD DS, you can’t just move mailboxes – it’s a bit more than that. You also have to move user objects. This can be done in several ways. Easiest thing to do is to use ADMT (Active Directory Migration Tool) which can greatly help in moving AD accounts from one domain to another, together with all attributes, as well as with password sync. You can also use ForeFront Identity Manager for this purpose, although it might be a bit complicated to deploy FIM just to do this, but if you have it in place, you can use it to provision user account objects in another domain. ADMT is definitely best choice, however, at this time, we still don’t have ADMT that can move user objects from Windows Server 2008 domain to Windows Server 2012 domain.
Luckily, there is a script in Exchange Server 2013, which can great help in doing this. The script prepares the AD DS target object and synchronizes the required attributes for cross-forest moves to work. The script creates the mail enabled user account in the target forest if necessary, or it synchronizes an existing user when possible. This script is called Prepare-MoveRequest.ps1, and it is in the Program Files\Microsoft\Exchange Server\V15\Scripts folder. This script is fairly simple to use, but be aware that this script does not move passwords, so user account that you move will be disabled (and without password) when you move it to OrgB. If you can live with this, you’ll be fine. Otherwise, you will have to use ADMT to move user objects, but then you should be aware that this script in Exchange Server 2010 is not fully compatible with user objects moved with ADMT, at least with current version of ADMT. This is because ADMT does not migrate Exchange attributes on user object, which can cause account in destination domain to look like a legacy Exchange account. The Prepare-MoveRequest script in Exchange Server 2013 supports a new parameter, OverwriteLocalObject, for user objects created by ADMT. The script copies the mandatory Exchange Server attributes from the source forest user to the target user.
Ok, let’s now see how to do this. First, you have to do some preparations in OrgA in OrgB. In a nutshell, you have to do following:
· Make sure that connection between OrgA and OrgB is reliable. Also, make sure that name resolution between domains in OrgA and OrgB is working
· Establish forest trust between OrgA and OrgB. While this is not mandatory, it will definitely make your life easier during this procedure. You can remove the trust later.
· Deploy mutually trusted certificates on Exchange server in both organizations. You can achieve this in various ways, I will not elaborate on this – just make sure that each Exchange trusts certificate on another one
After you did all these preparation steps, you should make sure that Mailbox Replication Proxy (MRSProxy) service on the Client Access server in the source Exchange Server organization is running. By default, this service is disabled, and you’ll probably have to make it start. Easiest way to do this is to execute following in EMS:
Set-WebServicesVirtualDirectory -Identity "EWS (Default Web Site)" -MRSProxyEnabled $true
Before executing this command it is wise to check identity of your Web services virtual directory. Default value is like in command I just wrote, but it can be different. So, run Get-WebServicesVirtualDirectory | FL and check for the identity attribute.
With Set-WebServicesVirtualDirectory cmdlet you can also use MaxMRSConnections parameter. The value of this parameter establishes how many mailbox moves you can do simultaneously. The default value is 100. You should reduce this number if the mailbox move is going across a slow link. If you have reliable and fast connection, you can forget about this. But, if you change the value, you should restart Mailbox Replication Service for the change to take effect.
Before you proceed, there is one thing that you should check to spare some headaches later. When you enable the Mailbox Replication Proxy service on the source Client Access servers, the mailbox move endpoint becomes MrsProxy.svc. In some cases, the IIS configuration is missing the svc-Integrated handler mapping, which results in an error, such as “(405) method not allowed,” when you start moving mailboxes, and that’s not something you want to see. To make sure that this will work, open command line at this path: C:\Windows\Microsoft.Net\Framework\v3.0\Windows Communication Foundation\ , and then execute the following command: ServiceModelReg.exe –r. This command reinstalls the handler mappings in IIS. To check for existing handler mappings in IIS, start the IIS console and then, in the center pane, double-click Handler Mappings, while the virtual directory or website is selected. Just make sure that you see *.svc there.
Now that we have things prepared, we will start moving some mailboxes in next part of this article. Stay there.
Hello, i enjoyed your article.
have your written the next steps yet?
also is the MRSProxy needed? & is it needed in the source & not the target? i have read that it should be enabled in the target.
thank you
please dis-regard the comment about about part 2, i did not notice the link at the top.
Hi!
Is it possible running exc 2007 and exc 2013? We have a legacy of 2007 HMC and we have to migrate for a new forest in 2013.
Regards,
Daniel
Hi, We are trying to migrate mailboxes from two different forests into a new forest with Exchange 2013. We have Exchange 2010 in one and 2007 in the other forest. We do not want to move the AD user objects but just the mailboxes. Meaning that we want to keep the users on their existing forests/domains and only move their mailboxes to the new forest with Exchange 2013. We have trusts between all 3 forests. Any help is appreciated!
Were you able to accomplish this, I am looking to move only mailbox to new users in a new domain from 2010 to 2013?
Hi,
My lab worked very well. Now in production I ‘ve been facing some issue when I try to create the migration endpoint. Both environments have a 3 party cert and the name can be resolved. But I always get a message saying that
“We couldn’t detect your server settings. Please enter them. AutoDiscover failed with a configuration error: The migration service failed to detect the migration endpoint using the Autodiscover service. Please enter the migration endpoint settings or go back to the first step and retry using the Autodiscover service. Consider using the Exchange Remote Connectivity Analyzer (https://testexchangeconnectivity.com) to diagnose the connectivity issues.
Remote MRS proxy server:
I treid addind the FQDN but no success.
Could you help me?
Hi Daniel
Did you find a solution to your question? I am in the same situation..
Br. Teddy
Hi Teddy!
Actually yes. If your issue is btw exc 2013 and 2010 the endpoint migration will work only if one of the exc 2010 name servers are in the certificate. Ex: exc01.mydomain.com With this name you can create the endpoint when a fqdn from it was requested. For my lucky my valid cert had one of them.
Now if you trying to migrate from exc2007 you don’t need it. Just use this command bellow after run the prepareMoveRequest.ps1:
New-Moverequest -Identity user@domain.com.br -RemoteGlobalCatalog dc01.ms.domain.local -RemoteCredential $Remote -RemoteLegacy -TargetDeliveryDomain domain.com.br
Of course you need trust in both ones.
It should help you. Let me know!
Regards,
I ran into this too. The certificate on my test machines had a wildcard for the externally facing name. If I used the CAS server name or the internal load balanced name, I would get the same error stated. When I switched to the external name (I changed the DNS record fo the “external” name to point to the internal IP of one of my CAS servers) I was able to connect to the endpoint.
Hi thanks for your answer. I am not able to test now – sorry – my customer decided to take the on-premise exchange down and uninstall! Instead convert the slow ADSL to Fiber to get enough bandwidth to drive the 365 without a on-premise exchange.
Br. Teddy
Thank you so much for sharing the excellent step by step guide. Migration from one forest to another is really very complicated and tedious job. There are many problems which are faced by the Exchange administrator when performing the migration job. Security, data loss, server downtime are major challenges which are encountered while moving from one organization to another in Exchange environment.
To overcome such problems, there are some third party tools available in the market which could be helpful. Here is one such application that helped us in migration from Exchange 2010 to Exchange 2013 production server:
Some key-features of the tool are here:
– Offer options to migrate data to Production Exchange Server and Office 365
– Fixes database related issues during migration so that users could not get any issue on new server
– Offer options to migrated all or selected items in databases
– Free trial version is also available to check its working functionality and efficiency
So, if anybody who wants quick migration in a rich graphical environment instead of command line, take a look at it.
Good Luck!
Jenny
Hi,
I have question?
Can i move only the mailbox from one forest to a different exchange in the other forest? Like User A in (Domain A) need to be moved to exchange org in Domain B?
User A has his computer added to Domain A but mailbox to be in exchange org of Domain B?
Is this possible?
MTA
Regards
Natesh
I am looking to move my mailboxes from 2010 to 2013. I’m being brought in late to this migration and am looking to see what my options might be.
If I someone has already stood up User accounts (not disabled user not mail enabled) and contacts for the source mailboxes (for mail flow,) will I have to delete the contacts (exporting out the legacyexchangeDNs to apply to the target mailboxes) in order to run this prepare script? I am betting that I would need to remove the target orgs contacts since the SMTP addresses will conflict with the source mailboxes primary address.
Will the prepare script negatively modify the target user accounts or is it better to use ADMT? Will ADMT change the user accounts so that they can’t be used? (the new target forest AD accounts are in use now.) Does the new version of ADMT play nicer with Exchange migrations?
Any help would be appreciated.
Nice article. question.
Is there a way to link/MEU an exisiting User Object in the target domain if
1) the samaccountname is different from the source
2) the givenName and/or sn is different from the source domain
3) the displayName is different from the source domain
I see that if an existing contact exists prepare-moverequest will delete the contact and merge the addresses in the MEU. However, when I run the PS1 and one or more of the issues above are in place, the script creates a new user object instead of linking what is existing. I was able to get it to work my first time with a test account in the lab. Subsequent test in the same lab only create new accounts.
Mailbox migration can be easily done from (one domain to another) Exchange 2010 to 2013 using manual solution (https://blogs.technet.microsoft.com/meamcs/2011/06/10/exchange-2010-cross-forest-migration-step-by-step-guide-part-i/), as well as if you prefer automated software (http://www.stellarservertools.com/exchange-edb-pst-converter.php)…it all up to you & your organization need!