Troubleshooting mail flow problems in Exchange Server can be a complicated process. There are many factors that can contribute to a slow down in processing and may include messages that are backing up in remote delivery queues due to bad DNS configuration or unintentional third party software settings. As previously discussed in another blog post some messages might be getting backed up in the Messages awaiting directory lookup queue in which case those backed up messages might be due to heavy distribution group expansions or permissions inheritance blocks. It is also possible that messages cannot be received due to a metadata corruption issue.

Some of the ways that the slow down of mail processing is exhibited include:

• Client response is very slow when email status is changed such as when end users change an email’s status from read to unread, or if email items are opened of deleted.
• Messaging Application Programming Interface (MAPI) error messages are generated that include the phrase “Client Operation Failed.”
• Log files in the Mdbdata folder show continuous growth even though very little has actually changed in the public folder resources or the mailbox resources.
• Attempts to improve the speed of processing are unsuccessful such as creating a new folder and moving the contents of the folder, with the slow responsiveness, to the new folder. The move is only temporarily successful as the speed of processing will continue to steadily decrease until the processing matches the previous unacceptable condition.
• Administrators may notice that some folders are more easily accessible than others within the same database and show no slowdown or problems in responsiveness. This uneven distribution of problems and responsiveness can include special folders such as gateway folders like the Mts-in and Mts-out folders.

If users are receiving unexpected non-delivery reports when sending messages then an administrator should review those NDRs to obtain the DSN code that is contained in the non-delivery report. Lookup the DSN code definition and then determine what actions will be needed to correct this error.

As an example, the DSN code 5.1.6, will contain the following message in the output report:

“The user directory attributes, such as homeMDB or msExchHomeServerName, may be missing or corrupted. Troubleshooting: Verify the integrity of the user directory attributes, and then run the Recipient Update Service again to make sure that the attributes that are required for transport are valid.”

For some DSN codes, an administrator might have to determine which records in DNS are consistent.

If your organization is not receiving any messages from the Internet or some users can receive emails while other uses can not then this condition might be due to delays in the email flow. These delays might be caused by reasons which range from poor or limited network conditions to incorrect SMTP configuration settings.

Some troubleshooting steps can include:

1. Issue the “Ping” command from a Command Prompt window to the designated gateway or email server to check for general network health.
2. Verify connectivity over port 25 and other designated SMTP ports to the designated gateway or email server.
3. Verify the SMTP service status to confirm there are no problems.
4. Review any filter settings such as: Sender ID, IMF, Recipient, Connection or Sender.
5. Test the connection between the gateway to the sender address by sending a test email.
6. Review the SMTP proxy settings for any conditions that could cause SMTP traffic to be hindered. 
7. Review the message tracking logs from the sending server through the network onto the destination server to determine where the test email message is getting bottlenecked.
8. Review and confirm that the local domains are correctly registered.

If all of the above steps still do not help isolate the bottleneck then there may be another problem such as too many cached restrictions, back links, and searches are being placed on an individual folder. If an administrator believes this to be the case then they can try the following fix:

Add the Reset Views registry value for either the public or private information store. This change will have to be made in the Registry so please back up the registry before making any changes. More information can be found in the Microsoft Support Article ID 216076 (http://support.microsoft.com/kb/216076).

Additionally, a workaround would be to decrease the Aging Keep Time value for the affected database (either the public or private information store).