Everyone with some experience with Exchange knows that there’s a lot more to a mailbox than what we see in clients such as Outlook or OWA. The RecoverableItems subtree is one such example, storing items placed on hold, audit items, calendar logs and versioning, etc. Generally speaking, email clients work with just the IPM subtree, while low-level tools such as MFCMAPI or EWSEDitor can be used to explore the Root, or Non-IPM subtree.
In the Exchange Online world, the Non-IMP subtree is quite larger, as over the years different Office 365 applications have been using (and abusing) mailboxes to store and process data. Delve, MyAnalytics, Teams, all have their own folders or folder trees inside the Non-IPM root. Nowadays, you can even spot a whole new subtree parenting such application-specific folders, named ApplicationDataRoot. If you are interested in obtaining more details about such folders via PowerShell, check my previous article on the subject.
What I want to focus on in this article is the fact that items from the Non-IPM subtree are now returned in search results in Outlook. An easy way to check this is to perform a search for items received on a given date, and change the scope to include all items in the current mailbox. Here’s an example of one such search I did recently:
Apart from using the “received” keyword, the only thing I’ve done is to add the “In folder” column, in hopes of understanding what the few hundred such “empty” items were. As you can see from the above screenshot, I have 31 items in a folder called ClipboardItems, 561 items in folder called Activities and so on. None of those folders were created by me, which prompted me to investigate what’s going on.
So, turning to PowerShell, I could easily locate those folders as part of the Non-IPM subtree. It’s actually interesting to compare the current state of my mailbox to the snapshots I took an year ago with the same cmdlets. The good folks at Microsoft has certainly been busy dumping more and more data into the mailbox – the total number of folders has grown to 321, and the size is now a whooping 23.51GB.
$folders = Get-MailboxFolderStatistics vasil -FolderScope NonIpmRoot $folders[0] | select FolderPath,ItemsInFolderAndSubfolders,FolderAndSubfolderSize FolderPath ItemsInFolderAndSubfolders FolderAndSubfolderSize ---------- -------------------------- ---------------------- / 279291 23.51 GB (25,239,132,610 bytes)
And here’s the current breakdown by 10 largest folders:
$folders | Sort -Property @{Expression={[double]((($_.foldersize).split(" "))[2]).trimstart("(")}; Ascending=$false} | select FolderPath,foldersize,ItemsInFolder -First 10
FolderPath FolderSize ItemsInFolder
---------- ---------- -------------
/AllItems 7.955 GB (8,541,124,958 bytes) 59540
/Top of Information Store/MVP DL 3.163 GB (3,395,854,617 bytes) 23009
/Top of Information Store/MVP Only DL 3.044 GB (3,267,951,982 bytes) 19192
/SubstrateFiles/SPOOLS 1.837 GB (1,971,942,903 bytes) 32446
/Top of Information Store/Inbox 940 MB (985,650,804 bytes) 6523
/Unified Inbox 928.6 MB (973,702,527 bytes) 6438
/Finder/OwaFV15.1AllFocusedAQMkAGU2MWM5NzU0LWY3MmQtNGI3OS1hNDVlLTBkMzI3OWVlADViM2YALgAAA6EpIkCGWdRMge0pKyjfROEBAEg98MzHI9FiFjwzzGYA9UAAAIBDQAAAA== 736.2 MB (772,009,689 bytes) 4584
/Finder/OwaFV15.1ToOrCcMeAQMkAGU2MWM5NzU0LWY3MmQtNGI3OS1hNDVlLTBkMzI3OWVlADViM2YALgAAA6EpIkCGWdRMge0pKyjfROEBAEg98MzHI9FiFjwzzGYA9UAAAIBDQAAAA== 533.5 MB (559,374,034 bytes) 4165
/Top of Information Store/Forums 523.7 MB (549,174,242 bytes) 4694
As well as the folders with most items:
$folders | Sort ItemsInFolder -Descending | select FolderPath,foldersize,ItemsInFolder -First 10 FolderPath FolderSize ItemsInFolder ---------- ---------- ------------- /AllItems 7.955 GB (8,541,124,958 bytes) 59540 /ApplicationDataRoot/d32c68ad-72d2-4acb-a0c7-46bb2cf93873/Activities 446.3 MB (468,014,414 bytes) 54069 /SubstrateFiles/SPOOLS 1.837 GB (1,971,942,903 bytes) 32446 /Top of Information Store/MVP DL 3.163 GB (3,395,854,617 bytes) 23009 /Top of Information Store/MVP Only DL 3.044 GB (3,267,951,982 bytes) 19192 /Finder/NoArchiveTagSearchFolder8534F96D-4183-41fb-8A05-9B7112AE2100 961.4 MB (1,008,126,877 bytes) 8219 /Calendar Version Store 433.1 MB (454,166,321 bytes) 7340 /Recoverable Items/Audits 29.8 MB (31,247,493 bytes) 6726 /Top of Information Store/Inbox 940 MB (985,650,804 bytes) 6523 /Unified Inbox 928.6 MB (973,702,527 bytes) 6438
Back to Outlook now. Why such items are being returned is not clear, but it seems to be a side-effect of the new server-driven search. The behavior doesn’t seem to depend on the Outlook build, assuming it’s a version that uses the server-driven search, as I can reproduce it with the several different versions, across different channels. Looks like a clear bug to me, but perhaps there is a reason for it…
And it’s not just Outlook exposing items in the Non-IPM subtree, eDiscovery and Content searches also suffer from the same issue. The same search query performed against my mailbox via the SCC Content Search UI returns the following:
While it might not be immediately visible from the screenshot, the selected item is one of the items stored in the application folders. More important is the number of items found by the search, and the breakdown by folder we can obtain by exporting the search report:
As you can see from the above, the bulk of returned items are stored in the Activities folder, same as what the Outlook search reported. If you with to examine any of these items, you can simply press the “Download original item” link in the UI. You can decipher the content of such items via MFCMAPI, but that’s a subject for another article. Believe me, there is some interesting data stored inside 🙂