# Using “Restore-RecoverableItems”, or “how I saved my own bacon”

•
•
•
•
•
•

Since the dawn of time (or at least, since the dawn of the Epoch), people have been inadvertently deleting stuff.  As is attributed to Uncle Ben, “with great power comes great responsibility,” and so it is true with the system administrator.  The ability to delete an email is insignificant next to the power of the Forc–ok. I’ll stop now.

If you want to learn about the Recoverable Items folder, this page is not for you.  This page, however, is.  I’m assuming you’ve arrived here because you have some bacon to save–yours, a friend’s, a customer’s…who knows.  There’s lots of bacon in the world, and it is frequently in need of saving.

For the Cliff notes version, deleted items go through a few stages, depending on how they’re deleted.  From Technet:

• Deletions   This subfolder contains all items deleted from the Deleted Items folder. (In Outlook, a user can soft delete an item by pressing Shift+Delete.) This subfolder is exposed to users through the Recover Deleted Items feature in Outlook and Outlook on the web.
• Versions   If In-Place Hold or Litigation Hold is enabled, this subfolder contains the original and modified copies of the deleted items. This folder isn’t visible to end users.
• Purges   If either Litigation Hold or single item recovery is enabled, this subfolder contains all items that are hard deleted. This folder isn’t visible to end users.
• Audits   If mailbox audit logging is enabled for a mailbox, this subfolder contains the audit log entries. To learn more about mailbox audit logging, see Mailbox audit logging in Exchange 2016.
• DiscoveryHolds   If In-Place Hold is enabled, this subfolder contains all items that meet the hold query parameters and are hard deleted.
• Calendar Logging   This subfolder contains calendar changes that occur within a mailbox. This folder isn’t available to users.

Basically, what the graphic maintains is that Deleted Items sit in a purgatory waiting for their final disposition.  During this time, the messages may be recoverable using various means:

• Recover Deleted Items via Outlook or Outlook Web App
• Discovery Search
• Search-Mailbox cmdlet
• Exchange Web Services
• Restore-RecoverableItems cmdlet

The last one is what interests us, and has some of the best flexibility for those “oh, crap” moments.  You know, like when someone (usually by the name “I don’t know”) applies a delete MRM tag to all folders instead of just one.  Stop looking at me, Linda.

To see how the recovery process looks, take a look at my examples. Here, I have created a few folders (intuitively named, of course), that I’ll use to demonstrate what happens from the perspective of the mailbox and the cmdlets.  In the first, am going to delete an item (just by pressing Delete on the keyboard or right-click | Delete on the message), which will send it to Deleted Items.

In the second example, I’m going to bypass Deleted Items and go right to Recoverable Items.

So, fire up some PowerShell and connect to Office 365.  We’re going to restore some stuff!  We’re going to mainly going to focus on using two commands: Get-RecoverableItems and Restore-RecoverableItems, which will allow you to see what items are available for recovery and … yes, you guessed it, apply for financing for a llama.

Get-RecoverableItems requires the -Identity parameter, which can be any of the things you normally use to uniquely identify a mailbox (alias, DN, SMTP address, etc).  You cannot pipe data into this cmdlet directly (as in, Get-Mailbox | Get-RecoverableItems), nor can you specify a wildcard (Get-RecoverableItems a*).  In this case, I’m going to use my admin ID in my test tenant:

I want to draw attention to the two highlighted lines: LastParentFolderID and LastParentPath.  LastParentFolderID is a relatively new feature add (one that’s been requested for quite some time).  Previously, when items were deleted, they lost their parent path identity, meaning we could only ever restore them all to the same place (such as Deleted Items or the Inbox).  With the advent of these properties, we can now put things back and provide a better experience for our customers.

The *-RecoverableItems cmdlets allow us to filter on both the SourceFolder and LastParentFolderID (as well as dates), so if you need to sift through a bunch of deleted items, you can do that more easily.  For example, to see all of the deleted items for the ShiftDeleteFrom folder (with the LastParentFolderId of F521B8ECADFF6E48A85AFBD5B5FEAFFF0000910EA6A7), I can simply run:

Get-RecoverableItems -Identity admin@ems340903.onmicrosoft.com -LastParentFolderID F521B8ECADFF6E48A85AFBD5B5FEAFFF0000910EA6A7

Good to see–exactly what we were expecting.

You can then use Restore-RecoverableItems the same way.

Now, this is the part where you’re probably asking, “how do I do this for, say, 10,000 mailboxes, due to a runaway MRM tag?”

Fortunately, where there’s a script, there’s a way:

Get-Mailbox -ResultSize Unlimited | % { Restore-RecoverableItems -Identity %_.Identity | Export-Csv RestoreLogfile.csv -Append -NoTypeInformation }

The result?  Glorious data, back home in its original spot–just as the good Lord had intended (and a log file to prove it).