It is a beautiful Friday morning. Sun is shining bright and you are just about to enter your office. You are feeling happy and excited because you finished installing Exchange 2013 two weeks ago on a single physical server; everything is working great. But, you know, you need that second server for high availability so you already made your case to management. After those long conversations where management is complaining about “budget” and you are trying to convince them with “the reasons why you need” it; they finally approved your request. So this morning you received your brand new second physical server.
After few hours, you have your Second Exchange 2013 server and Database Availability Group is up, configured with all the best practices in place. You do not even realize, how time passed so fast. It is already lunch time! Your buddy joins you at one of your favourite restaurants for a great lunch. And all you talk about is Exchange, Exchange, and Exchange: “What a great day already, now I shall get rid of these databases and create new ones in DAG and move every mailbox there”
You head back to office feeling the passion to finish what you started and you concentrate on planning to move all mailboxes. You have limited storage until you get rid of those local databases because you planned a new database storage structure after realizing that you can really use Exchange 2013 AutoReseed feature. You carefully calculate the transaction log space for each database. Cross checking mailboxes that you are going to move and you create nice batch files for the new batch migration framework on Exchange 2013 Exchange Administration Center.
You are ready! You have your batch files in CSV format, you are confident that if you move all the mailboxes in those CSV files at once you will not have any problems because you have enough space for database growth and the transaction log space.
You go to Exchange Administration Center. Quickly finding your way to migration page and you create a new migration batch for the first CSV file. You are feeling good and confident but there is something wrong going on. “Why do transaction logs are getting generated on a database which is neither the source or the target! I am going to run out of space on that volume if I run the rest of the batches!!!” You are thinking of turning circular logging on for that database. “But wait, why is this happening? What did I do wrong! What is the problem/solution?”
Answer is NOTHING! Nothing is wrong and there is NO solution because this is NOT a problem it is by design…
You just missed an important information that you need to know about moving mailboxes in Exchange 2013. If you are using EAC it will use New-MigrationBatch cmdlet and New-MigrationBatch cmdlet uses a system migration mailbox “Migration.8f3e7716-2011-43e4-96b1-aba62d229136” to keep the metadata.
“Assume that you use the Migration wizard in Exchange Administration Center or *-MigrationBatch commands to move mailboxes in Microsoft Exchange Server 2013. In this situation, transaction logs are generated for the mailbox database that hosts the “Migration.8f3e7716-2011-43e4-96b1-aba62d229136″ system mailbox. This issue occurs even though the mailbox database that hosts the Migration mailbox is neither the source or target mailbox database. The transactions logs that are generated may be very large, depending on the size of mailboxes that are moved, and could lead to disk space issues.”
And the cause is
“The behavior is by design. The migration batch framework uses the “Migration.8f3e7716-2011-43e4-96b1-aba62d229136″ arbitration mailbox to store migration metadata (such as batches and migration user information). This behavior generates transaction logs.”
To read the KB Article Click here.
So, while moving mailboxes around databases if you think it will be a problem to generate transaction logs on the database where Migration System Mailbox is (Due to large metadata), than you should consider the following options.
- Turn on Circular Logging for the database where Migration System Mailbox is. (Circular logging is evil don’t do it if you have important mailboxes on that database, lol).
- Go back to your Exchange 2010 days and use New-MoveRequest to move mailboxes.
- Move the transaction log path to a very large volume for the database where Migration System Mailbox is.
Have a nice weekend…