Users do not receive quota warning messages

We all know that, for better or for worse, the way Exchange calculates and sends Quota Messages changed with Exchange 2010 SP1. We also know that this has caused nothing but confusion for many Administrators out there…

This tip will try to give an overview of the new behavior for normal mailboxes and, more important, explain when users will actually receive these messages.

Pre Exchange 2010 SP1

In Exchange environments previous to Exchange 2010 SP1, Exchange sends a quota message to mailbox owners when a:

  1. Mailbox exceeds its IssueWarningQuota limit (the lowest storage quota);
  2. Mailbox exceeds its ProhibitSendQuota limit (the middle storage quota);
  3. Mailbox exceeds its ProhibitSendReceiveQuota limit (the highest storage quota).

Remember that:

  • quota messages are sent to mailbox owners, so if a mailbox is owned by a security group (shared mailbox), quota messages are sent to the security group;
  • quota messages are sent with high importance and are not subject to storage quotas, which means they are always delivered even if the recipient’s mailbox is full;
  • quotas can be configured at a mailbox or database level.

These quota messages are sent during the QuotaNotificationSchedule specified for each mailbox database, which would normally be something like every day from 4AM to 6AM:

Get-MailboxDatabase | Set-MailboxDatabase -QuotaNotificationSchedule “Mon.04:00-Mon.06:00, Tue.04:00-Tue.06:00, Wed.04:00-Wed.06:00, Thu.04:00-Thu.06:00, Fri.04:00-Fri.06:00, Sat.04:00-Sat.06:00, Sun.04:00-Sun.06:00”

During this period, Exchange goes through every mailbox in the database(s) and if any has exceeded the quota threshold, it sends the owner an e-mail. No matter if the schedule was 1h, 2h or 10h, as long as Exchange has enough time to go through every mailbox, everyone over quota receives one warning message.

Exchange 2010 SP1 Onwards

Now comes SP1 and all hell breaks loose… We still have:

  • the same 3 levels of quotas;
  • quotas configurable at the user or database level;
  • quota messages sent during the QuotaNotificationSchedule.

BUT…. The way these messages are generated has changed… Now, every mailbox has a flag that controls whether it is checked to see if it has exceed a quota threshold. This flag is only set if the mailbox size is more than 50% of the ProhibitSendQuota limit! Unfortunately, this flag is a system property (part of the code) and therefore not visible using MFCMapi…

Let’s take an example and imagine a mailbox currently 450MB in size. This mailbox (or its database) has IssueWarningQuota set to 400MB and ProhibitSendQuota set to 1GB. We can see the mailbox is over its warning limit but because 450MB is not over 50% of the ProhibitSendQuota (500MB), it will not be checked and will not receive a quota warning message!

On top of this, once a mailbox has been checked during the QuotaNotificationSchedule, the flag is cleared and the mailbox will not be checked again until the flag is reset. Now, here’s the problem I found: according to Microsoft documentation, this flag is reset when “either a message is saved in the mailbox or a message is submitted”. When this happens, if the mailbox size is more than 50% of the ProhibitSendQuota, the flag is reset and the mailbox will be checked during the next QuotaNotificationSchedule.

But what exactly is a saved message?! I assumed that if a user drafted a message and saved it without sending it, the flag would be reset. However, from my tests this is not the case… So far, only sending e-mails from a mailbox seems to reset this flag. This means that if you have a mailbox that only receives e-mails, it will never receive the warning message. Again, this is what I am seeing in the environment I work at and from my tests!

You might be asking why I previously emphasised the “1” in “everyone over quota receives one warning message”. By default, with SP1 the QuotaNotificationSchedule is set to run for 15 minutes every day at 1AM. If you increase this to 2h, for example, your users might receive more than one message at a time! I had cases where I had this set to run over 3h for testing purposes, and some users received 3 quota messages…


If you would like to see if/which mailboxes are over quota or received a quota message, you have a few methods:

Increase the diagnostic logging on the mailbox server you want to check:

  1. Open the Exchange Management Console;
  2. Choose Server Configuration;
  3. Select the the server name under Server Configuration for which you want to increase logging ;
  4. Choose Manage Diagnostic Logging Properties… under the Actions pane;
  5. Expand MSExchangeIS;
  6. Expand 900 Private;
  7. Choose Storage Limits;
  8. Select the Expert radio button and click Configure;
  9. You don’t need to restart the MSExchangeIS service or dismount and remount the database stores;
  10. The next time the QuotaNotificationSchedule runs, look for the EventID 1077 in the Application log.

Use PowerShell to check mailbox statistics:

Get-MailboxStatistics -Database MDB01 | ? {$_.StorageLimitStatus -eq “IssueWarning” -OR $_.StorageLimitStatus -eq “ProhibitSend” -OR $_.StorageLimitStatus -eq “ProhibitSendReceive”} | Select DisplayName, Alias, StorageLimitStatus

Use PowerShell to see which users received a quota message:

Get-TransportServer | Get-MessageTrackingLog -ResultSize Unlimited -Start “08/08/2012” -MessageSubject “your mailbox is” –EventID DELIVER | Select TimeStamp, Recipients, MessageSubject


To reiterate, from Exchange 2010 SP1 onwards:

  • Every mailbox has a flag to control if the mailbox’s quota is checked;
  • This flag is only set if the mailbox size is more than 50% of the ProhibitSendQuota limit;
  • If the flag is set, Exchange will send a quota message during the QuotaNotificationSchedule interval and then clear the flag;
  • The flag is reset only when a message is sent from the mailbox;

Hope this helps clarifying the new behavior regarding quota messages!

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top