The Get-MailboxStatistics cmdlet is probably one of the most used commands in an Exchange environment. Some new properties are reported if you run the command on Office 365. So what's the deal. And why is Exchange so lousy at reporting anyway?
I like the Get-MailboxStatistics cmdlet, if only because it provides an insight into mailbox contents, which you sometimes need to understand in order to perform tasks such as server sizing. As Jeff Mealiffe (the performance guy) remarks in his Sizing Exchange 2013 post: “Sizing is both a science and an art form” and understanding what’s going on in user mailboxes is part of the data collection process that contributes to the science of sizing. Deciding what to do with that data is the art.
Of course, Get-MailboxStatistics is also used as the basis for many mailbox reports, such as the one available from ExchangeServerPro.com. The Exchange Reports Codeplex project is another example that is worth checking. Many other examples are available on the web, most of which follow the same approach – select a batch of mailboxes, run Get-MailboxStatistics for each mailbox to extract data, report the data, iterate.
In fact, so many of these reports exist it’s a wonder that Microsoft has not yet understood that Exchange is highly deficient in the reports available to administrators. Most of the time no reports are available at all, even about simple stuff like listing all mailboxes. Even where reports are providing (mailbox and administrative auditing), XML format output is generated. Office 365 is better, but not by much. Microsoft really should do better in a product that is so mature and successful.
In any case, I was asked to explain some of the output from Get-MailboxStatistics. Most of the stuff is easy to understand.
- ItemCount: The total number of items in a mailbox
- TotalItemSize: The size of the items in a mailbox. Remember, Exchange 2013 calculates mailbox size differently to other versions because it factors in database overhead that was previously ignored.
- DeletedItemCount: The number of items in the Recoverable Items folder. This number does not include any items retained because of an in-place hold or other compliance features. These items are those that users can view through the “Recover Deleted Items” option.
- TotalDeletedItemSize: The size of the items in the Recoverable Items folder. Remember that Exchange maintains a separate quota for the Recoverable Items folder.
All pretty straightforward. But then I was asked about some other properties that I had not encountered before:
MessageTableTotalSize : 423.9 MB (444,465,152 bytes)
MessageTableAvailableSize : 14.94 MB (15,663,104 bytes)
AttachmentTableTotalSize : 1.503 GB (1,613,725,696 bytes)
AttachmentTableAvailableSize : 7.813 MB (8,192,000 bytes)
OtherTablesTotalSize : 17.25 MB (18,087,936 bytes)
OtherTablesAvailableSize : 1.188 MB (1,245,184 bytes)
Hmmm… These properties do not appear when you run Get-MailboxStatistics on anCU1 mailbox server. They do if you run the cmdlet against Exchange Online, providing that your tenant has been upgraded to Wave 15 (Exchange 2013). What’s going on here?
As it turns out, the presence of these properties is evidence of how Microsoft is executing against the strategy that it explained how cumulative updates for Exchange 2013 would be released. In essence, the on-premises and cloud versions of Exchange share a common code base, new features are released into the cloud first (Microsoft controls the end to end operation so it’s easy for them to do this on a controlled basis) and then find their way into the next cumulative update that is delivered to on-premises customers. The idea is that if everything works for the millions of cloud users who access , there’s more than a fair chance that on-premises customers will be happy too.
The properties listed above belong to a new feature that will be revealed in an on-premises update soon. That’s all I can say on the matter. We will just have to wait until Microsoft is ready to tell us exactly how these properties are used.
Follow Tony @12Knocksinna