Most Ongoing store.exe calls are waiting for a response from IMAIL
Topic Last Modified: 2006-07-13
The Microsoft® Exchange Server Analyzer Tool examines the Exchange Server Function Call Log (FCL), the Store.fcl file, for events that indicate a predominance of ongoing cross-component calls from the Microsoft Exchange Information Store service (Store.exe) to the IMAIL component of the MAPI client.
Ongoing calls are requests from the Microsoft Exchange Information Store service (Store.exe) to other components that have not received a response at the time the Exchange FCL data is written to the Store.fcl file.
The IMAIL component of Exchange Server is a flexible conversion service that is used by the Microsoft Exchange Information Store service between Internet and MAPI messages. This allows for interoperability between clients that use RFC-822 or Internet format and clients that use the Exchange Server internal storage format, such as MAPI clients or internal STORE tasks.
Exchange uses the IMAIL mechanism to apply message formats to the content, as defined for Internet domains in Exchange System Manager or as specified by the user per recipient in Microsoft Office Outlook®. If no formatting parameters are passed to IMAIL, IMAIL formats MAPI messages in Summary TNEF (S/TNEF) format for transfer between servers.
If the Exchange Server Analyzer finds events in the Store.fcl logging file that reflect a predominance of ongoing calls from the Microsoft Exchange Information Store service (Store.exe) to the IMAIL component of the MAPI client, the Exchange Server Analyzer displays an error.
When cross-component calls from the Microsoft Exchange Information Store service (Store.exe) wait for a response, remote procedure call (RPC) threads can back up behind these requests and lead to Exchange Server performance issues such as delays in server responses to clients.
Ongoing calls from the Microsoft Exchange Information Store service to the IMAIL component of the MAPI client can occur when one or more of the following conditions are true:
IMAIL tries to process much data in a message or attachment.
Many clients request data conversion.
- DSAccess requests encounter a slow response.
There are bottlenecks on the TEMP and TMP drives.
There are ongoing mailbox moves.
To resolve this error, take the following steps:
Schedule any mailbox moves for off-peak hours.
Run the Exchange Server Analyzer for an additional analysis of server issues such as message and attachment size limits. You can download the Exchange Server Analyzer at "Microsoft Exchange Server Best Practices Analyzer Tool v2.7" (http://go.microsoft.com/fwlink/?LinkId=34705).
Review the articles in the For More Information section of this document.
For more information about disk bottleneck issues with Exchange Server, see Disk Bottleneck Detected.
For more information about how to size and optimize disks for Exchange Server, see "How to Calculate Your Disk I/O Requirements" and "Best Practices Common to Multiple Architectures" in Optimizing Storage for Exchange Server 2003 (http://go.microsoft.com/fwlink/?linkid=49324).
For more information about best practices for message size limits on Exchange Server, see Maximum outgoing message size has not been set.
For more information about DSAccess and Exchange Server performance, see "How to Configure the DSAccess User Cache" in the Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576).
For more information about how to troubleshoot Exchange Server performance issues, see "Troubleshooting Microsoft Exchange Server Performance" (http://go.microsoft.com/fwlink/?LinkId=47588).
For more information about how to troubleshoot information store performance, see Microsoft Knowledge Base article 257725, "XADM: How to Collect Diagnostic Data for Information Store Troubleshooting" (http://go.microsoft.com/fwlink/?LinkId=3052&kbid=257725).