The Exchange 2016 migration project for Not Real University has reached the stage where they can begin their mailbox migration.
When planning a mailbox migration it's useful to review how much data each mailbox actually stores. This is important to know so that you can plan your migration batch sizes in way that won't overwhelm the destination server with too much transaction log generation from all of the database changes that will be occurring during the moves. You can use the Get-MailboxReport.ps1 script to generate mailbox size reports for your environment.
You can move mailboxes using either:
- Individual move requests
- Multiple move requests tagged with the same batch name
- A migration batch of one or more mailboxes (which is not the same as tagging a bunch of move requests with a batch name)
If you perform the migrations using the Exchange Admin Center, you'll be creating migration batches. If you choose to use the Exchange Management Shell instead, you can use any approach you like. The process for moving mailboxes has not changed between Exchange 2013 and 2016, so you can refer to this tutorial on moving Exchange Server mailboxes for more details.
Note that after completing a migration batch there are some factors that might cause a delay before the users can access their mailbox:
- Active Directory replication delays
- Autodiscover caching
Any Active Directory delays will need to be accounted for in your migration timing, and should be revealed during the first few migration batches you run. For the Autodiscover caching, you can recycle the Autodiscover app pool in IIS on all Exchange servers, or lower the automatic recycle interval during your migrations. In both cases, if you're completing migration batches overnight when there are several hours before users will be logging back on, then it's unlikely you'll run into either problem.
When the mailboxes have been migrated to Exchange 2016, the public folder migration can be performed.
Paul is a Microsoft MVP for Office Apps and Services and a Pluralsight author. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server.
As I’m currently migrating users from Ex2010 to Ex2016, I noticed that their Outlook will be disconnected. I need to restart the Autodiscover Application Pool on the Exchange Servers.
What should be recommended settings to set the AppPool recycling interval in IIS?
Thanks.
There’s a delay due to Autodiscover caching but the server will recycle that on its own (I think it’s every 30 minutes by default). So if you plan your migrations to complete overnight…
https://practical365.com/exchange-server/using-completeafter-manage-automatic-completion-mailbox-move-requests/
…by the time the users launch Outlook again it should be fine. Otherwise just plan to manually cycle the Autodiscover app pool immediately after completing your moves.
Hi Paul, Great blog. I have a question regarding migrating from Exchange 2010 – Exchange 2016. Is there any SIS in Exchange 2016? a consultant told me there was so we could expect to see the mailbox databases decreasing in size. He advised us to build the databases on ReFS volumes which we have done. If no SIS is there any form of DeDup that is available to Exchange 2016?
SIS hasn’t existed in Exchange since Exchange 2007.
Microsoft recommends ReFS in their Preferred Architecture for Exchange. You need to configure it per their recommendations, as well as ensure your backup software supports it.
Dedupe is not supported at all.
Link for further reading:
https://technet.microsoft.com/en-us/library/ee832792(v=exchg.160).aspx
Hi Paul,
We are almost finalising our migration from Exchange 2010 to 2016, I just to clarify what we supposed to with distribution groups before decomissioning Exchange 2010.
Nothing special required.
Thanks Paul, so you are saying that nothing is required to do with distribution groups ?
That’s what I’m saying.
Thanks Paul, You are great
I followed your every article for Migrating to Exchange and they are awesome. Thanks a million once again.