It is generally considered best practice to set mailbox limits (also known as mailbox quotas) within your Exchange environment and apply them at the level of the Information Store.  The reason for this should be fairly obvious: without limits in place there is nothing to stop the Exchange Information Store database (or, more likely, the transaction logs) growing to fill the available disk space.  Rapid store growth can occur in a number of different scenarios, e.g. virus outbreak, denial of service attack, badly implemented Outlook rules, etc. 

Most organisations I come across do impose limits at the store level, but I am surprised at how many times I find individual mailboxes that are exempt from the store limits.   Although it is not generally recommended, it is not such a bad thing if limits are set on individual mailboxes (to override the store defaults), but there is a very real risk if no hard limit is set.  By this I mean the Prohibit send and receive at (KB): setting in the Storage Limits configuration window under the Exchange General tab of a user’s properties in ADUC.  Without this hard limit the store is exposed to the problems outlined in my first paragraph above. 

The screenshot below shows the Storage Limit configuration window in ADUC together with the LDAP display names of the three quota settings.

So how do you find mailbox-enabled users that are exempt from the store default limits?  You don’t want to have to go clicking through the properties of every user in ADUC.   Fortunately, ESM gives you a simpler alternative.   You can add a new column called Storage Limits to the display of mailboxes within any given store, as shown in the screenshot below.  If you see a mailbox with “No checking” in the Storage Limits column you know that no limits have been set on the mailbox. 

You will not be surprised to learn that the limits are stored in AD as attribute values.   This allows us to search directory for information about the storage limits using LDAP queries.  The example below (using ADFIND from www.joeware.net) shows a search for mailbox-enabled users that have either been exempted from the store limits or that have individual limits set.  (Note that the query is one command line and only appears on more than one line below to fit the screen).

Let’s break the query down to explain how it works in a bit more detail. 

-nodn simply instructs ADFIND not to display the distinguishedName attribute in the results.

-csv is a switch used to generate a comma separated value output.  Very useful if you want to import the results into Excel.

-default is a shortcut way of instructing ADFIND to search the default domain partition.

-f is the switch to start the LDAP filter.

samAccountType is an indexed attribute and the value 805306368 provides a quick way of finding user objects. An alternative would be to specify (objectClass=user)(objectCategory=person).

(homeMDB=*) narrows the search to only include objects that have a value for homeMDB, i.e. mailbox-enabled objects.

(!mailnickname=systemmailbox*) is required to exclude any system mailboxes from the results.  These are always exempt from the mailbox store defaults, so there is no point having them in the search results.

(!mDBUseDefaults=TRUE) finds any objects that to which the store default limits do not apply.

sAMAccountName is the first of the attribute values to be returned by the search.  It is basically the login ID of the user.

displayName is kind of obvious

MDBStorageQuota corresponds to the Issue warning at (KB): setting in ADUC.

MDBOverQuotaLimit corresponds to the Prohibit set at (KB): setting in ADUC.

MDBOverHardQuotaLimit corresponds to the Prohibit send and receive at (KB): setting in ADUC.

An example of the results returned by the ADFIND search is shown below.

"samaccountname","displayname","MDBStorageQuota","MDBOverQuotaLimit","MDBOverHardQuotaLimit"

"SmithJa","Smith, James","10240","20480","102400"

"HayesCa","Hayes, Carson","10240","20480","204800"

"BotheAl","Bothe, Alexis","","",""

In this example, the users SmithJA and HayesCA both have individual limits configured.  In other words they are exceptions to the default store limits.  The user BotheAl has been exempted from the default store limits, but has no alternative limits set.  BothAl therefore represents a risk and action should be taken to ensure limits are imposed for this user.

Summary

It’s considered best practice to set mailbox storage limits at the store level.  Setting individual mailbox limits may be required for certain special users, but can cause confusion.  Mailbox-enabled users with no limits at all represent a real risk to the stability of your Exchange environment and should be addressed.

Tony Murray