Mail-Box Size Report Script and Database       Download Scripts

 Mailbox growth patterns are an often overlooked aspect of Exchange System Management mainly because their aren't too many tools out their that can report on mailbox size and track that size growth over a period of time. Currently their are quite a few good scripts out their that can be used to retrieve mailbox size data from a Exchange mail store. Microsoft published this Qbase article that detailed all the different methods you could use to programmatically get mailbox size from the mail store the only exception being you can now use WMI with Exchange 2003. The Exchange 2003 SDK also has a different version of a WebDAV (using a deep traversal) mailbox report script and a version of  a WMI mailbox size script. Which method you use will probably come down to personal preference and experience, I've put this article together to show a method I've used to retrieve and store this information and more importantly make it meaningful on a day to day basis.

The first step is to retrieve the mailbox usage data, for this I've choose to use Exoledb (WebDav or CDO would also be appropriate). The original script I've been using for a while used a Deep Traversal query of the mailbox retrieving the http://schemas.microsoft.com/exchange/foldersize property of each folder. This allowed a fairly simple script which could get the mailbox size data in one query. However after I read the above mentioned Qbase article and did a bit of research to see what sort of potential problems that might be caused by overusing Deep Traversal queries it was time for a rewrite.  The main theory behind this is any monitoring script should be as unobtrusive and transparent to your server as possible, Deep Traversal queries put a lot more stress on the Information store and the server as a whole (compared to Shallow Traversal) and this could in turn affect the reliability of your server (which is exactly the opposite purpose of implementing any sort of monitoring scripts). The basic premise of the script still remains the same it determines the size of the mailbox by adding together all the individual folder sizes.

But getting the size of the mailboxes however useful is only half the job, to measure growth trends you need to be able to keep track of the size of each mailbox over a period of time and then do some comparisons to work out the growth trends happening on your server. Also just seeing the total mailbox size however useful may not be helpful in telling you why the mailbox has grown to this size. For this the ability to drill in and see which folders have the most mail in them and have experienced the most growth can assist in determining where you mailbox policies may be most effective. This is where a database is necessary to handle the storage and display of the information your size script has been gathering. For this Article I've used Access as my database engine mainly because it allows me to build a self contained system that should be supported in most peoples environments (all you need is ODBC and IIS which every Exchange box should have), myself I prefer to use MSSQL as the backend where you get a little more flexibility being a true RDBMS. The Third and possibly most important task is to display the information you capture and be able to monitor and report on it. For this I've written two simple ASP pages the first gives you a view like this which you can drill into and get a view like this showing you the folder size details of a users mailbox. I've also include a graphing option that looks like this that will show a visual representation of the mailbox growth over a period of a month this can be useful to see if the growth occurred sharply or in large chunk.

Be Careful

A small word of warning before I go any further these scripts are designed to write the size of every folder in a mailbox to a row in a database. If you have a lot of mailboxes on your server this can add up to a lot of rows in the database. Access databases when they get large can have performance issues, you also need to be careful that you don't use up too much disk space on your mail server. Its a good idea to test the script with a few mailboxes first to see if its going to work and if you do intend to use it for a extended period of time to keep an eye on how much your database grows each night. One thing you can do to reduce the number of folders in your database is to remove the  /NON_IPM_SUBTREE from the end of the Exoledb URL I'll go into this a bit later.

How it works

There are two scripts that I use to make this work the first script is a LDAP query that will gather information about the user mailboxes located on a mailbox server.

Mailbox Query Script

set WshShell = CreateObject("WScript.Shell")
DomainName = "your.domain.com.au"
strDefaultNamingContext = "DC=your,D=domain,DC=com,DC=au"

GALQueryFilter = "(&(&(&(& (mailnickname=*)(!msExchHideFromAddressLists=TRUE) (| (&(objectCategory=person)(objectClass=user)(msExchHomeServerName=/o=exch-dev/ou=First Administrative Group/cn=Configuration/cn=Servers/cn=Yourserver)) )))))"
strQuery = "<LDAP://" & DomainName & "/" & strDefaultNamingContext & ">;" & GALQueryFilter & ";samaccountname;subtree"

Set oConn = CreateObject("ADODB.Connection") 'Create an ADO Connection
oConn.Provider = "ADsDSOOBJECT" ' ADSI OLE-DB provider
oConn.Open "ADs Provider"

Set oComm = CreateObject("ADODB.Command") ' Create an ADO Command
oComm.ActiveConnection = oConn
oComm.Properties("Page Size") = 1000
oComm.CommandText = strQuery
oComm.Properties("Sort on") = "givenname"

Set rs = oComm.Execute
while not rs.eof
    cmdexe = "c:\winnt\system32\cscript.exe d:\mreport1.vbs " & rs.fields("Samaccountname")
    ef = WshShell.run(cmdexe,0,true)
rs.movenext
wend

The above code works the same way as I have explained in this article, the main difference here is in the GALQueryfilter I'm using. For this script I've included 2 new parameters the first is the server name (this is so only mailboxes on this server are included) and the second is a parameter to exclude and hidden mailboxes. From experience I've found hidden mailboxes tend to cause a lot of problems with these type of scripts because you tend to pickup the system mailboxes and antivirus mailboxes whose structures differ and cause the script to error out.  The sections that I've highlighted in Red are the parts that you need to change to get it to work in your environment, the hardest one of these to get is the DN name of the server for the GalQueryFilter their are a few ways to get this the easiest way I've found is to use ADSIedit. If you are using ADSIedit just look at the msExchHomeServerName property of 1 of the user accounts that has a mailbox on the server you wish to query. The other method if you don't have ADSIedit installed (or just don't like using it) is to use the Exchange System Manager I've written a quick walkthrough of this method here.

Once this query has executed a record set is built and the next part of the code executes the mailbox size script for each mailbox. These two scripts could be combined into one but I found its more reliable to run separate scripts for each mailbox so that one error in a mailbox wont bring down the whole process.

Next Page