We have an Exchange Server
2003 environment with a
front-end and back-end
infrastructure. There are dedicated
bridgehead servers for incoming and
outgoing email traffic. Symantec Mail
Security 4.6 for Microsoft Exchange is
installed on all our Exchange servers.
Recently, I was troubleshooting another
problem and discovered that one bridgehead server was holding
numerous emails in the SMTP mailbox temporary tables. When the
bridgehead SMTP service was re-started, users notified our Support
Center that they were receiving old
email messages. So, I initiated a call
with Microsoft Product Support Services (PSS). When I was trouble-shooting this problem with PSS, I
discovered that whenever event ID
348 occurred (which has the error
message A message could not be virus
scanned – this operation will be retried
later), email messages became stuck
inside the SMTP mailbox temporary
tables. Although this event came from
Exchange, I later learned that when
Mail Security can’t scan email messages, it logs those events and the
messages are stored in the SMTP
mailbox temporary tables. If you’re
unfamiliar with the SMTP mailbox
and other special Exchange Server
mailboxes, Evan Dodds has done an
exceptional job explaining them in the
three-part “Exchange Special Mailboxes” blog at http://blogs.technet.com/evand/archive/2004/12.aspx.
When email messages are stuck in
SMTP mailbox temporary tables, you
can’t use Outlook or other email
clients to view them. You have to use
a tool called Microsoft Foundation
Classes MAPI (MFCMAPI). The Microsoft article “MFCMAPI demonstrates
MAPI client code” (http://support.microsoft.com/?kb=291794) contains
information about this tool as well as
a link to download it.
MFCMAPI doesn’t have good documentation. So, if you want to look at
what’s inside your SMTP mailbox
temporary tables, follow these steps:
- Download MFCMAPI and copy it
to your Exchange server. Launch the
tool and let it create a MAPI profile for
you. Don’t try to create this profile
manually.
- Select Session and choose Logon
and Display Store Tables.
- Select MBD and choose Get Mailbox Table.
- Enter the name of your Exchange
server and click OK. If you’re checking
a bridgehead server, the next window
will show up quickly because there are
only three mailboxes. If you’re checking a mailbox server, it might take a
long time to open because MFCMAPI
will display all the mailboxes.
- Double-click the SMTP (<Server
Name> (GUID)) mailbox, where Server
Name is the SMTP server’s name.
- Expand the Root Container.
Under the Temp Tables folder, you’ll
see the temporary tables, the number
of which depends on how many
SMTP virtual servers you have on
your SMTP server. They’ll be marked
TempTable#1, TempTable#2, and so
on. Check each table for email messages. You might see messages in the
temporary tables for a short period of
time, but you shouldn’t see any messages sticking around in those tables.
If you do, you might want to call PSS
and discuss the problem. Note that
you should be careful using MFCMAPI
because any items you delete, whether
intentionally or accidentally, will be
permanently deleted.
I worked with PSS and Symantec
representatives to make sure future
email messages didn’t get stuck in the
temporary tables. Following the
instructions in the Symantec article
“Error: ‘A message could not be virus
scanned - this operation will be retried
later.’ Event ID 348” (document ID 2004102615323554), I ended up making
a couple of changes in the registry. Basically, I increased the timeout
period and the number of input
threads available to the Mail Security
process. After the registry changes, I
re-created the Exchange database on
our bridgehead server. Because this
database didn’t have any user mailboxes, I didn’t have any problems.
(Had the problematic Exchange database been on the mailbox server, I
would have given a lot more thought
before deciding to re-create the database.)
Nowadays, whenever I restart the
SMTP service, I always check the
event log for event ID 348 and the
SMTP mailbox temporary tables for
stuck email messages. I haven’t seen
either, so it appears the problem has
been fixed.
—Brian Ko