“Recoverable Items” Very Large

Have you come across a mailbox during a move or during mailbox issue whereby the mailbox size is very large? Then when you check the mailbox folders size and find that the “Recoverable Items” are enormous. This issue had arise in Exchange 2010 SP2 RU2.  Usually in the later versions, you would run Search-Mailbox –Identity <UPN> – SearchDumpsterOnly –DeleteContent.

It would remove the items in the Deletions folder, Purge folder and Recoverable Folder. However, if the mailbox was provisioned on Exchange 2010 SP2 RU3 of before, you may noticed, those items would not get removed. The question is why? This is caused by Calendar Version Logging feature. How does this cause the large growth? There is a few points on how this can cause the increase in items:

1. This is a copy-on-write process taking place in the mailbox.
2. Everytime you create an appointment, adding items to an appointment, Outlook is auto-saving. This creates multiple copy-on-write process happening in the background.

There is more in-depth information on the how the coding worked for that RU but in a nutshell, With Exchange 2010 SP2 RU3 and later, copy-on-write now understands the difference between Flush and Save operations and will only be triggered when a Save operation occurs. In order to resolve this, we have to use a flag called “CalendarVersionStoredDisabled”.

This is “Calendar Version Logging“. This is a process which calendar changes occurs within a mailbox are saved via copy-on-write. Calendar items are now stripped into individual items and saved. For a more in-depth look, here is an article on “Calendar Version Logging”

 As an Exchange administrator, ensuring that the database are healthy and moving mailboxes between stores, we have a mailbox move which had failed. This is what it looked like:

Yip, you are not seeing incorrectly. This mailbox size is 285GB. How can that be possible? Usually when an OST passes 3GB, it can become unstable, yet here we have a mailbox with size. So I then logged onto the mailbox to see which folder had so much of data and could not find it. The mailbox only showed it is at 39GB of 50GB. So where is Exchange getting that amount. I then ran the following command to check the mailbox size on the Database:

Get-MailboxStatistics <Email Address> | fl

I then confirmed that, that Exchange is seeing the large mailbox but which folder had the files if OWA was not showing it. Then ran the following command to check the users folders:

Get-MailboxFolderStatistics <Email Address> | Select folderPath,Foldersize

There I found a large folder. I then attempted running this command to remove those items:

Search-Mailbox <Email Address> –SearchDumpsterOnly –DeleteContent

Never worked, items still showing. I then ran a test on my mailbox and same results, nothing changed. I then ran it against another mailboxes created on Exchange 2010 SP3 RU24/CU24 and it worked. So what was different? Looking at the history, my mailbox and the failed was created on or before Exchange SP2 RU2. Even though we are on the latest update version but bugs are carrying over. After some immense research understanding the components on how is a mailbox is provisioned and characteristics an RU or CU plays. We then proceed to test on my mailbox before administering onto the users mailbox. After testing the solution, we confirmed it is working. We then proceeded to run the fix on the users mailbox. The fix is quite simple. Run the following flags on the users mailbox:

Get-Mailbox –Identity <Email Address> | Set-Mailbox –CalendarVersionStoreDisabled:$True

By default, this option is set to False.

Then to check it is worked, run this command:

Get-Mailbox –Identity <Email Address> | Select Cal*

 Allow a day or two for the process to start the clean-up. In order to monitor the folder size,  run this command:

Get-MailboxFolderStatistics <Email Address> | Select FolderPath,FolderSize,FolderandSubFoldersize(Optional)

After some hours…..

After some more hours…..

Sometime later, finally

It was done. And there you go. Oh, yes, for the mailbox move, I had to remove the mailbox from the “MoveRequest” as it still had the old information cached. To remove a mailbox from the “MoveRequest”, run this Get-MoveRequest | Remove-MoveRequest

And then start a new one and if you can specify another DAG or Store

New-MoveRequest -Identity “Email Address” -TargetDatabase “DB01”

It will take time, perhaps you may need to Accept some data loss if there is corruption but the move should complete successfully.