Cleaning up a full recoverable items folder

  • Article

I recently worked with an organization where one of their users had a full Recoverable Items folder. This user had a hold on their mailbox, but also had the Exchange Online Unlimited Archive, so why had the Recoverable Items folder filled up and why were these items not being moved to the online archive? Let’s dig in.

Problem

A user started having problems when trying to accept meeting invites that had been sent to them. They raised the problem with their IT staff who quickly discovered that the users’ Recoverable Items folder was full. This user had previously been put on hold, which gave them a quota of 100 GB for their recoverable items folder (default is 30GB), and this space was maxed. In our investigation, we found that the Versions folder in the Recoverable Items folder was taking all the space in the Recoverable Items folder. This explains why the user was having problems accepting meeting invites, because meeting versions are moved to the Versions folder in the Recoverable Items folder, which was completely full.

Troubleshooting

As any good IT folk would do first, I wanted to verify the problem with my own eyes, so I had the organization run the following PowerShell.

 Get-mailboxfolderstatistics -Identity <User Identity> -IncludeAnalysis

This cmdlet will return statistics for all folders in the mailbox, including the folders under the Recoverable Items folder. In looking at the results for the Versions Folder we found the following.

 Name                       : Versions
FolderPath                 : /Versions
FolderType                 : RecoverableItemsVersions
ItemsInFolderAndSubfolders : 252
FolderAndSubfolderSize     : 100.6 GB (108,063,890,884 bytes)
TopSubject                 : <Meeting Subject redacted>
TopSubjectSize             : 100.6 GB (108,063,890,884 bytes)
TopSubjectCount            : 252
TopSubjectClass            : IPM.Appointment
TopSubjectPath             : \Top of Information Store\Calendar

We see that there are 252 items in this folder. We also see that the TopSubjectCount is 252, and TopSubjectClass is IPM.Appointment. This indicates that a single item, with 252 multiple versions, is responsible for all the space being used in this folder.

In the past, I have seen the odd case where a corrupt calendar meeting will continually replicate in the versions folder, and this is my current suspicion here. There are 252 versions of a single meeting that are taking 100.6 GB of space. If we do some simple math and assume that each version is the same size, we find out that each version of this meeting is approximately 409 MB in size.

Remember that this user also has an Exchange Online Unlimited Archive. So even if we have a corrupt meeting that keeps replicating, why is it not being moved to the online archive?

From the above information, because the only item we saw here was this single meeting, I was inclined to believe that other items in the Recoverable Items Folder were properly being moved to the user's Online Archive. It was only the large versions of this corrupt meeting that were not. My guess is that the size of these items, each being 409 MB in size, was the reason they were not moving to the Online Archive. Either the size stopped the Managed Folder Assistant (MFA) from moving the items, or the MFA was timing out because the items were so large. I won’t go into details about the MFA in this blog, but all you need to know is that this is the process that purges expired items in a mailbox and/or moves items to the archive, both behaviours are based on retention policies.

To verify that the Managed Folder Assistant was properly running against this mailbox we ran the following.

 $ElcProperties = Export-MailboxDiagnosticLogs <user identity> -ExtendedProperties
$XMLProperties = [xml]($ElcProperties.MailboxLog)
$XMLProperties.Properties.MailboxTable.Property | where {$_.Name -like "ELCLastSuccessTimestamp"}

We found that the ELCLastSuccessTimestamp showed a last run time within the last 24 hours. This tells us that MFA is running against the mailbox. Next, I wanted to verify the retention policy was configured  correctly. In particular, we looked for a retention policy tag that had a type of RecoverableItems folder. We found there was one in place.

 Name: Recoverable Items 14 days move to archive
Type: RecoverableItems
MessageCLassDisplayName: All Mailbox Content
RetentionAction: MoveToArchive
AgeLimitForRetention: 14.00

The above tag is part of the applied policy. This tells me that the items in the Recoverable Items folder should have moved as long as they were at least 14 days old. We used MFCMAPI (details later on in this post) to view the items in the Versions folder, and sure enough, they were all much older than 14 days. Some were almost a year old.

A wrench here is that this mailbox was on hold. If the mailbox was not on Hold, we would have been able to ask the user to delete and re-create the corrupt meeting, and then disable Single Item Recover and use MFCMAPI to manually delete the items in the Versions folder. Because the mailbox is on Hold, we have a couple of other steps to perform for this cleanup.

Solution

With this mailbox being on Hold, we want to be careful with our actions so that we minimize the chance that mail gets purged and lost when we perform the cleanup. If you want to be the most careful, remove access to the mailbox from the user before performing the following steps.

  1. Have the user delete all occurrences of the meeting invite from their calendar. We know the subject of the meeting from the above Get-MailboxFolderStatistics pull. Once deleted they can re-create it.
  2. Grant yourself access to the mailbox. This usually takes around 60 minutes for the permissions to replicate. Remove the user's access to the mailbox if you want to be extra careful.
  3. Disable MFA from running on the user's mailbox by running Set-Mailbox -Identity <UPN of user> -ElcProcessingDisabled $true. We need this to be disabled because when we remove the mailbox hold, we don’t want the MFA going through the Recoverable Items Folder and purging any items in there. As this command will take some time to propagate, wait at least a few hours before moving on.
  4. Disable single item recover on the mailbox by running Set-Mailbox -Identity <UPN of user> -SingleItemRecoveryEnabled $false. If we don’t do this, then deleting items won’t allow the item to actually be completely purged.
  5. Remove the hold on the mailbox.

After the above has been completed, use the following steps to perform the cleanup with MFCMAPI.

Create an Outlook Profile for the user's mailbox on your machine, and then use MFCMAPI to connect to the mailbox.

  • Start MFCMAPI
  • Click Session and then click Logon.
  • Select the new mail profile and then click OK.
  • Right-click the users’ mailbox you have full access to and then click Open Store.
  • Expand the user and then expand Recoverable Items.
  • Double click /Versions to open the folder to view the contents.
  • Select one or more messages, right-click, and then choose the appropriate action you wish to complete.

 

Now that the items are deleted, we need to reverse the changes we made above.

  1. Re-enable the hold.
  2. Re-enable Single Item Recovery (Set-Mailbox -Identity <UPN of user> -SingleItemRecoveryEnabled $true).
  3. Re-enable MFA (Set-Mailbox -Identity <UPN of user> -ElcProcessingDisabled $false).

To verify the cleanup worked, we ran the following.

 Get-mailboxfolderstatistics -Identity <User Identity> -IncludeAnalysis

The results showed us that the versions folder contained 551 KB of data, down from 100.6GB. Mission accomplished. Pat yourself on the back and move on to the next fire.

Cheers!

References

Clean up or delete items from the Recoverable Items folder Increase the Recoverable Items quota or mailboxes on hold Overview of unlimited archiving in Office 365