People that have dealt with Exchange for a while are probably well aware that there’s much more to a mailbox than what’s visible from within Outlook. Indeed, what email clients usually expose is the so-called IPM (intrapersonal messaging) subtree. The IMP subtree is basically a structure of folders intended to handle messages between human recipients, all stemming from the root folder, or Top of information store. It’s also referenced as the MsgFolderRoot and features all the familiar folders we use on a daily basis, such as Inbox or Sent items.
If you have ever worked with low-level tools such as MFCMAPI, chances are you have run into the Non-IPM subtree, also known as Root. This “non-interpersonal messaging” subtree represents a hierarchy of folders at the root level used for storing data and metadata created and/or consumed by different features and services. Yes, a bit vague, I know, but there is no real definition of what those folders contain. As you will see from the examples below, a huge number of such folders exists, both client- and server-created, but all of them are hidden from the end user.
As the name suggests, the point of this article is to give you some insight on how you can use PowerShell to expose information about the non-IPM subtree and the content therein. PowerShell is by all means not the only way to interrogate this data, and is actually a bit limited, but as usual it adds the benefit of simplicity. If you want to explore the non-IPM subtree on more detail and work with the individual items stored within the folders, you can use tools such as MFCMAPI, EWSEditor or the EWS and MAPI APIs directly.
So, what can you see via PowerShell? The answer is – a lot, thanks to the Get-MailboxFolderStatistics cmdlet. More specifically, you can run the cmdlet with the -FolderScope parameter set to the NonIPMRoot value, which in turn instructs the server to return details on the full folder hierarchy. Here’s an example:
Get-MailboxFolderStatistics vasil -FolderScope NonIPMRoot
The example above is of course just for illustratory purposes, the amount of information that will be spilled on the screen makes it impossible to get any real insight. If you want to work with the data, you should save the output to a variable or a CSV file, this would do:
$folders = Get-MailboxFolderStatistics vasil -FolderScope NonIPMRoot
The first thing you might want to check is the number of folders, which can easily be done by “measuring” the $folders variable or just querying for its .count property. In my case, the number is 237! Compare this to the number of files you have in your IPM store (the data returned by Get-MailboxFolderStatistics without using the FolderScope parameter) or in Outlook. What’s that, a five-fold increase? If you are running this against an on-premises mailbox, or a freshly created Office 365 mailbox that hasn’t used any of the “value added” cloud services, the numbers will probably be much smaller, but in most cases you will see at least a threefold increase in the number of folders.
Next, we can check the size of the mailbox. No, not the size you see in Outlook, the EAC or via the Get-MailboxStatistics cmdlet. The real size of the mailbox, containing all those additional bits of data and metadata Microsoft is storing in order to provide you with additional features and insights. An easy way to check for that is to look at the first folder entry returned by the cmdlet we run above, namely the Root (“/”) folder, and query the number of items contained within the folder and its children, as well as their size. Here’s how to do that:
folders[0] | select FolderPath,ItemsInFolderAndSubfolders,FolderAndSubfolderSize FolderPath ItemsInFolderAndSubfolders FolderAndSubfolderSize ---------- -------------------------- ---------------------- / 263464 18.3 GB (19,650,915,144 bytes)
Now compare those to what you see from other sources. In my case, I have a triple increase in terms of the reported size and number of items, your mileage will probably vary. Intriguing, no? So where all these numbers come from? Here’s a breakdown of the 10 largest folders by individual folder size for my mailbox:
$folders | Sort -Property @{Expression={[double]((($_.foldersize).split(" "))[2]).trimstart("(")}; Ascending=$false} | select FolderPath,foldersize,ItemsInFolder -First 10
FolderPath FolderSize ItemsInFolder
---------- ---------- -------------
/AllItems 6.93 GB (7,440,996,618 bytes) 76028
/Top of Information Store/MVP Only DL 2.577 GB (2,766,887,625 bytes) 16697
/Top of Information Store/MVP DL 2.217 GB (2,380,696,451 bytes) 17478
/Finder/NoArchiveTagSearchFolder8534F96D-4183-41fb-8A05-9B7112AE2100 1.674 GB (1,797,049,602 bytes) 33608
/GraphFilesAndWorkingSetSearchFolder 1.051 GB (1,128,168,273 bytes) 26852
/Top of Information Store/Files 1.051 GB (1,128,168,273 bytes) 26852
/Top of Information Store/Inbox 633.6 MB (664,371,783 bytes) 5317
/Unified Inbox 621.6 MB (651,821,313 bytes) 5233
/Finder/OwaFV15.1AllFocusedAQMkAGU2MWM5NzU0LWY3MmQtNGI3OS1hNDVlLTBkMzI3OWVlADViM2YALgAAA6EpIkCGWdRMge0pKyjfROEBAEg98MzHI9FiFjwzzGYA9UAAAIBDQAAAA== 413.2 MB (433,268,067 bytes) 2845
/Top of Information Store/Forums 288 MB (302,013,382 bytes) 4532
The AllItems folder is an interesting one. It seems to be a 1:1 copy of the IPM subtree, as it contains the exact number of messages and is the exact size as the Top of Information Store. Why Microsoft doubles the content of your IPM subtree is beyond me, but that folder alone accounts for 100% increase in the reported size and number of items.
Another duplication is also visible from the above. The Files folder (which we first spotted an year ago and is covered in this article by Tony Redmond) and the GraphFilesAndWorkingSetSearchFolder seem to be exact copies of each other, down to the individual items. They do have a different FolderType, with the latter being actually a Search folder. Perhaps Microsoft realized that a Search folder is more appropriate for the purpose served by the Files container and what we are currently seeing is the move to the new model?
Apart from the Files folder, multiple other Graph-related entries can be found in the Non-IPM subtree, for example everything under the GraphStore container:
$folders | ? {$_.FolderPath -like "/GraphStore*"}
Just looking at the folder names, you can also spot containers used by features such as Delve, MyAnalytics, Focused Inbox, Skype for Business, Teams, the infamous “Substrate”. There is no point in going over all of these, not just because of their number, but also because of the lack of publicly-available information as to what the items stored in those folders are used for. One can certainly get even more details on those folder using the –IncludeOldestAndNewestItems and the –IncludeAnalysis switches for the Get-MailboxFolderStatistics cmdlet, then speculate on their use. Opening the actual items via MFCMAPI or EWSEditor is also possible and can provide additional information, for example this is the method we used to discover that the Files folder contains actual… files!
Anyway, using the Get-MailboxFolderStatistics cmdlet and working with its output is fairly straightforward, so there is no point in wasting more time on it. Do share back in case you discover some additional interesting information about any of the non-IPM folders. And don’t forget to also check the other interesting subtrees, such as the Recoverable items subtree (known as RecoverableItemsRoot), the Archive (ArchiveRoot) and its Archive Recoverable items (ArchiveRecoverableItemsRoot) one.
Lastly, here’s also an example on how to query the non-IPM subtree via EWS and PowerShell. Skipping the “connectivity” details, you can use something like this:
$FPageSize =1000 $FOffset = 0 $folderView = New-Object Microsoft.Exchange.WebServices.Data.FolderView($FPageSize,$FOffset,[Microsoft.Exchange.WebServices.Data.OffsetBasePoint]::Beginning) $folderView.Traversal = [Microsoft.Exchange.WebServices.Data.FolderTraversal]::Deep $oFindFolders = $exchangeService.FindFolders([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::MsgFolderRoot,$null,$folderView) $oFindFolders.Folders | ogv
1 thought on “Using PowerShell to explore the Non-IPM subtree of an Office 365 mailbox”