RPC Client Access Throttling Logging

By default, you have to use PerfMon counters to see how often throttling is occurring for RPC connections.

However, there is a way to have this information "properly" logged. To achieve this, modify the Microsoft.Exchange.RpcClientAccess.Service.exe.config file located in \Program File\Microsoft\Exchange Server\V14\Bin and add Throttling to the LoggingTag string so it looks like this:

<add key=”LoggingTag” value=”ConnectDisconnect, Logon, Failures, ApplicationData, Warnings, Throttling”/>

Now restart the RPC Client Access service and you will see this information in logs created in the “\Program Files\Microsoft\Exchange Server\V14\Logging\RPC Client Access” folder. When throttling happens, you will usually find the keyword “exceeded”.

This way, you can easily see when RPC Throttling kicks in, what it is doing and why!

Office 365 Portal Login Error on Mobile Devices

Since early this week that whenever I try to login to an Office 365 “wave 15” tenant on a mobile device I get the following error message:

I have tried from an Android mobile phone and iPad, always with the same result...

I know for a fact that Microsoft is looking into this at the moment.

As a workaround, if you go to:

  • https://mail.office365.com

  • https://tenant_domain.sharepoint.com

you will be able to login directly to OWA or SharePoint. However, this from an iPad as from my android phone I get the error: “the page contains too many server redirects”...

I will update this post when I get more new on this.

Exchange 2013 Data Loss Prevention

Data Loss Prevention [DLP] is a system designed to detect a potential data breach/leakage incident in a timely manner and prevent it. When this happens, sensitive data such as personal/company information, credit card details, social security numbers, etc., is disclosed to unauthorized users either with malicious intent or by mistake. This has always been an important matter for most companies as the loss of sensitive data can be very damaging for a business. For many years now, there have been both software and hardware solutions that monitor data while:

• in-use: end-user actions such as copying data to USB or printing it for example;

• in-motion: network communications like e-mail, web traffic, Instant Messaging, etc.;

• at-rest: data stored in file shares or on users’ drives.

Up until now, Exchange Administrators had to rely on 3rd-party solutions to achieve this, but some solutions would cause more harm than good and user productivity would suffer. With Exchange 2013, Microsoft now makes it possible to enforce compliance requirements for such data and control how it is used in e-mail. DLP is the new feature that allows administrators to manage sensitive data in Exchange!

To read the full article, please go to MSExchange.org - Exchange 2013 Data Loss Prevention.

Default Junk E-Mail folder moved to a subfolder of Journal

A while back got a user saying he wasn’t receiving some e-mails. Straight away I asked for an example and searched the Message Tracking Logs for the e-mail, only to confirm it had been delivered.

Luckily for me, my search revealed something really useful too:
 

RunspaceId : b1156ba1-602e-434f-97c2-14822536234c

Timestamp : 05/11/2012 08:48:23

ClientIp :

ClientHostname : xxxxxxx

ServerIp :

ServerHostname : xxxxxxx

SourceContext : 08CE8549B7FC9C12;2012-11-05T08:48:23.828Z;0

ConnectorId :

Source : STOREDRIVER

EventId : DELIVER

InternalMessageId : 4039958

MessageId : <210c68f5fb76da439a65309fd835991f0c7ce3 data-blogger-escaped-nat10exc01="nat10exc01">
Recipients : { xxxxxxx@domain.com }
RecipientStatus : {Junk E-mail}
TotalBytes : 20527
RecipientCount : 1
RelatedRecipientAddress :
Reference :
MessageSubject : RE: Wednesday
Sender : xxxxxxx@external.domain.com
ReturnPath : xxxxxxx@ external.domain.com
MessageInfo : 2012-11-05T08:48:23.000Z;SRV=xxxxxxx.domain.com:TOTAL=0;SRV=xxxxx.domain.com:TOTAL=0
MessageLatency : 00:00:00.9060000
MessageLatencyType : EndToEnd
EventData : {[MailboxDatabaseName, mdb33], [DatabaseHealth, -1]}

The e-mail was delivered to the Junk E-mail folder (look at RecipientStatus)! :) Ok, job done! Not exactly... When I went to the user’s mailbox to check a couple of e-mails to see if they were actually Spam, I couldn’t find the Junk E-mail folder! For some strange reason, it got moved to inside the Notes folder!...

So, how do we move it back?! If you try to move any of the default folders like Inbox, Deleted Items, etc., you will simply receive an error message.
The only way to move these is to use MFCMapi:
1. Download MFCMAPI
2. Launch MFCMAPI
3. Go to Session -> Logon and Display Store Table
4. Select the outlook profile of the user and double-click “Mailbox - User Name”
5. Expand “Root Container”
6. Expand “Top of Information Store”
7. Locate Junk E-mail, right click it and select Copy
8. Highlight “Top of Information Store”, right click it and select Paste
9. Click OK
10. Check “COPY_SUBFOLDERS” and “FOLDER_MOVE” and click OK

Hope this helps!

iOS 6 issues with Exchange - Update

This is an update post of the iOS 6 issues with Exchange post from early October.

Looks like Apple has released an update for iOS 6 (available via iTunes and wirelessly) which supposedly fixes the issues of this OS with Microsoft Exchange meetings!

“This update contains improvements and bug fixes, including:

• Fixes a bug that prevents iPhone 5 from installing software updates wirelessly over the air;

• Fixes a bug where horizontal lines may be displayed across the keyboard;

• Fixes an issue that could cause camera flash to not go off;

• Improves reliability of iPhone 5 and iPod touch (5th generation) when connected to encrypted WPA2 Wi-Fi networks;

• Resolves an issue that prevents iPhone from using the cellular network in some instances;

• Consolidated the Use Cellular Data switch for iTunes Match;

• Fixes a Passcode Lock bug which sometimes allowed access to Passbook pass details from lock screen;

• Fixes a bug affecting Exchange meetings”

You can find details regarding this update here.

Exchange Server 2013 RTM Now Available

And here it is! The release-to-manufacturing [RTM] version of Exchange 2013 is now available for evaluation here!   :)

Lync Server 2013 RTM

You will be pleased to know that the RTM version of Lync Server 2013 is now available for a free 180-Day evaluation!

 

Download the Latest Version

Exchange 2013 DAG CreateCluster() Failed Error

So far I have encountered the following problem in two completely separate Exchange 2013 Preview environments when creating a Database Availability Group [DAG].

Started by creating a simple DAG without any problems, only specifying its IP address and letting Exchange decide which server to use as the Witness Server. However, whenever I tried to add any of the mailbox servers to this DAG, I would get the following error:

 

Note the "CreateCluster() failed with 0x5. Error: Access is denied" part of the error message.

If we look at the dagtask log mentioned in the error above, we will see all the tasks Exchange performs when adding a server to the DAG and where it failed:

[2012-10-26T18:23:18] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseConfigureClusterAccount, ePhaseType = ClusterSetupPhaseStart, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 94, szObjectName = DAG1 in organizational unit CN=Computers,DC=letsexchange,DC=com, dwStatus = 0x0 )

[2012-10-26T18:23:18] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseConfigureClusterAccount, ePhaseType = ClusterSetupPhaseEnd, ePhaseSeverity = ClusterSetupPhaseFatal, dwPercentComplete = 94, szObjectName = DAG1 in organizational unit CN=Computers,DC=letsexchange,DC=com, dwStatus = 0x5 )

When dwStatus is 0x0, it means “success” but 0x5 means “access denied” just like the error we received in the Shell.

After some troubleshooting, I found out that the DAG’s Cluster Name Object [CNO] wasn’t created properly! There were two problems with the CNO:

1. The Exchange Trusted Subsystem universal security group didn’t have Full Access permissions to it;

2. The CNO was enabled in Active Directory:

After assigning full control to DAG1 AD object to the Exchange Trusted Subsystem and then disabling it, everything worked just fine:

 
For more information: Pre-stage the Cluster Network Object for a Database Availability Group

Hope this helps!

Wiped Mobile Devices Can Still Access Mailbox

When you wipe a mobile device that has a partnership with your Exchange environment, it might still be able to re-establish a connection and access the mailbox it had configured for 24 hours. This is the same as what happens with Outlook Web App and similar to when you disable an Active Directory account and the user can still use Outlook to access his/hers mailbox for up to 2 hours.

The solution to immediately prevent access to the mailbox after issuing a wipe is to:

1. Disable the mailbox;

2. Set a Send Prohibit Quota of 0KB;

3. Move the mailbox to another database.

If this is a mailbox in Office 365, then disable the protocols using the Set-CASMailbox cmdlet!

Exchange 2013 Beta Exams

Microsoft Exchange Server 2013 MCSE Beta Exams are now open for registration for Microsoft Learning Subject Matter Experts (SMEs):

• Beta exam – 71-341: Core Solutions of Microsoft Exchange Server 2013 Customer Preview
• Beta exam – 71-342: Advanced Solutions of Microsoft Exchange Server 2013 Customer Preview

The beta exam period will run from October 19th to November 8th 2012 and is based on Exchange 2013 Customer Preview. The live exams testing Exchange 2013 RTM will be released around January 2013.

For more details on the upcoming Exchange 2013 certifications: 70-341 and 70-342

Exchange 2013 RTM

Today the Exchange engineering team signed off the Release to Manufacturing (RTM) build of the new Exchange 2013. This means the coding and testing phase of the project is complete and they are now focused on releasing the new Exchange via multiple distribution channels. General availability is planned for the first quarter of 2013.

In addition to Exchange, the new Office, SharePoint, and Lync have also reached RTM.

Source: EHLO

iOS 6 Issues with Exchange

There have been some reports that iOS 6 is not working properly for many Exchange users... Apparently there are two issues:

Push E-mail

Push delivery of e-mail does not work, meaning users have to manually check for e-mails. It seems that this issue is not carrier or device specific and rebooting or reconfiguring the Exchange accounts only “fixes” the issue temporarily.

Meetings

This second issue happens when users decline a meeting invitation from an iOS 6 device. Instead of simply sending a notification to the meeting organizer, iOS 6 sends meeting cancellation notices to the entire group of attendees, cancelling the invitation for everyone!

In the environment where I work, we don’t seem to be experiencing any of these issues. Initially I asked colleagues if they were having any problems with push e-mail and they were all working fine (I believe our ServiceDesk has not received any calls regarding this yet – we have 651 devices on iOS 6 so far).

As to the second issue, I tested it three times with different users and with the new iPad, iPhone 4S and iPhone 5 and couldn’t replicate the issue...

However, this seems to be affecting many, many Exchange 2007/2010 organizations out there, so please be aware of this and test it!

UPDATE: The Exchange Team has just published a post on this: iOS6 devices erroneously take ownership of meetings!

UPDATE 2: looks like Apple has released an update for iOS 6 (available via iTunes and wirelessly) which supposedly fixes the issues of this OS with Microsoft Exchange meetings! More information here.

List Litigation Hold Users and Size

A feature introduced in Exchange 2010 RTM and that is being used more and more it Litigation Hold. It is used during a lawsuit, investigation or similar events to preserve mailbox items from inadvertent or purposeful modification or deletion by the user (or someone with access to the mailbox) and from automated deletion by retention policies. Until the hold is removed, deleted items are not purged from the mailbox database and if a mailbox item is modified, a copy of the original item is also retained. These are returned in Discovery searches performed when the mailbox is on Litigation Hold. Any retention policies applicable to the mailbox don't need to be suspended. Because messages continue to be deleted as expected (except from the Recoverable Items\Purges folder!), users may not notice they're on Litigation Hold.

 

To check if there are any users in your organization currently enabled for Litigation Hold, simply run the following cmdlet:

Get-Mailbox -ResultSize Unlimited -Filter {LitigationHoldEnabled -eq $True}

If you want to check the Recoverable Items folder size for all mailboxes on Litigation Hold, i.e. how many data is being held by Litigation Hold, use the following cmdlet:

Get-Mailbox -ResultSize Unlimited -Filter {LitigationHoldEnabled -eq $True} | Get-MailboxFolderStatistics –FolderScope RecoverableItems | FT Identity, FolderAndSubfolderSize

 

Or if you simply want to check a single mailbox:

Get-MailboxFolderStatistics <user> -FolderScope RecoverableItems | Select Identity, FolderAndSubfolderSize

Hope this helps!

How to Determine Continuous Replication Mode (Block Mode or File Mode)?

In Exchange 2007 and 2010, Continuous Replication operates by shipping copies of the logs created by the active database copy to the passive database copies. With Exchange 2010 SP1, this is known as Continuous Replication - File Mode as the log file is only copied once it is full (1MB). But SP1 introduces a new form of continuous replication known as Continuous Replication - Block Mode. In block mode, when an update is written to the active database log file it is immediately copied to the passive mailbox copies, thus reducing the latency between the time a change is made on the active copy and the time that same change is replicated to a passive copy. This way, if a failure occurs on the active copy, the passive copies will have been updated with most or all of the latest updates.

However, Block Mode is only active when continuous replication is up-to-date in file mode. The Log Copier component monitors the copy and replay queue lengths of databases as transaction logs are generated and takes care of transitioning into and out of block mode automatically.

To determine if continuous replication is operating in block mode or file mode, use the following cmdlet:

Get-Counter -ComputerName <<DAG_Member_Name>> -Counter “\MSExchange Replication(*)\Continuous replication - block mode Active”

The output will be something similar to:

Timestamp                 CounterSamples

---------                 --------------

04/09/2012 11:39:46       \\MBX1\\msexchange replication(mdb31)\continuous replication - block mode active : 1

                          \\ MBX1\\msexchange replication(mdb32)\continuous replication - block mode active : 1

                          \\ MBX1\\msexchange replication(mdb33)\continuous replication - block mode active : 0

Here, the “1” means that block mode is active while a “0” means it is not. However, note that your active databases will always show “0”, we are just interested in the passive copies!

Mailboxes Quarantined due to Troubleshoot-DatabaseSpace.ps1 Script

Exchange 2010 SP1 added a new script called Troubleshoot-DatabaseSpace.ps1 that is used to detect excessive growth of database and log drive volumes. This script can be run manually by administrators but if you have Microsoft System Center Operations Manager (SCOM) 2007 it is run automatically every 15 minutes.

This script performs the following actions:

1. Track log generation rate for the highest log generators (mailboxes) per database. This helps determine which users are logging too heavily and potentially causing space issues;

2. Track available disk space for both database and log files. If either of these is within a configurable threshold of being full (25% by default), further action must is taken;

3. Track log generation rate. If it appears that the disk is going to run out of space within the value specified by the HourThreshold parameter (12 hours by default and based on the log generation rate), further action is taken;

4. If all of the above conditions are fulfilled, the script determines the list of top 25 users who accessed the database during the last 1 hour period. The script then quarantines the top high-usage mailboxes for 6 hours, during which they will not have access to e-mail;

5. If the troubleshooter is unsuccessful at dropping the log generation rate to below the threshold level, it will write out events that translate into health model alerts. At this point, the script removes the database from provisioning by running the Set-MailboxDatabase cmdlet with the ExcludeFromProvisioning parameter set to $True against the specified database;

When mailboxes are quarantined, you will see entries in the Registry of the mailbox server hosting that database/mailbox in:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\"server_name"\Private-"DB.Guid"\"Mailbox_Guid"

To check the events logged by this script go to the mailbox server you want to check and then Event Viewer -> Application and Services Logs -> Microsoft-Exchange-Troubleshooters/Operational. Note that if you run the script manually through the Shell it will not produce any output - you have to check the Event Viewer.

If you run the script manually without any parameters or if you have SCOM running this script automatically, then it will use default values specified in the StoreTSConstants.ps1 script located in the same folder. This is where you can customize the 25% threshold, for example, if it is not ideal for your environment:

   # The percentage of disk space for the EDB file at which we should start quarantining users.

   $PercentEdbFreeSpaceDefaultThreshold = 25

   # The percentage of disk space for the logs at which we should start quarantining users.

   $PercentLogFreeSpaceDefaultThreshold = 25

   # The percentage of disk space for the EDB file at which we are at alert levels.

   $PercentEdbFreeSpaceAlertThreshold = 16

   # The percentage of disk space for the EDB file at which we are at critical levels.

   $PercentEdbFreeSpaceCriticalThreshold = 8

   #The number of hours we can wait before running out of space.

   $HourDefaultThreshold = 12

In order for mailboxes to be quarantined, the –Quarantine parameter must be passed to the script, which the SCOM monitor uses by default. Because the Exchange Management Pack is sealed, you can’t change this...

So, if 25% is too high for your environment, you can change the value by updating the StoreTSConstants.ps1 script across all your mailbox servers or, ultimately, simply disable the SCOM monitors that run this script:

• KHI: Failed to execute Troubleshoot-DatabaseSpace.ps1

• KHI:The database copy is low on database volume space and continues to grow. The volume has reached critical levels 8% free.

• KHI:The database copy is low on database volume space and continues to grow. The volume has reached error levels under 16% free.

• KHI:The database copy is low on database volume space and continues to grow. The volume is under 25% free.

Resubmit Messages in Queues

There might come a time where you experience a problem with you Hub/Edge Transport servers, Mailbox servers or e-mail gateway and messages are stuck in Queues. Once you resolve the issue, you can either wait a few minutes for Exchange to resubmit the e-mails or you can manually resubmit them to the Submission queue for the categorizer to reprocess as long as they have the following status:

·         Mailbox delivery queues or remote delivery queues that have the status of Retry. The messages in the queues must not be in the Suspended state;

·         Messages in the Unreachable queue that aren't in the Suspended state;

·         Messages in the poison message queue.

 

 

To manually resubmit messages, you can use the following methods (examples below):

·         Use the Retry-Queue cmdlet with the -Resubmit parameter;

·         Export the messages to .eml message files and resubmit them by placing them in the Replay directory;

·         Use Queue Viewer or the Resume-Message cmdlet to resubmit the messages in the poison message queue. You can’t use the Retry-Queue with the -Resubmit parameter cmdlet to resubmit messages in the Poison Queues.

 

 

By using the –Resubmit parameter, messages are forced to be resubmitted through the Categorizer for a new delivery attempt. If you do not use the –Resubmit parameter, the delivery queue will try to connect to the next hop immediately without resubmitting the messages through the Categorizer.

 

 

Let’s look at a few examples:

1. To export a copy of a message (so you can put it into the Replay directory) that has an InternalMessageID of 1234 that's located in the remote delivery queue for the domain MSExchange.org on the server HUB01 to the path C:\MSExchange Export\export.eml:

Export-Message HUB01\MSExchange.org\1234 -Path “C:\MSExchange Export\export.eml”

2. To resubmit all the messages in the 62306 delivery queue of the HUB01 server, use the following cmdlet (you can’t use the EMC):

Retry-Queue “HUB01\62306” -Resubmit $True

3. To resubmit all the messages in all delivery queues of server HUB01 that have a status of Retry (again, you can’t use the EMC):

Retry-Queue –Server “HUB01” -Filter {Status -eq "Retry"} -Resubmit $True

4. To resubmit all messages located in the Unreachable queue of server HUB01, use the following cmdlet (again, you can’t use the EMC):

Retry-Queue “HUB01\Unreachable” -Resubmit $True

5. Let’s force a connection attempt for all queues that are holding messages for the domain msexhange.org, have a status of Retry and are located on the server HUB01:

Retry-Queue –Server “HUB01” -Filter {NextHopDomain -eq “msexchange.org” -and Status -eq “Retry”}

 

6. To resubmit messages in the Poison Queues, you have to resume the messages. As I mentioned previously, the Poison Queue cannot be resubmitted by using the Retry-Queue cmdlet with the -Resubmit parameter.

Remember that the Poison Queue contains messages that are determined to be harmful to the Exchange system after a server failure. They may also be victims of a poorly written agent that crashed the Exchange server while it was processing them. If you're unsure of the safety of the messages in the poison message queue, you should export them to files so you can examine them.

 

Using the Exchange Management Console to resume messages in the Poison Queue:

1.       In the EMC click Toolbox;

2.       Open the Queue Viewer tool;

3.       In Queue Viewer, click the Queues tab;

4.       Click the Poison Queue and select View Messages;

5.       Select one or more messages from the list, right-click them and select Resume.

 

To use the Shell you must first determine the identity of the message to be resumed. This example will show the identity of all messages in the poison queue:

Get-Message -Queue “Poison” | Select Identity

 

Now you can use the identity to resume the message. For example, let’s resume the message with an identity value of 123:

Resume-Message 123

 

Exchange 2010 EventID 9320 and 9359

During the generation of your Offline Address Book [OAB] you might see the following warning logged in the Exchange server responsible for generating the OAB:

Log Name:      Application

Source:        MSExchangeSA

Date:          05/07/2012 05:02:35

Event ID:      9320

Task Category: (13)

Level:         Warning

Keywords:      Classic

User:          N/A

Computer:      SERVER.domain.com

Description:

OABGen could not generate full details for some entries in the offline address list for address list '\Global Address List'.  To see which entries are affected, set event logging for the offline address list generator to at least medium.

And a similar warning to the one below for many of your users:

Log Name:      Application

Source:        MSExchangeSA

Date:          05/07/2012 05:02:08

Event ID:      9359

Task Category: (13)

Level:         Information

Keywords:      Classic

User:          N/A

Computer:      SERVER.domain.com

Description:

OALGen truncated or dropped properties for entry 'USERNAME' in address list '\Global Address List' because they exceeded the configured size limits for the version 4 offline address list.  The affected MAPI ids are:  8008. 

- \Default Offline Address List 

The possible affected MAPI IDs are:

• 0x8CD8000D = PR_EMS_AB_AUTH_ORIG

• 0x8008101F = PR_EMS_AB_IS_MEMBER_OF_DL_W

The example above with the 8008 ID is generated for each user in the OAB that is a member of a Distribution List [DL] and for each DL that has members.

This happened because the Active Directory attributes member and memberOf are not part of the truncated property list for regular groups. So when the OAB is being generated, this property is read but because Exchange can’t see it in the list, a 9359 event gets logged.

It looks like this is by design so, at the moment, there is no workaround or a way to suppress these warnings. The good news are that these warnings are expected, can be ignored and Microsoft has plans to address this!

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...

In this post I will try to give an overview of the new behaviour 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...

Troubleshooting

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

Exchange 2013

I have been doing some tests with Exchange 2013 to check if the behaviour is the same, but for some reason Exchange doesn’t seem to check my mailbox for quotas...

From the screenshot below, you will see that:

1. Database DB1 has ProhibitSendQuota set to 400MB and IssueWarningQuota to 200MB;

2. My mailbox is using the database’s quota defaults;

3. My mailbox is over the IssueWarningQuota limit with a size of 246MB

4. Exchange has not set the StorageLimitsStatus for my mailbox which should say IssueWarning (if it’s the same as 2007 and 2010).

It was only when I set quota limits at the mailbox level that I started to get warning messages, so I am still trying to understand exactly what is going on with Exchange 2013...

Conclusion

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 ProhibitSendQuota limit is not used, users will never receive a quota message; 

• 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 behaviour regarding quota messages!

Exchange 2010 SP2 Update Rollup 4

"On August 13th 2012, the Exchange CXP team released Update Rollup 4 for Exchange Server 2010 SP2 to the Download Center.

This update contains a number of customer reported and internally found issues. See KB 2706690 - Description of Update Rollup 4 for Exchange Server 2010 Service Pack 2 for more details."

Exchange 2007 SP3 Update Rollup 8

"On August 13th 2012, the Exchange CXP team released Update Rollup 8 for Exchange Server 2007 SP3 to the Download Center.

This update contains a number of customer reported and internally found issues. See KB 2734323 - Description of Update Rollup 8 for Exchange Server 2007 Service Pack 3 for more details."