Generating custom Mailbox limit (Quota Messages) for Exchange

One request I’ve seen a lot over the years is to be able to customize the quota messages generated by the information store process.  Customers have offered any number of reasons on why they want to do this – some for legal reasons can’t use PSTs, and some just want to give more helpful instructions to their users.  To understand the problems with this, you have to understand how the Store process creates these messages.

Each night, during quota maintenance, the Information store kicks off a background task that walks through the mailbox table, checking the mailbox size against a user’s configured limits.  A user falls into one of four categories by default:

  1. No limit
  2. Over warning limit
  3. Over send shutoff limit (QuotaExceeded)
  4. Over send receive shutoff limit (ShutoffQuotaExceeded)

The store creates a message (from the system attendant), and formats it using a string retrieved from MDBSZ.DLL (a compiled binary that is effectively part of the store).  This string is formatted with a few predefined values, and the message is delivered via a system delivery path into the user’s inbox as a “quota message”. The key part here is that the source of data is a string resource in a compiled binary. MCS (Microsoft Consulting Services) will contract to update MDBSZ.DLL with a new string, but that has to be maintained, as each new Hotfix and service pack (and version) of Exchange will update MDBSZ.DLL.

For Exchange 2000 post SP3 & Exchange 2003 SP1, we have taken a DCR (design change request) to enable Administrators to create their own custom quota messages.  Note that this does not mean editing the existing messages, or invoking that logic at all.  The DCR is really three bits of functionality:

  1. The first part of the DCR is a registry key that disables the system generated quota messages (similar to setting the quota maintenance to never).  This registry key allows the event logs to still be generated, but the quota messages themselves are not delivered.

  2. The second part of the DCR is a registry key that allows applications running as Local System to ignore quota settings (so you can save a message to a user’s inbox even if they are over the shutoff quota).

  3. With the first two parts, everything is in place to allow people to write their own quota generation apps, but the process is not straightforward – An application (as LocalSystem) retrieves the mailbox table for the store (using methods documented in our SDKs) and walks along, looking at the quota status of each row.  For each user over a limit, it then needs to retrieve the quota properties (off the user, then off the server if necessary) and then format and save a message.  Note that I keep saying “Save”, not “Send”.  We are not allowing users over their quotas to RECEIVE mail.  Applications running as localsystem can save a message into the inbox.   Still, the current method would require an AD trip per user, so we took a third part to the DCR –  In the third part, the Store exposes new properties from the Mailbox Table that contain the quota information for the user.

So, now a custom app could be written that walked the mailbox table, looking at the status, using the quota information to format a custom message, and the over ride registry key to be able to save it into the inbox.  This isn’t terribly complex code, but it didn’t exist.  As part of testing this change, we needed an app that would do exactly that, so I wrote one.  It began as a simple command line app (a derivative of the same tool I’ve modified to report mailbox sizes, repair OOFs, modify free/busy and other such things).  I converted it to a service, added event logging, diagnostic logging, a RPC interface and a MMC extension to trigger it, and perfmon counters.  The event logging and diagnostic code is inherited from a service I wrote for Exchange 5.5 that archived journaled email messages to SQL server for powerful searching. Custom messages can support inserts (%1, %2, %3, ect) for mailbox size, warning limit, send limit, send receive limit, and the difference between each.

You can download the service from The source is available as well under a slightly modified Microsoft Shared Source License.  The code as is worked at the last time I tested it, but my tests since converting to IExchangeManageStore4 (for supporting more than 64,000 mailboxes per server) have been limited. 

Why release the source? 

  • A quick download will show you that the service has a VERY manual setup.  Manually merging reg files, manually loading perfmon counters.  A rudimentary setup project is underway, but it’s no where near done.

  • Thresholds (the ability to deliver different messages at 10%, 15%, 25%, ect of quota are something the tool is designed to be able to do, but they aren’t done. Reports (copying the administrator or delivering a summary report) are not done. 

  • There needs to be a way to exclude mailboxes.  There isn’t.

  • Some people want to build a home grown mailbox manager app on top of this.  So be it – there are KB articles telling you what properties Mailbox manager uses, and it would be easy to extend. 

  • Some people want to archive messages to server based PSTs.  That’s do-able too, there’s just no current code for it.

  • Some people insist on using additional inserts (%11, %12, ect) thinking that surely the documentation is wrong and there are hidden or secret information bits you can insert into a custom message.  With the source, you can see for yourself what is available.

There’s a number of things that COULD be done, but I just don’t have time.  While this has been a pet project of mine for a while, there’s no way this will satisfy what each and every user wants.


  • Exchange 2003 SP1 includes support for the extended props.  When it ships, this will work against E2k3 servers.

  • This doesn’t do public folder messages.  It’s not difficult do, but would require AD/GAL information that the current service doesn’t use.

  • Must have a mailbox on each server.  Yup.

  • Not supported by Microsoft PSS.  No, it isn’t.  You have the code.  If you have a problem, post on the workspace, or debug it yourself. 

NOTE: The above note about lack of PSS support is no longer true. Microsoft Exchange Server Quota Message Service is now released on the official Exchange 2003 Tools web site and is now fully supported.


So, the workspace is open for business, the project and code are available for download. 


Jason Nelson

Comments (15)
  1. Jesse says:

    I am glad the MS has recognized the need for this, I just feel like the SP should contain more than the ability to write your own code, it is time that MS implimented a supported solution. This feature request has been around for at least 3 years, how much longer will we have to wait before we have a supported GUI configuration? Kodiak…?

  2. KC Lemson says:

    Jesse: I can’t really answer what might be available in the future. This is the option that is available at this time. Although it’s not an officially supported solution, perhaps an independent developer will help contribute to the project and build a UI on top of Jason’s tool.

    Also, If an ISV wanted to take advantage of #1 and #2 above and develop their own product to do this or add it into an existing product, that would also be an option.

  3. Rick says:

    Ideally, the administrator should have the abilility to customize ALL Exchange messages (NDRs/notifications) that are sent to the user via email (Netscape can do this!)

    I support a very large client in Canada that has both French and English users. Canada’s offical language is French AND English. So the user has the right in Canada to be dealt with in the language of their choice.

    Since all the users are on English servers, all the NDRs are sent as English messages.

    The french speaking users love to complain about this.

    We would like the ability to customize the messages so that they are bilingual.

  4. Al Mulnick says:

    Just out of curiousity, if it’s not supported, how is that any better than the method previuosly used by MCS in the field where the mdbsz.dll was manipulated? It’s a step in the right direction, but it’s still not there IMHO.


  5. Jason Nelson says:

    I’m not sure I understand the logic behind your question. PSS doesn’t support THIS tool. PSS also doesn’t support a host of 3rd party gateways, UM servers, wireless bridges, and other things. The server is still supported if you run them against it. This is just another 3rd party app, except that the 3rd party is anyone who wants to compile and run it.

  6. Benjamin Mateos says:

    Thanks for this !

    It needs to be improved, but It´s a beggining…



  7. Marian Henc says:

    Pity I cannot test it now. I am missing the post SP3 rollup package which upgrades store.exe to 6488 :( The hotfix is not yet available to public.

  8. Colin Walker says:

    Come on people – this is a free tool written by a guy as a pet project in his spare time.

    Be thankful for what you’ve got.

  9. Anonymous says:

    If you have used Exchange for any length of time I bet you have gotten at least one message from System Administrator telling you that you were over some kind of limit.  The folks at “You Had me at…

  10. Anonymous says: – Din portal til Microsoft Exchange Server information

  11. LLewis says:

    I can’t wait until this feature is ready for prime-time in an Enterprise shop to standarize from a single point across all servers within the Org or broken down by AG’s, etc. Maybe tie it to the Mailbox Manager on Recipient policies?

    Jason, good job and keep it up!


  12. Jonathan R says:

    I thought I had set it up correctly (on an Exchange 2003 server with SP1,

    making all the required registry changes etc.) but when I try to run a

    manual quota maintenance, I get the following error message:

    "The RPC Server is unavailable"

    Here are the variables I was using:

    SiteDN: /o=SMTPORG/ou=SITE1

    Server DN: /o=SMTPORG/ou=SITE1/cn=Configuration/cn=Servers/cn=ADCTEST


    CommonName: /o=SMTPORG/ou=SITE1/cn=Recipients/cn=BUILDER_B (the name of the

    mailbox that issues the quota messages)

    Version number is

    Anything (syntax, version number, etc.) need to change? I downloaded the

    code everal months ago, before Exchange 2003 SP1 came out so this was my

    first opportunity to try it.


  13. Jason Nelson says:

    Ok – it looks like a few things are wrong. First off, I recommend you use the 1.1.0 test release – it configures itself. Second – from the lack of a GCName key, I know this is the build that didn’t run right on non GCs. Thid – commonName is only the recipient portion of the RDN. Remove all traces of the 1.0.4 binaries, service, event log and perfmon entries, and give the 1.1.0 installer a try. If that doesn’t work, post on the workspace message boards – I watch those, and I’ll help you figure this out.

  14. Anonymous says:

    I wanted to talk a little bit in this blog about Mailbox Quota Limits “Mailbox over the limit”, and how…

Comments are closed.