Skip to content

Exchange TotalDeletedItemSize and how to tame it when it runs rampant

Exchange 2010 does a lot of activity in the background to ensure that you don’t permanently lose things that you didn’t mean to lose. Without going into the actual code of Exchange, suffice it to say that the steps it takes to do this can sometimes cause loops and create copies of inconsequential messages over and over again until you’ve hit the limit (default is 30GB) of your TotalDeletedItemSize. iOS 6.1 has been known to a culprit in causing these loops.

Typically, a user will come to me explaining that Outlook is constantly telling him that he can’t get any more mail because his Inbox is full. When a quick perusal of mailbox size shows that his Inbox isn’t remotely close to full, I go to powershell and run get-mailboxstatistics for that mailbox. That’s when I’ll see this:

Not good.

Usually, in the same output, you’ll see DeletedItemCount at something like 300K or some ridiculous number.

In Exchange 2010, if you have Single-Item Recovery enabled, you’ll have a hidden folder called Recoverable Items. Within that folder are 3 folders: Deletions, Purges, and Versions. Deletions is where things go that are hard deleted in Outlook. It skips the Outlook Deleted Items folder, but it can be recovered in Outlook by going to Recover Deleted Items. Purges is where things go after they get deleted from the Deletions folder (until the default Retention period expires). This is inaccessible in Outlook, but it is accessible in MFCMAPI. Versions is a calendar feature that saves versions of calendar entries when they get changed. This is where a lot of the buggy loops happen (with iOS 6.1, many times), but I’ve seen it the other folders as well.

I just had one case (the one screenshot above) where the TotalDeletedItemSize was 30GB but there was only a couple thousand messages in the Purges folder. Shouldn’t be even close to 30GB. To investigate this further, I ran the following code against the mailbox.

Get-mailboxfolderstatistics | ft name, itemsinfolder,foldersize –autosize

And look what we’ve got here. There are only 2680 items in Purges, but it somehow comes out to ~30GB.

I’ve found the culprit, but now how do I get rid of it?

There are a few cmdlets that come in very handy for any of these situations:

Set-mailbox {name} –CalendarVersionStoreDisabled $true

This takes away the versioning feature that can cause bugs.

Search-mailbox {name} –SearchDumpsterOnly –DeleteContent

This searches the mailbox for items only in the Deletions folder and deletes them (Must have at least SP1 installed).

Start-ManagedFolderAssistant {name}

This overrides the default Retention policy schedule and starts the purging of Purges immediately. In my case, this is the one this fit the bill.

I’ve read that a lot of the bugginess in Single-Item recovery is fixed in RUs to SP2. I’ll be upgrading all the way to SP3 sometime this month, so hopefully this pesky issue can be fixed.

One Comment

  1. David Burridge wrote:

    Very useful solved the issue I am currently experiencing.

    Wednesday, September 25, 2013 at 9:15 am | Permalink

Post a Comment

Your email is never published nor shared. Required fields are marked *
*
*