Get-MailboxStatistics and the lack of an Integer

The other day while working on a new feature of the Priasoft Public Folder Toolbox a need arose to capture the available space on each Public Folder mailbox in Microsoft Office 365.  Naturally the immediate idea was to use the results from Get-MailboxStatistics to get such information. Get-MailboxStatistics returns many valuable bits of information about a mailbox, including Public Folder Mailboxes.  There are the obvious values like TotalItemSize and ItemCount.   There’s also the values for the established limits such as DatabaseProhibitSendReceiveQuota, which, if present, is the maximium amount of data the mailbox can contain before it will reject creating or saving new content.  There’s a few other values as well…some dates, GUIDs, and the legacyExchangeDN (aka x500). However, missing from the list of values are any percentage values like %FreeSpace or %Utilized.  Some other missing values are the total free space available as compared to the quota, if a limit exists.  Granted, such values are easily calculated but would have been easy for Microsoft to have provided along with all the other values.  Furthermore, Microsoft does this calculation for you in the web admin console for Exchange and Office 365. So, this new feature is to help customers with the headache of distributing a large amount of Public Folder data across two or more Public Folder Mailboxes.  In Office 365 a Public Folder mailbox has either a limit of 50GB or 100GB (depending upon the version of the back-end tenant; Microsoft is slowly updating tenants for the newer limit of 100GB).  If a customer has 500GB of Public Folder data, it has to be distributed across several mailboxes.  However, Exchange will not automatically start pushing data to a new mailbox just because the first one fills up.  Office 365 does have an “auto split” function that will split a Public Folder mailbox when it reaches its capacity, but such is not immediate nor quick.  Reports from customers are that the auto-split process can take many hours, several days, or even a couple of weeks to complete.  It is likely that the total item and folder count has much to do with the duration since there is a need to actually move items and folders from one Public Folder mailbox to another. The above reality leads to a situation of needing to understand the data at hand and determining how to distribute that data across multiple mailboxes but without filling up any single mailbox.  In order to do that, an analysis of each Public Folder mailbox is needed to understand its limit and how much data already exists in it (in the case of using pre-existing mailboxes). The frustration presented by Microsoft in the Get-MailboxStatistics output is that nearly all of the apparent numeric values are, in fact, not numeric at all and are an object that, when converted to a string for showing in a typical powershell text console, is formatted with a human readable value such as: 22.34 GB (22,339,443,193 bytes).  At first, those who are familiar with powershell will likely imagine that there must be some property of the value that allows one to get to the actual numeric value…and while technically true, access to this property is only available when powershell is running on the Exchange server.  When running remote powershell, as is the case with Office 365, the results from Get-MailboxStatistics are a simplified version of the original object so that it can be transmitted to the powershell console.  The value object, when on the Exchange server, has some functions to convert the value to GB, MB, KB, and bytes…but the simplified version of the object doesn’t have the functions to make these conversions – because the object is a data-only copy…none of the function code is sent from the server to the powershell console. Luckily the string representation of the value (as seen by .ToString()) does contain the “bytes” value in the text.  The string must be parsed and the numeric value extracted and converted to a number.  In .NET code, this is accomplished most completely by the following, where ‘prop’ is one of the numeric values from Get-MailboxStatistics:

System.Int64.Parse(System.Text.RegularExpressions.Regex.Match(prop.Value.ToString(), "([0-9" & Globalization.CultureInfo.CurrentCulture.NumberFormat.NumberGroupSeparator & "]+) bytes", RegexOptions.IgnoreCase), Globalization.NumberStyles.Number)

The above uses .NET powerful Regular Expression pattern matching engine to ensure that, regardless of number formats around the world, the digits are found and extracted properly.  Of key importance is the use of Globalization.CultureInfo.CurrentCulture.NumberFormat.NumberGroupSeparator so that regions that use a “.” as a thousands separator are properly picked up. In pure powershell the same can be done as follows:

[Int64]::Parse([System.Text.RegularExpressions.Regex]::Match(prop.Value.ToString(), "([0-9" & [Globalization.CultureInfo.CurrentCulture.NumberFormat]::NumberGroupSeparator & "]+) bytes", [System.Text.RegularExpressions.RegexOptions]::IgnoreCase), [Globalization.NumberStyles]::Number)

If you are searching for this issue, you’ll find other sites using string.Split() to handle this, but there’s no guarantee that the “(” will always be there (Microsoft can change the formatting at any time) and also the handling of the thousands separator is not being done.  The above versions should work in any case where there are numbers-and-separators followed by a space and the text ‘bytes’. It is a frustrating issue that Microsoft could have solved by simply adding an Int64 property to the numeric value object…but such wisdom seems to escape them sometimes :).