Large Messages Affect Server Performance
I recent months we have seen issues where users (knowingly or unknowingly) send messages with LARGE attachments (500+mb.) Unfortunately this has huge impact on the server's performance, typically causing message queues to backup and general client sluggishness. I wanted to point on some of the things going on behind the scenes and what can proactively done about it and what we are doing about it...
When a client submits a message the message either lives in memory or is temporarily saved to the Drafts folder depending upon timing. When a user generates a message and attaches a large file to it, the attachment begins streaming to the server. It is only when that process is done and the message is sitting in the drafts folder does the message size count against mailbox storage limits. If user is able to generate a message, attach a large file, and then 'SEND' the message before being completely streamed to the server, the message submission attempt is allowed even if the user current mailbox size + the new message size exceeds the user’s storage limits. If the user is configured to save messages in their Sent Items folder and mailbox size limits are in place, the user will likely realize their error when the attempt to send another message since there mailbox is then over the size limit.
When a message is submitted, or sent, a property is stamped on the message by the client indicating the size of the message. The Information Store checks the size of the message against the user's individual maximum message size submission limits. This information is cached when the user first logs on to Exchange and fully refreshed every 2 hours. To adjust the lifetime of the various mailbox caching mechanisms, take a look at the following KB article:
If the message exceeds the individual limit, the Information Store rejects the submission from the client and the client then receives an error message to the affect “This message exceeds the maximum message size limits for this user“. However, when no individual limits are imposed, the message is accepted by the Information Store and placed into the Temp Tables while the message stub information is sent to the Categorizer. When the Categorizer examines the message it looks to see if the message size exceeds the Global Maximum Submission Limit, and if so, creates an NDR message and attaches the original, large message, to the NDR. This process in essence generates a new message containing the old message. The NDR is then sent back through the Information Store to the user that originally sent the message.
Currently there is a setting to prevent the NDR process from attempting to attach such a large message:
We are also current working on a Hotfix that changes some behavior during the submission process. With this fix, the Information Store now changes some of the logic of how it maintains limits. As I mentioned above, when a user initially logs on to Exchange, we query information about the user from the Active Directory. If the user has individual message size limits, those limits are cached as part of the user’s logon. If the user does not have individual limits, then we read the Global Maximum Submission Limit value and apply that value to the user’s limits. By making this slight change, we can prevent a large message from being submitted for delivery and clogging the pipes. If in some rare circumstance the Individual Limits are larger than the global limits, the message will be allowed to be ‘Sent’ from the client, but when the message reaches the Categorizer, may still NDR.
More details about this fix are available from the following articles. Note the first article, 830762, is a released fix that starts to address this issue. I minor problem was found after the fix was released that may cause the limits to be reverted when background quotas are refreshed. The final fix correcting that problem should be available in 3 weeks and is referenced by the second article below, which has yet to be released.. You can currently call PSS for the first fix, 830762, however it be likely 3-4 weeks before the final fix (836738) is available.