Office 365 mailbox statistics

A recent tweet took me to a script repository for Office 365 maintained by Microsoft’s Thomas Ashworth. Now, despite the best efforts of Twinbox to integrate my Twitter feed into Outlook (a job it does quite nicely), I don’t always respond to tweets or even read their content. After all, there’s so much rubbish you can deal with during any one day. But discovering an exception to the normal dross is always wonderful and so it is when you discover something useful.

When I visited it, the script repository offered just six scripts. Perhaps more will come over time. However, the point is that there’s some interesting stuff here that can be taken advantage of immediately, which I think is the hallmark of a truly useful repository. In this case, the PowerShell scripts deal with aspects of Office 365 tenant domain management. I think that most administrators who have to manage email in an Office 365 tenant domain limit their horizon to the Exchange Control Panel (ECP) and don’t attempt to navigate the depths of PowerShell for Exchange Online. ECP is all very well but its options are limited to the imagination of the engineers who built the tool allied to the time that they had available to do the work. Engineers always have too little time so the options and features offered by ECP are, by necessity, limited to the most essential tasks that administrators have to perform.

Reporting is never deemed to be an essential task. Or so it seems to be in the world of the Exchange development group. I think I have been complaining to a succession of Exchange General Managers about this very topic since 1996 or thereabouts. The last time I raised the topic was over a very nice dinner in San Diego in early May when my words were carefully listened to and then immediately filed in the “we’ll do it if we can but you know that we won’t” category. I wasn’t offended because this happens to me a lot. It must be the way that I approach General Managers.

In any case, I do think that reporting is important. It would be nice, for instance, if any version of Exchange offered administrators the chance to generate a simple list of all mailboxes, perhaps sorted by database or server or some other convenient attribute, together with important information about each mailbox such as the amount of data that it occupies, the number of items and folders in the mailbox, when the mailbox was last logged onto, and so on. You get the picture. And despite this being an obvious need and glaring hole in what is now a very complex and highly functional product, the Exchange developers have never even attempted to ship even some basic reports about user activity. It’s all very puzzling. Unless of course it’s part of a grand plan that determined that this area should be left to third party developers. .

The upshot is that administrators have attempted to fill the gap by building their own reports. The advent of PowerShell in Exchange 2007 provided the first really practical method for administrators to approach the task (if they didn’t want to master MAPI or one of the other APIs that Exchange has supported over the years). So we’ve had great fun over the past five years or so writing all sorts of reports to capture all sorts of information with many opportunities to swear oaths at the developers who forced this work upon us.

But getting back to the repository, I was happy to find that it includes a script called GetMsolUserReport.ps1 that generates mailbox statistics. Given my feelings on the topic as outlined above, this seemed to be a good place to start as I’m pretty certain that most Office 365 tenant administrators would like such information. I therefore downloaded the script, made no changes whatsoever, and fired up a PowerShell session on my PC. I then moved to the directory where I had stored the script and invoked it as follows:

C:Temp> .GetMsolUserReport.ps1

The script collected the credentials for my Office 365 tenant domain, set up a remote PowerShell session, and did its stuff. A couple of minor errors were reported with secondary proxy addresses but the error handling made sure that the script ran to the end. The errors that I met might well have been fixed in a new version of the script before you read this - or they remain as an exercise for the reader to fix all by yourself.

The script’s output is a CSV file that Excel was happy to open for me. You can edit the file as you want to highlight or eliminate columns and produce whatever report you think is necessary. One interesting thing that I discovered is that my mailbox had lower send and receive size limits than anyone else in the domain (good sense on the part of Exchange, I hear you say…). The only logical reason that I could come up with to explain this is that my mailbox was created a few months before the others in the domain and that Office 365 must have subsequently increased the send and receive limits for mailboxes.

Uncovering inconsistencies like this is a good reason for reporting and analysis. Unfortunately I’m stuck with the lower limits as RBAC prevents me being able to update these values (MaxSendSize and MaxReceiveSize) using the Set-Mailbox cmdlet. I can run the cmdlet, but can’t access the necessary parameters. This proves the power of RBAC to assign permissions at a granular level but it’s somewhat frustrating in this instance.

Oh well, being limited to a maximum send size of 20MB instead of 35MB won’t cause me too much heartburn. As for you, have a look at Thomas’s repository and see if some of his scripts will help you to understand the hidden side of Office 365 a little better.

Follow Tony @12Knocksinna