In-place archiving not working as expected

Copper Contributor



I was wondering if someone could shed some light on this, because we feel we are at an impasse here. A quick summary of the case:


We migrated a customer from on-prem Exchange to Exchange Online earlier this year. No hybrid, just a clean cutover. Some of these users have very large mailboxes, 150-200+ GB in size. So all of them have Exchange Online Plan 2 licenses, with auto-expandable in-place archiving enabled in Exchange Online. Retention policy is set to one year, where everything older than that should be moved to the in-place archive mailbox.


The problem:

Now we are starting to get full mailboxes and full in-place archive mailboxes. The users get warnings all the time, and we get the complaints. When checking the affected mailboxes, it looks like there is a lot of stuff moved to the archive, but also a lot not moved, and by that i mean hundreds of thousands of items. The timestamp on things not moved is random, although everything is older than one year as set in the retention policy.


There is no indication that stuff is moved anymore either, except when we do it manually. The we can clearly see the mailbox shrinking and the in-place archive mailbox expanding in size. This is however extremely time consuming, giving the limitations Outlook or Outlook Web App has.


So what gives? As we have understood, in-place archiving with auto-expansion enabled, should be able to provide up to 1,5TB more, or are we wrong? When talking to our license partner, which we are required to use for support, they claim that what we are doing is unsupported. That we cannot start in-place archiving with mailboxes of that size. The mailbox has to be 10 MB or less from the start to support this.


I cannot remember seeing this information anywhere in the maze of Technet, and to me it does not make sense. Are admins supposed to predict that the customer _could_ reach such astronomical sizes of their mailboxes from the very start? We are talking about users who have been with us since the ages of Exchange 2007.

6 Replies
Your partner got it wrong, it's the other way around - the mailbox needs to be min 10MB in size in order to be eligible for processing by the MRM (and thus subject to retention policies).

In any case, your issue likely stems from the limitations of expanding archives and the lack of options we have therein, as in we cannot "force" a new chunk to be provisioned, and it can take up to 30 days. I'd recommend working with Microsoft support on this.
Just in case, check the last time the mailbox was processed by the MRM:

$logs = Export-MailboxDiagnosticLogs mailboxname -ExtendedProperties
$xml = [xml]$logs.MailboxLog
$xml.Properties.MailboxTable.Property | ? { $_.Name -like "Elc*" }

and also for any obvious errors in MRM processing:

Export-MailboxDiagnosticLogs mailboxname -ComponentName MRM

@Vasil Michev 

Thanks for the reply. Yeah, you are probably right. I guess we have to bypass our partner on this and talk to Microsoft directly.

I get this when running your cmdlets:





0 items processed... is MRM processing blocked on the mailbox? Check these:

Get-Mailbox blabla | select ElcProcessingDisabled,*RetentionHold*

@Vasil Michev 


Both ElcProcessingDisabled and RetentionHoldEnabled are set to false on the mailbox, ElcProcessingDisabled is set to false in the organization config.

So it should be processing, yes we see zero results. Double-check the set of tags assigned to the mailbox, also make sure the RecoverableItemsSubtree quota is not reached. Some additional guidance can be found here:

Correct tag is set on the entire mailbox when checking EAC, but when doing step 3 in your linked guide, there seems to be set a personal tag *somwhere*. It is just a bit unclear to me how i go about finding out what folder this is when looking at the XML-export from 'PR_ROAMING_XMLSTREAM'.

I checked another mailbox from the same customer, and this mailbox also had the correct tag when checking EAC , but also multiple and different tags when looking at the XML-export from 'PR_ROAMING_XMLSTREAM'.