Handling Poison Messages with Exchange 2007

Sometimes our servers get badly formed messages; they might be malicious, or they might be generated by a buggy Message Transfer Agent. These messages could have a variety of unwanted side effects. I've seen messages that crashed the Exchange Transport or Information Store services, plus many cases where an antivirus or antispam utility pegs the CPU at 100 percent when it encounters a particular message. You've probably encountered the same types of messages in your environment; finding them and getting rid of them can be a tiresome exercise, especially if you have to do it often.

Microsoft developers call these messages poison messages, and they've added a number of features to Exchange Server 2007 to help handle them. The basic definition of a poison message is a message that causes an Exchange transport service to stop more than once. Poison messages are automatically redirected into a separate queue, the poison message queue, on the Hub Transport server.

The poison message queue doesn't exist until it's created to hold one or more poison messages, and messages in the queue don't expire—they stay in the queue until you manually dispose of them. Unfortunately, Exchange doesn't automatically tell you that there are messages in the poison message queue; you can check the length of the queue using the Exchange Management Console (EMC) Queue Viewer or the Exchange Management Shell (EMS) Get-Queue cmdlet. The poison message queue appears only if there are messages in it, so don't be alarmed if you don't see the queue.

When you do see the queue, you've got some work to do. You can't just resume processing of the entire queue. You can, however, process individual messages using the Resume-Message cmdlet. This cmdlet requires the message ID of the message you want to resume. The fastest way to find the ID is with a quick call to Get-Message with the -queue flag, like this:

 get-message -queue:Poison    

This command gives you a list of messages in the queue, which you can then use with Resume-Message. You can also pipe the output of Get-Message to Export-Message to save the messages as files so that you can inspect them yourself. If you find messages that are actually poison, you can remove them with the Remove-Message cmdlet.

Of course, the transport services are never supposed to crash, so any time there are messages in the poison message queue it indicates a software fault either in the services or in the entity that generated the message. In my experience, the biggest source of poison messages is (drum roll, please) . . . Exchange itself. Public folder replication messages seem to end up in the poison message queue much more often than you might expect. I haven't done any detailed analysis to prove this observation or to figure out exactly what the cause is. The popular solution to this situation is to turn off poison message detection with the Set-TransportServer cmdlet; specify -PoisonMessageDetectionEnabled:$false to prevent the Hub Transport service on that machine from putting messages in the poison message queue. This isn't a long-term fix; if you're frequently seeing messages in the poison queue, you need to identify the source of those messages and find a better solution.

Public folder replication is still a confusing subject to many Exchange administrators; I'll be writing more about it in future columns. If you have specific questions, drop me a line at [email protected].