Exch07 - Large attachment got around limits, killed servers
I'm in the middle of performing a migration from one Exchange 07 server to another 07 server. Both are setup as closely as possible in terms of roles (Mailbox, Hub Transport, CAS, UM) with similar settings. Most of the users are still on the old server, some have been migrated to the new one.
There is a limit of 20MB for attachments set in Organizational Configuration-Hub Transport-Global Settings-Transport settings. In Server Configuration-Hub Transport-Recieve connectors for both servers, the same limit is in place as well.
Yesterday, a user tried to email a 800MB video file. Even though they got a non-delivery report saying the attachment was too large, it seems Exchange still attempted to process it. Some of the symptons we saw included:
* An error email from Forefront saying it could not scan the message
* Users reporting emails from various sources not getting through (the first reported incident was scanned documents from multi-functions not being recieved)
* Our helpdesk website was generating "insufficient resources" errors
* Noone could send email, the items just sat in the outbox.
* The edgetransport.exe process was using higher than normal CPU
Steps taken after the incident was reported:
* Looked up the "insufficnet resources" error, which suggested not enough disk space for the queue. Both servers had more than enough space.
* The event log had entries relating to resource pressure increase for the Version Buckets, as well as the Hub Transport service not responding.
* Reviewed the mail queues and found them backing up
* Reviewed the message logs and found entries relating to the cause, with interaction between both servers in these entries
We found that there were 2 emails with very large attachments, with the details matching the error emails generated by Forefront. After deleting them, service appeared to return to normal.
Is there anything I missed in the configuration of the server? The NDR email suggests the attachment limits, but the message log entries and the resulting problems suggest that it didn't work properly. Any ideas, suggestions, etc would be appreciated. Thanks.
There is a limit of 20MB for attachments set in Organizational Configuration-Hub Transport-Global Settings-Transport settings. In Server Configuration-Hub Transport-Recieve connectors for both servers, the same limit is in place as well.
Yesterday, a user tried to email a 800MB video file. Even though they got a non-delivery report saying the attachment was too large, it seems Exchange still attempted to process it. Some of the symptons we saw included:
* An error email from Forefront saying it could not scan the message
* Users reporting emails from various sources not getting through (the first reported incident was scanned documents from multi-functions not being recieved)
* Our helpdesk website was generating "insufficient resources" errors
* Noone could send email, the items just sat in the outbox.
* The edgetransport.exe process was using higher than normal CPU
Steps taken after the incident was reported:
* Looked up the "insufficnet resources" error, which suggested not enough disk space for the queue. Both servers had more than enough space.
* The event log had entries relating to resource pressure increase for the Version Buckets, as well as the Hub Transport service not responding.
* Reviewed the mail queues and found them backing up
* Reviewed the message logs and found entries relating to the cause, with interaction between both servers in these entries
We found that there were 2 emails with very large attachments, with the details matching the error emails generated by Forefront. After deleting them, service appeared to return to normal.
Is there anything I missed in the configuration of the server? The NDR email suggests the attachment limits, but the message log entries and the resulting problems suggest that it didn't work properly. Any ideas, suggestions, etc would be appreciated. Thanks.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.