With co-existence established and the Client Access namespaces cut over to Exchange Server 2013 we can begin the mailbox migrations.
When you’re planning a mailbox migration it helps to know what you’re dealing with in terms of number of mailboxes, their sizes, and the number of items they contain. To gather this information I recommend using the Get-MailboxReport.ps1 script.
In earlier versions of Exchange such as 2003 and 2007 the mailbox migration process was an interactive task that required the administrator to test how much mailbox data they could move per hour, break up the mailboxes into migration groups, time the moves to occur out of business hours, and communicate to end users that their mailbox would be unavailable for what was often a several hour period.
In addition to this, care had to be taken not to move so much data in one period that the transaction log volumes on the destination Exchange server ran out of disk space.
Exchange Server 2010 improved on this with the introduction of move requests. Exchange Server 2013 improves on this even further with new enhancements.
Exchange Server 2013 will apply self-management of its resources when processing mailbox moves, backing off when required due to server load or to allow log replication to catch up. Move requests can be issued and allowed to run without the administrator needing to micro-manage the process, with only occasional monitoring required and some intervention at the end to complete the moves.
And in a scenario where mailboxes are being migrated from Exchange 2010 to 2013 the moves are processed as online moves, which do not require the user’s mailbox to be offline for the whole move process, only the final completion stage.
For the Exchange Server Pro organization the migration follows this process:
- Run the Get-MailboxReport.ps1 script
- Choose a sample of pilot users, with the rest of the mailboxes assigned to a small number of batches that increase in size from first to last
- Migrate the pilot mailboxes
- Migrate each subsequent batch
You can learn more about the migration process here:
In each case the administrator running the migration only needs to:
- Create and start each migration batch
- Monitor the progress of the migration batch
- When ready, notify end users of a brief outage for that evening and then complete the migration batch
- Repeat for the next batch
With the mailbox migrations complete the next step is to look at public folder migration.
Hi Paul much appreciate all your efforts on providing good posts.
Hoping you can assist with recommendations on increasing the amount of moves ?
Current have 2 x 2010 CAS (Virtuals) migrating 2200 mailboxes to 2 x Exchange 2013 servers that hold both mbx and cas roles.
The Exchange 2013 servers have 64GB RAM and 10 processors, but the 2010 servers only have 2 processors and 8GB RAM. Would it be unwise to increase the max moves ? Are you able to give some advice on what to set the MSExchangeMailboxReplication config file to on the 2010 CAS servers ?
MaxActiveMovesPerSourceMDB (Currently 5)
MaxActiveMovesPerTargetMDB (Currently 2)
MaxActiveMovesPerSource Server(Currently 50)
MaxActiveMovesPerTargetServer(Currently 5)
MaxTotalMovesperMRS(Currently 100)
Are you able to advise on whether transaction logs will only be generated on the destination database or is the only the database that holds the 2013 Migration Arbitration Mailbox. ?
Your help would be very very much appreciated.
The Real Person!
Author Paul Cunningham acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
Transaction logs generated on the destination server will be approximately the same size as the amount of data you migrate. So if you move 10GB of mailboxes, plan for at least 10GB of logs to be generated on the destination server.
I tend to leave the max moves alone because the biggest influence on migration throughput, in my experience, is the performance of the source and destination servers.
Thanks heaps for the quick reply Paul, I will see how it goes as I need to migrate the 2200 mailboxes in 25 days and the moves will be completed both during the day and during the night.
What i was originally thinking was to increase the max moves from 2 to 5 per target DB but wasn’t sure what impact this would have to users as it will be done during the day. Do you think this would be risky ?
The transaction logs drive has 1.2TB storage so I think this will suffice if the full backup runs every day. I will put on some monitoring just to make sure.
The Real Person!
Author Paul Cunningham acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
I think you’ll find that if you’re throw a lot of moves at the server, they will simply stall when the source or destination server can’t handle the load. The whole point of workload-based processing like that is to prevent impacting users.
I am having the same issues Vishal is having. have you experirenced this issues. how did you resolve the issue?
Hi Paul,
it’s a wonderful site and great instructions for running Exchange 2013 in co-existence with Exchange 2010. I managed to get Exchange 2013 installed and set up correctly and everything is working fine. I’ve got only 1 very minor issue that I need some advise to look into right direction.
When I move the mailbox from Exchange 2010 to Exchange 2013, once the move is completed – if mailbox is opened in Outlook 2007, users get notification – “The exchange administrator has made the changes and requires you to quit and restart the outlook”. When you click ok, it’s trying to configure the profile and open the outlook – but gives another messsage – “Cannot open your default e-mail folder. Microsoft Exchange is not available. Either there are network problems or the Exchange computer is down for maintenance”. When we click Ok on message – it quits the outlook. However, I can go and setup the outlook profile manually for the mailbox which is migrated to Exchange 2013 and it works fine.
What could be the root cause of this problem? and how can I fix it?
Await your response.
Kind regards,
Vishal.
Hi Paul,
I used to follow many times you article to achive correclty Exchange 2007/2010 to 2013 migrations.
Most of the time I’m using the EAC to create the move requests, but something disturb me a little.
I don’t know if I’m right, but it seems to me, that it take longer to migration the same amount of data from an Exchange 2003 to 2010, that it takes today from 2007/2010 to 2013.
I notice that the number of simultaneous thread increases from 2 to 8 with the new version and I believe that this is the reason of the very long time to transfert mailboxes.
Recently I moved a 50 Go database, it took almost 24 hours and the storage was based on SSD Raid5.
Could you tell me if also notice that it take more time with 2013 than before and do you if it possible to decrease the number of simultaneous threads of move ?
Hope I’m clear… and thanks in advance for you advices.
Raphaël
Hi Paul,
I do not see tasks to move the system mailboxes – is this obsolete?
Thanks!
I have migrated all mailboxes from 2010 to 2013 and everything is working fine except for Activesync and owa from external. Internally activesync and owa are working fine. My environment is that I have an internal domain like “mydomain.com” hence my mail server is “mail.mydomain.com”. But i have a website hosted externally also like “www.mydomain.com” where “mydomain” is same in both cases, just thinking it could contribute.
My working internal URL is “https://mail.mydomain.com/owa” and the external NOT working URL is “https://mydomain.com/owa”.
Please help.
Hi Paul, firstly, massive thanks for this hugely informative guide, this has really helped me out no end in performing the steps in getting to a place where i am nearly ready to migrate… though I have one final hurdle, and its been a head scratcher for a few days!
I’ve got all the way through to having the my existing exchange 2010 cas and mailbox servers running alongside the new exchange 2013 cas and mailbox servers.
my problem seems to be somewhere in the transport or dns between the two… its very odd!
If i create a test mailbox on 2010 and open within outlook (using online mode), it still resolves fine to the old 2010 environment, even though i have now modified the DNS records to point at the new 2013 servers.
if i then migrate that mailbox, and open it within outlook, again, no problem, and when viewing the connection status you can see it connected via the new GUID format.
If i then try either creating a brand new mailbox from scratch on 2013, or deleting the existing migrated mailbox profile, and recreating manually to ensure the process, the new 2013 cas server will not resolve, but the old 2010 will.
for example typing in 2013cas.domain.local does not resolve, however if i then type in 2010cas.domain.local, it does resolve it to 2013cas.domain.local! i might also add at this point it doesnt resolve it to the cas server but the new mailbox server, but this i believe to be correct.
i cant for the life of me work out why this is. i’ve gone back through all settings again, checked all permissions, virtual directories, URLs, DNS, its got to be something simple, but i am fresh out of ideas!
There was one other thing which I cant for the life of me remember what cmdlet I ran, but it threw up an error about not finding an object or unable to create an object for the mailbox server in the directory… is there a command i can run to check this also?
Sorry for so much here, i really dont know where to turn as everything else tests perfectly!
Hello Geoff Bryan,
You could solve?
I have the same problem.
Hi Taken,
In the end I was able to use a technical support call to Microsoft through our Schools Agreement, and after some fiddling, they were able to resolve.
It did take a few hours however!
In the end, I identified that when Microsoft Office was installed, that in the OCT (office customisation tool) the server address has been entered, meaning no matter what, each user, regardless of whether there mailbox was migrated, was still trying to point to the old 2003 server.
I modified this to the address of the new server, saved it as an MSP file, and ran this on each of the machines in question, easy for us as we use citrix, so only 8 machines, however this is easily deployable.
Please test and let me know if this resolves your issue.
I Have noticed some of the companies willing to move to O365. but most of the Companies are willing to move to Exchange 2013 on Cloud. Got so many calls from my friends for Exchange 2013 Migration from Legacy versions and they want to go immediately. I think there is no problem for exchange 2013 On-premises.
Can u write articles on O365 as many of the organizations are moving to cloud. There are no projects or companies willing to move for exchange 2013
That’s funny. I’ve done three since 2013 RTMd, am just kicking off another, and am being interviewed for another gig to do a 2013 migration. Lots of companies just finally moving to 2010. Lots of companies finally just moving to Windows 7 desktops, too.
Besides, a lot of these articles apply at least somewhat to Exchange Online as well. You may not have to go through the full sizing rigmarole, but I would argue that moving to the cloud makes it even MORE important to know how much data you’re moving when.
Most of the cmdlets are similar when moving to 365. In fact 365 is Exchange 2013 just in the cloud .