A client contacted me regarding an issue that an e-mail recipient had brought up. I'm not sure what could be causing this and was hoping someone could give me some ideas..... Myclient reported that a recipient had queried them about just receiving messages, from several senders at the client's business, which were composed two months ago.The users were never alerted about the messages being delayed or not bieng delivered. My client isrunning Windows Server 2003 SBS (I know there is also a SBS forum, but I don't believe that this issue is SBS-specific), with Exchange 2003 SP2. I started troubleshooting by checking the Exchange Message Tracking, which revealed that several messages (from several senders) had been created (shown by the "origination time" back in April and May, but had not been delivered until yesterday. (As I side note, I know that their Exchange services were restarted yesterday for an unrelated reason.) When checking the details of any particular message in the message tracking results, every step of the way (submission to advance queuing, routing, and outbound transfer of message via SMTP) has a timestamp of yesterday's date. I also double-checked theSMTP virtual server'soutbound delivery options, which areshowing defaultretries of 10 minutes andmessage expiration timeout of 2 days. So.... The question is, where did the messages "hide" for two months, why weren't the users notified of delays, and why didn't Exchange expire the messages and give up on sending??? I know that they weren't stuck in Outlook outbox, as this occurred with several users and the messages all transmitted when the Exchange services were restarted. I have also checked the queues and currently they are empty. Thanks for any ideas, Vishnu

Hi Vishnu, Have you checked the SMTP (servername-{guid}) mailbox? SMTP (servername-{guid}) mailbox is used by the mail transport of Exchange 200x as a temporary holding place for various messages as they pass through the system. When a message is processed by Exchange transport, the message remains in one place while passing through the various phases and memory based queues. If the message originates from the SMTP protocol (another Exchange 200x server or the Internet), then as the message comes in, it is written via the NTFS store driver to the mailroot/queue folder while going through categorization & advanced queuing. If the message originates from anywhere else -- MAPI client, OWA, or the MTA, then the message remains in the SMTP mailbox during the same process, in the SMTP mailbox accessible to transport via the Exchange store driver using IFS. Please further information, please refer to the following site: http://support.microsoft.com/kb/906557/en-us http://blogs.technet.com/evand/archive/2004/12/27/332752.aspx Mike

Hi Mike, Thanks for the information on the MFCMAPI tool, I hadn't seen/used it before. At first glance, the tool is a bit daunting... I am assuming that if the SMTP (servername-{guid}) mailbox has any items *stuck* in it, that I would be able to see a count of messages in the Exchange System Manager, under mailboxes. Would that not be the case? I am seeing zero messages in that mailbox and the queues are still empty. I'm still trying to determine how to tell if there are messages in that mailbox, via MFCMAPI. Interestingly enough, I just got notification from this same client that another e-mail composed in April was sent out on Saturday the 14th (Neither servicesnor theserver itself were restarted over the weekend). My client is starting to question if they can trust their Exchange server to deliver business-critical e-mail in a timely manner. It seems that if I can't find any currently hung messages, then I need to wait until the client notices messages being delayed until I can troubleshoot (Assuming that they notice the problem whenit isactually occurring). I can't think of another way to monitor this situation..... Any ideas? Thanks again, Vishnu Mike Shen wrote: Hi Vishnu, Have you checked the SMTP (servername-{guid}) mailbox? SMTP (servername-{guid}) mailbox is used by the mail transport of Exchange 200x as a temporary holding place for various messages as they pass through the system. When a message is processed by Exchange transport, the message remains in one place while passing through the various phases and memory based queues. If the message originates from the SMTP protocol (another Exchange 200x server or the Internet), then as the message comes in, it is written via the NTFS store driver to the mailroot/queue folder while going through categorization & advanced queuing. If the message originates from anywhere else -- MAPI client, OWA, or the MTA, then the message remains in the SMTP mailbox during the same process, in the SMTP mailbox accessible to transport via the Exchange store driver using IFS. Please further information, please refer to the following site: http://support.microsoft.com/kb/906557/en-us http://blogs.technet.com/evand/archive/2004/12/27/332752.aspx Mike

Hi Vishnu, I am afraid that we cannot check the emails stuck in the SMTP mailbox through ESM. We have to view the emails stuck in the SMTP Mailbox Temp table by using MFCMapi. For detailed steps to check whether the old email hangs in the SMTP Mailbox Temp table by using MFCMAPI, you can use the following steps 1. Double-click Mfcmapi.exe. 2. Click OK to close the About Mfcmapi dialog box. 3. Click Session, and then click Logon and Display Stores. 4. Log on by using an Administrator account. If the MAPI profile is unavailable, create one. 5. Click MDB, and then click Get Mailbox Table. 6. Confirm the server name, and then click OK. 7. Double-click the SMTP (ServernameGUID) mailbox. 8. Expand Root Container. 9. Expand TempTable#n. Note: n represents the number that corresponds to the TempTable. The number of which depends on how many SMTP virtual servers you have on your SMTP server. Theyll be marked TempTable#1, TempTable#2, and so on. 10. View subfolders #0 to #19 and check whether any old messages can be located. If some old messages stuck in the Temp folder, please use the steps in my previous KB to remove the TempTable or just remove the old message by using MFCMAPI) Warning: If you delete the SMTP TempTables, all incoming and outgoing messages are cleared from the TempTables at the same time. If there is no old messages stuck in TempTables folder, please also check the SMTP Queue folder (Exchsrvr\Mailroot\vsi #\queue) for old message. Mike

In additin, please also check the Antivirus application to ensure that the SMTP Queue folder andsome otherExchange foldesis in the exclude list of the scanning. For further information: http://support.microsoft.com/kb/823166/en-us Mike

Hi Mike, I hadn't looked at this issue since June 16th, because I hadn't heard from the client reporting that they had seen the issue again. In reviewing my service tickets, I am re-visiting it again. Thanks for the additional instructions on the MFCMAPI tool and the suggestion on excluding the Exchange SMTP queue from the anti-virus scan. I followed your suggestions and used MFCMAPI to look through all of the TempTable folders, but they didn't contain any messages. I also checked the SMTP queue folder, which is empty. The client is using Trend Micro CSM, which excludes the Exchange folders from the real-time and on-demand scans. I double-checked and that option is selected. I guess I'll have to wait to see if this occurs again, I just really don't like the idea that I can't pin down the cause of the issue. If you think of anything else I should look for, please let me know. Thanks.