Office 365: Large item migration limits did not apply…


Administrators of Office 365 may have been pleasantly surprised to hear that the large item migration limit for hybrid mailbox moves has increased.  Administrators may now migrate messages up to 150 meg.  Originally when performing a migration any item that was found in the mailbox over 35 meg was either left behind or it was the responsibility of the administrator to preserve and handle this data.  This increase should allow administrations to more easily migrate to Office 365.

 

Over the last two days I have talked with some customers who observed what appeared to be the limits not applying.  Excited about this new feature these administrators were testing it prior to performing their end user migrations.  For example, when performing a migration of a mailbox with known large items the following was observed in the migration log:

 

1/19/2015 2:07:44 PM [BY2PR02MB315] A large item was encountered: Item (IPM.Note) Subject:"77 mb", Size: 77.51 MB (81,278,846 bytes), Folder:"Inbox"

 

Why did the new limits not apply?  Let’s take a look…

 

When a mailbox exists on premises it is represented in Exchange Online as a mail user object.  A mail user object where the mailbox has never been migrated to Exchange Online does not have a mailbox plan applied.  This can be validated with get-mailUser.

 

PS C:\> Get-MailUser | fl maxSendSize,maxReceiveSize

MaxSendSize    : Unlimited
MaxReceiveSize : Unlimited

 

When the mailbox is migrated to Exchange online the mail user object is converted to mailbox object.  When this occurs a mailbox plan is applied to the mailbox.  This can be validated with get-mailbox.

 

PS C:\> Get-Mailbox | fl maxSendSize,maxReceiveSize

MaxSendSize    : 35 MB (36,700,160 bytes)
MaxReceiveSize : 36 MB (37,748,736 bytes)

 

What happens if the mailbox is migrated back to on premises?  When this occurs the mailbox object in Exchange Online is converted back to a mail user object.  In this instance though the mail user object retains the original mailbox policy applied.

 

PS C:\> Get-MailUser| fl maxSendSize,maxReceiveSize

MaxSendSize    : 35 MB (36,700,160 bytes)
MaxReceiveSize : 36 MB (37,748,736 bytes)

 

How does this affect migrations?  When a mailbox policy has already been applied to an object those settings are enforced for the migration.  If the mailbox that was migrated back to on premises was subsequently used, and large items generated in the mailbox, when the mailbox was migrated back to Exchange Online any large items would be discarded due to the applied mailbox plan limit of 35 meg.  In each of these cases the administrators were testing with mailboxes that has previously been migrated to Exchange Online and then back on premises.

 

To allow large item limits to migrate changes, were taken to apply the mailbox policy after the mailbox was migrated and control the item size limit as a part of the move mailbox procedure.  For example, this is a mailbox that contained large items > 35 meg and was migrated after the service changes were applied.  The items migrated successfully.  Even after migration the original mailbox policy of 35 meg was applied. 

 

PS C:\> Get-Mailbox | fl maxSendSize,maxReceiveSize

MaxSendSize    : 35 MB (36,700,160 bytes)
MaxReceiveSize : 36 MB (37,748,736 bytes)

 

This is correct as that is the existing mailbox policy of Exchange Online.

 

If you are migrating mailboxes and observe large items being left behind you may want to check the mail user object within Exchange Online to see if a mailbox policy has been applied.  Chances are that one has and the object we are dealing with was migrated previously.  If this is the case the mailbox must be treated like before – the large items must either be skipped or retained manually prior to the migration being performed.  You can ensure that no loss occurs by continuing to specify a large item limit of 0 on the migration batches, which will cause the individual move to fail if a large item is encountered.


Comments (2)

  1. turbomcp says:

    interesting as always

  2. Satya says:

    Thanks for update

Skip to main content