Share via

Moving Mailboxes Between Exchange Organizations

  • Article

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, so 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 PrepareMoveRequest 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.

 
After you enabled Mailbox Replication Proxy service on the source Exchange Server, it is a good idea to test its functionality. You can easily do it by executing Test-MRSHealth cmdlet. Make sure that you have value True in each Passed row, for each test, and you’re good to go.

 
Before actually moving a mailbox, you should prepare it for moving. Actually, you have to migrate a user object first and prepare mailbox move request. Luckily, Microsoft has provided a script for this. Steps for preparing an object move are as follows:

1.       Open Exchange Management Shell on the destination CAS server and change the path to “C:\Program Files\Microsoft\Exchange Server\v15\scripts”

2.       Type, $Local = Get-Credential and press Enter. When prompted, provide admin credentials for new (destination) organization. That the org to which you move the mailbox.

3.       Type $Remote= Get-Credential and provide credentials for source organization. By executing these steps we are actually storing credentials for administrators in both organizations. These credentials are used by the script.

4.       Type:
**.\Prepare-MoveRequest.Ps1 -Identity “User UPN” -RemoteForestDomainController FQDN_OF_SourceDC -RemoteForestCredential $Remote -LocalForestDomainController FQDN_OF_LocalDC -LocalForestCredential $Local -TargetMailUserOU "OU=OUNAme,dc=domain,dc=extension" **

  • you should fill italic text with your own values (example : .\Prepare-MoveRequest.Ps1 -Identity Damir@dizdarevic.ba -RemoteForestDomainController dc-srv-01.dizdarevic.ba -RemoteForestCredential $Remote -LocalForestDomainController dc-srv-01.dizdarevic.local -LocalForestCredential $Local -TargetMailUserOU "OU=IT,dc=dizdarevic,dc=local" )

5.       After you execute this PS script you should get the reply : 1 mailbox(es) ready to move

Now, if you open Active Directory Users&Computers in destination domain, you should find user object created (and disabled, since we didn’t move password). If the object is there, we are ready to move the mailbox. We will do it in Exchange Admin Center in Exchange Server 2013.

 
So, open EAC and perform following:

Click recipients and then click the migration tab. Click New and choose Move to this forest option. In a wizard, click Add and select the user that you just moved. Actually, here you will see only users that are moved using procedure described earlier. Enter credentials for remote/source forest and confirm the name of migration endpoint – that is FQDN of the server where you enabled MRS Proxy service. After that choose the destination database for the mailbox and confirm the admin credentials. Start the migration batch. After that wait for a few minutes until status of user object becomes Synced. Then click Complete this migration batch and wait until the status of the object becomes Completed. And, you’re done!

After the mailbox is migrated, all you have to do is to set the password on the moved user account and to enable that account. After that, user can login in the new forest, and will have its mailbox content moved.