(Re)Introducing the MSV (Mailbox Space Viewer) for Exchange 2010
A number of you may have noticed that yesterday I published a tool entitled the “WSV (White Space Viewer) for Exchange 2010”. Today I was contacted by Scott Schnoll (Principle Technical Writer for Exchange) via Twitter who pointed out that the “AvailableNewMailboxSpace” property for the Powershell command Get-MailboxDatabase is NOT the same as reading the total whitespace within the database.
I had a look around web, and whilst I found that I was not alone in believing that the above switch gave you a good indicator of white space within your Exchange databases, Scott was of course completely correct (I did not doubt him, I was interested in what the property actually represented).
It occurred to me during my research that there is definitely some confusion about how to determine white space in your Exchange 2010 databases – below are some random examples from around the web:
- http://www.expta.com/2010/09/reporting-database-whitespace-for-all.html (in the comments section, Elan and Jeff discuss the very issue that this article is about)
All of the above refer to the command that I have used in my Get-MailboxDatabase example later on in this post, and indeed what was the core foundation of the WSV tool.
Given the above I felt that it was important to pull the original post until such a time that I had confirmed all my facts and could publish a more accurate description of my tools functionality and what the AvailableNewMailboxSpace represents, and re-brand the software to a more suitable name.
The actual definition of the AvailableNewMailboxSpace property is as follows:
TheAvailableNewMailboxSpace parameter provides information about the free space that is used to create new mailboxes. This parameter does not represent the total white space in the database.
Further investigation on the web found the following information as part of an MSExchange Team Blog Post:
You will need to dismount the database and use ESEUTIL /MS to check the available whitespace in a database. For an example, see http://technet.microsoft.com/en-us/library/aa996139(v=EXCHG.65).aspx (note that you have to multiply the number of pages by 32K).
Note that there is a status property available on databases within Exchange 2010, but it should not be used to determine the amount of total whitespace available within the database:
Get-MailboxDatabase MDB1 -Status | FL AvailableNewMailboxSpace
AvailableNewMailboxSpace tells you is how much space is available in the root tree of the database. It does not factor in the free pages within mailbox tables, index tables, etc. It is not representative of the white space within the database.
What is Whitespace?
Database White Space is created when data is cleared from a Mailbox Database when the relevant data item’s retention period has expired. For example, if you delete an item from a mailbox and empty the “Deleted Items” folder – the item will be kept within the store for the period of time that is specified on the “Limits” property page of the Exchange Database – see below:
Mail items can be retrieved via the “Recover Deleted Items” option from within Outlook or Outlook Web App. However, once the period has expired the item is permanently remove from the store and is recycled as White Space.
The same principle also applies to mailboxes which are deleted – these are kept within the store until the “Keep deleted mailboxes” value has expired. Mailboxes are then also converted into whitespace.
Whitespace is a good thing in the context of Exchange Server. In essence, whitespace is used within the database, before Exchange will expand the physical size of the .edb file.
So for example; if you have deleted 10 mailboxes which may create 300MB of whitespace within the database, if someone sends an e-mail that is 50MB in size – the physical .edb file will not grow by 50MB. Exchange will store the message item within the 300MB of whitespace – leaving 250MB free within the database.
If someone sends an e-mail that is 310 MB in size (and if they do, find them and shoot them) – the physical database would only grow by 10MB.
In previous versions of Exchange (e.g. 2007 and below) whitespace was reclaimed within the database at pre-set intervals (these intervals were part of the online maintenance routines) – however in Exchange 2010 the online defrag is running continuously.
Furthermore in previous versions of Exchange, whitespace space was reported via the Application Event Log under evtID 1221 – this is now not the case in Exchange 2010.
Ok, so how do I view the amount of whitespace in my databases?
The only way to get an accurate representation of all the whitespace in an Exchange 2010 Mailbox Database is to use ESEUTIL /MS against a database target. This of course means that your Database needs to be dismounted.
In Exchange 2010 if you use the:
Get-MailboxDatabase -Status | select Name,Ava* | ft -AutoSize
command you are only presented with the amount of free space for new Mailboxes.
Using the above command will produce output similar to the following:
The application that I have developed below is useful for determining the amount of space in the database that is available for new mailboxes before Exchange will need to physically increase the size of the EDB – it does not give you a full picture of all the whitespace within the DB, for that you will need to run ESEUTIL.
Download, Prerequisites and Install
In order to run the tool, your host computer will need:
- Windows 2003 or 2008 x64
- .NET Framework 3.5
- Exchange 2010 Management Tools
Download the above WinZip SEA to your computer and then execute it. You will be asked for a target location where you wish to install the binary.
Using the tool
The tool is designed to be as simple as possible to use, when you have extracted it from the SEA package doubt click on the “MSV.exe” file.
You will be presented with a window that looks like the screenshot below. On the left hand side of the window you should see a list of your databases – clicking on a DB will populate the information on the right hand side of the screen.
I would like to apologise for posting what was slightly misleading information, and hope that I have clarified the issues concerned. I would also like to thank Scott for point the errata out.