Two years back, Microsoft introduced a set of cmdlets that aim to relieve some of the administrative burden related to recovering deleted content. While Exchange has some robust capabilities that help reduce the chance of data being inadvertently purged out of the system, it’s not uncommon for end users to get confused on how the process of recovering deleted items work, and in turn make them knock on help desk’s door. And of course there are situations where messages have been “purged” by the user or retention policy, so only admins can attempt the recovery.

The two cmdlets, namely Get-RecoverableItems and Restore-RecoverableItems, allowed admins to query the content of the Deleted Items and Deletions folders and restore any items as necessary. Without having to go to the user desk or involve him in a remote session, which is of course a big win for the support team. Unfortunately, the cmdlets didn’t cover the Purges folder, where items “purged” by users are held for the duration of the Single Item Recovery period or the duration of any hold applicable to said items. In turn, for such items we had to rely on the good old Search-Mailbox cmdlet or perform an eDiscovery/Content search, which made the process a bit more complicated.

Now, either because of the impending doom faced by the Search-Mailbox cmdlet and the EAC eDiscovery tools, or simply as the next step in the release cycle, the two *-RecoverableItems cmdlets have received support for the Purges folder. This brings both good and bad news. The good news being that the single item recovery process is now a lot faster/easier than before, all you need to do is run the Get-RecoverableItems cmdlet against the Purges folder and find the item(s) in question, then use the Restore-RecoverableItems cmdlet to bring them back to life. Here’s an example:

Nice and easy, right? Well, now for the bad news. Since the Purges folder is not only used for items that are being preserved for the duration of the Single item recovery window, but also for items on hold (which you can think of are on “unlimited” single item recovery retention window), the amount of items you might find in the folder can be very high. Luckily, this will mostly affect mailboxes that do not have an Online archive enabled, as once such is configured the Recoverable Items 14 days move to archive retention tag will move such items to the corresponding folder in the Online archive’s RecoverableItems subtree, as the name suggest. As a side note, the *-RecoverableItems cmdlets do not support the archive mailbox.

But, if the mailbox is put on hold and doesn’t happen to have an archive enabled, you might end up with situations like the one shown on the screenshot below, where the Purges folder contains a whooping amount of 200k+ items:

Working with such number of items can pose some challenges, and even though the cmdlets do feature some filtering capabilities, those might prove inadequate in some scenarios. Given the use case the cmdlets are intended for, it makes sense that only messages that were originally located in one of the default or user-created folders are returned and only for the duration of the single item recovery window. For all other messages, either those preserved by a hold or the gazillion system-generated messages that end up in the Purges folder, it might be best to leave the recovery process to the eDiscovery tools.

As another side note, the cmdlets are more than capable of actually handling such number of items it seems, and they will happily return up to 10000 (yes, that’s 10k, not 1000 as suggested by the documentation) items when using the default value for the –ResultSize parameter. The question is how efficiently can we as humans work with such a large set of data, even when exported to CSV and opened in Excel.

In any case, the new capabilities introduced for the Get-RecoverableItems and the Restore-RecoverableItems cmdlets are welcome additions and should prove useful.