Archive | April 2013

Exchange 2010 Journaling: Stuck messages in Submission queue

Update: This appears to be a documented bug in  KB2681250
However, the KB notes that it should be patched as of SP2 RU3 and it still appears to be an issue in SP3.  Opening support case now.

Further update: Looks like this is a distinct bug from the reported on in the above KB.  Scheduled to be patched in SP3 RU3.  Specifically, my issue seems to deal mostly with meeting invite replies (Accepted/Declined, etc.)

There’s an issue that appears to pop up periodically with Exchange Journaling which annecdotally, is due to having a BES server attached to your Exchange environment or  if a user has a broken signature in the Outlook client.  It appears some or all of these messages are Calendaring responses with a subject like “Accepted: Meeting Name” or “Declined: Meeting Name”

Messages get stuck in “Retry” in the Submission queue, which shows as an Event 9213 in the Application log:

Log Name: Application
Source: MSExchangeTransport
Date: <date>
Event ID: 9213
Task Category: Categorizer
Level: Error
Keywords: Classic
User: N/A
Computer: <servername>
A non-expirable message with the Internal Message ID 12345678 could not be categorized. This message may be a journal report or other system message. The message will remain in the queue until administrative action is taken to resolve the error. Other messages may also have encountered this error. To further diagnose the error, use the Queue Viewer or the Exchange Mail Flow Troubleshooter.

Looking at the message info it shows:

Last Error: 400 4.4.7 The server responded with: 550 5.6.0 M2MCVT.StorageError; storage error in content conversion. The failure was replaced by a retry response because the message was marked for retry if rejected.

A note about the line “The server responded with: 550 5.6.0…”  This appears to be the local Exchange server, not the intended destination server.  In context, since the message is in the “Submission” queue and not in one of the destination queues, that makes sense.

Without a way to specifically stop the messages, they can at least be manually removed from the queue using:

Get-Message -Server <servername> -Filter {FromAddress -eq "<>" -and Status -eq 'Retry'} | Remove-Message

Note, the second part of the filter “Status -eq “Retry”.  Normal Journaling messages also fly by with blank from addresses and this avoids removing any of those.