Skip navigation
How Exchange's Recover Deleted Items option could be improved

How Exchange's Recover Deleted Items option could be improved

Since the introduction of the first "dumpster" in Exchange 2000, users have been able to recover deleted items without asking an administrator to recover the data from a backup. Given the propensity of humans to make mistakes (like deleting an important message in error), the feature has proved to be invaluable over the last 15 years.

Microsoft doesn't like you to call it the dumpster any more. Somewhere along the line this became a politically incorrect term, or whatever that might be in the eyes of the marketing people, who decided that the feature would be so much nicer if it were called Recoverable Items, or dumpster 2.0. I see what they mean. Rummaging through the dumpster for a forgotten item evokes thoughts of sorting smelly rubbish in waste cans, and we wouldn't want anything in Exchange associated with a pungent and distasteful activity.

Of course, Recoverable Items became so much better in Exchange 2010 when Microsoft changed the implementation from a flag set on an item when it was deleted (ptagDeletedOnFlag) to a set of hidden folders used to store deleted items and for other purposes such as retention of data for in-place holds. Items remain in Recoverable Items for the deleted items retention period and can be recovered by the user during this time.

There's much to like about the Recoverable Items structure. It ensures that items are available for user recovery, preserves items for as long as the administrator requires, and keeps items required for in-place holds – even when users attempt to dispose of embarrassing item. In short, Recoverable Items works well.

Except, that is, for one small niggling horrible little detail. If an item first moves into the Deleted Items folder, you cannot recover a deleted item to its original folder. It would be nice if Exchange retained details of the folder context when items were deleted, but it doesn't. So clients are left to figure out how they should implement the Recover Deleted Items option. Testing against Outlook 2013 SP1/Outlook 2016, and Outlook Web App demonstrates that the two clients take different approaches to how to recover deleted items. 

Outlook allows users to choose the Recover Deleted Items option for any folder. For example:

  • Select an item in the Inbox
  • Use Shift/Delete to hard-delete the item. Exchange moves the item into the Recoverable Item\Deletions folder
  • Select the Junk Email folder, right click, and select Recover Deleted Items to see a list of items stored in Recoverable Items\Deletions
  • Search for the item deleted from the Inbox and click Restore Selected Items. The item is recovered into the Junk Email folder.

The approach is logical and is based on the idea that the user knows where they want the recovered item to go.

The interface used by OWA differs from Outlook in a number of significant ways. First, the Recover Deleted Items option is only available in OWA when the Deleted Items folder is selected. Second, Outlook allows you to sort items by any of the available columns shown in the Recover Deleted Items dialog (click on the column heading to sort) whereas OWA sorts by received date and doesn't support additional sort options. However, on the upside, OWA provides a very useful search option that can be used to locate items in what can be a very large list. 

The last difference is how items are recovered. Because OWA doesn't support the Recover Deleted Items option for all folders, it makes an intelligent guess based on the item type as to where a recovered item should go. When an item is recovered, OWA flags its intentions by telling the user that mail items go to the Inbox, Calendar items to Calendar, Contact items to Contacts, and Task items to Tasks. The idea here is that items should be recovered to a folder where they can be used. For instance, recovering a calendar item into the Inbox makes no sense because that item is "foreign" to the Inbox and has to be in a calendar folder before a client can display and process it correctly.

This is all very logical, except for the little fact that you might not want every mail item (or to be more precise, any non-calendar, task, or contact item) to be recovered to the Inbox. For example, if you delete a conversation record captured from a Lync call and later recover it, the item ends up in the Inbox where it would be better recovered into the Conversations folder.

It's true that it is easy to move a recovered item from the Inbox to wherever it is best stored and that the most important thing is to be able to recover a deleted item before it is removed from the server. The implementations in Outlook and OWA both meet this criterion.

But it would be nice if Exchange tracked the last folder that an item was stored in before deletion (ignoring the Deleted Items folder) to give clients a more precise guide as to where the item should be recovered should the need arise. A MAPI property seems like the right place to store this information.

Having a common approach to item recovery would be nice. Having the ability to recover direct to an item's original location would seem to be even better. We can but hope.

Follow Tony @12Knocksinna

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.