Poison Detection und Poison Queue

Seit Exchange 2007 gibt es eine neue "Warteschlange", die idealerweise gar nicht sichtbar oder leer ist aber wenn dort Mails liegen, von vielen Administratoren nicht richtig verstanden wird. Der Name "Poison" sagt es schon: Exchange legt dort Nachrichten ab, die nicht korrekt geroutet werden können und eine Gefahr für das System darstellen. Mit jedem Support Case lernt man mehr und so ist mir auch das genaue Verhalten von Exchange im Bezug auf die Poison Queue klar geworden. Früher hatte ich immer das Problem. dass Replikationsnachrichten von öffentlichen Ordnern dort gelandet sind und ich dann einfach die Poison-Detection temporär abgeschaltet habe. Heute weiß ist, dass das dies keine gut Idee ist, denn im Extremfall werden gar keine Mails mehr geroutet

Warum gibt es die Poison-Queue ?

Das Internet ist ein gefährlicher Raum und wie es bei SQL-Servern und Webservern "Injection"-Angriffsmuster gibt, sind auch Mailserver diversen Gefahren ausgesetzt. Insbesondere wenn die Transportdienste über Agenten um weitere Funktionen (z.B.: Disclaimer, Regeln, Rights Management, Signaturen etc.) erweitert werden und damit Inhalte lesen und verändern. Es ist zwar recht unwahrscheinlich, dass ein MTA letztlich eine Mail oder eine Anlage auf dem Server mit privilegierten Rechten startet, aber ausgeschlossen ist es nicht. Oftmals reicht schon eine falsch formatierte Mail, die eine Weiterverarbeitung unmöglich macht. Solche Mails generieren "Fehler" die von Exchange erkannt werden und nach mehreren Versuchen in der Poison-Queue landen. Sie werden also nicht gelöscht aber stören nicht mehr die Exchange Dienste.

Bitte schalten Sie nie die Poison Detection ab !
Im Extremfall werden dann einfach keine Mails mehr geroutet weil eine defekte Mail permanent Exchange Dienste so stört, dass diese auch keine andere Arbeit mehr durchführen können.

Wie erkennt Exchange solche Mails ?

Die genaue Logik hierzu kenne ich auch nicht, aber anhand einiger Fälle von Mails, die letztlich in der Poison-Queue gelandet sind, kann ich mir ein Stück weit die Arbeitsweise herleiten. Exchange 2007 und höher nutzt dazu anscheinend den Trick, dass nicht der Hauptprozess die Mail verarbeitet, sondern dieser einen eigenen Thread zur Verarbeitung startet und diesen überwacht. Bricht dieser Thread dann ungeplant ab, z.B.: weil die Mail irgendwie defekt ist (es kann aber auch ein Programfehler sein), dann erkennt dies der Hauptprozess.

Immer wenn eine Verarbeitung einen Fehler produziert, wird der Poison-Counter für diese Mail erhöht. Mit der passenden Konfiguration des Eventlogs sehen Sie dies auch als Informationsmeldung im Eventlog.

Normalerweise ist diese Meldung aber nicht sichtbar. Wenn eine Mail aber den Trigger zu oft ausgelöst hat, dann wird sie verschoben und nicht weiter betrachtet. Voraussetzung ist natürlich die aktive Poison Erkennung, welche aber Default wie folgt eingestellt ist

Get-TransportServer | ft name, poison*

Name             PoisonMessageDetectionEnabled           PoisonThreshold
----             -----------------------------           ---------------
SRV01                                     True                         2

Poison-Queue und Eventlogs

Standardmäßig protokolliert Exchange sehr wenig dieser Meldungen im Eventlog. Man muss also schon das Diagnoseprotokoll etwas anheben, um die Fehler zu sehen. Seit Exchange 2007 SP2 ist dies auch über die GUI einfach möglich:

Aktivieren Sie einfach den Eintrag "PoisonMessage" auf Expert. Alternativ geht dies natürlich auch per Powershell, was besonders in Umfeldern mit mehreren Servern sehr effektiv ist:

# Aktivieren
Set-EventLogLevel -Identity MSExchangeTransport\PoisonMessage -Level Expert

# deaktivieren
Set-EventLogLevel -Identity MSExchangeTransport\PoisonMessage -Level Lowest

Mit bislang bekannte Events. Quelle ist "MSExchangeTransport" und Kategorie = "PoisonMessage". Für einige Meldungen habe ich den Link zur OnlineKB von Operation Manager gefunden

EventID Severity Meldung (Beispielhaft)
100001 Warning Poison Count is 2 for the message with RecordID 4711. The message has reached or exceeded the configured poison threshold of 2. After the Microsoft Exchange Transport service restarted, the message was moved to the poison message queue.
100002 Information PoisonCount for the message with the record ID 4711 has been incremented. the new value is 1
10003 Error The transport process failed during message processing with the following call stack: System.InvalidOperationException ....
10004 Warning The processing of the message file c:\pickup\test.eml from the Pickup directory or the Replay directory caused the transport process to fail. The message file c:\pickup\test.eml will be renamed.
http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Exchange&ProdVer=8.0&EvtID=10004&EvtSrc=MSExchangeTransport&LCID=1033
10005 Error The transport process couldn't load poison message information from the registry. Access to the registry failed with the following error: xxxxx
http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Exchange&ProdVer=8.0&EvtID=10005&EvtSrc=MSExchangeTransport&LCID=1033
10006 Error The transport process couldn't save poison message information to the registry. Access to the registry failed with the following error: xxxx
http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Exchange&ProdVer=8.0&EvtID=10006&EvtSrc=MSExchangeTransport&LCID=1033
10007 Error The transport process couldn't remove poison message information from the registry. Access to the registry failed with the following error: %1
http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Exchange&ProdVer=8.0&EvtID=10007&EvtSrc=MSExchangeTransport&LCID=1033

Die Fehler 10005-10007 weisen eher auf ein Konfigurationsproblem hin. Interessant ist hier fast immer der Fehler 10003, welcher in der Beschreibung meist klar das fehlerhafte Modul ausgibt. In vielen Fällen können Sie selbst damit schon schauen, woran es liegt. In einigen Fällen wird eine genauere Analyse aber dem Microsoft Support vorbehalten bleiben.

Ursachen

Aktuell kenne ich nur wenige Ursachen, aber die paar Fehler sind dann doch leicht zu finden:

Wenn Sie weitere Nachrichten in der Poison-Queue finden, dann nutzen Sie einfach das Eventlog, um die Diagnosefunktion so hoch zu stellen, dass Sie die Ursache erkennen und beheben können

Erkennen und Auslösen von Nachrichten

Mails in der Poison-Queue sind nicht verloren. Sie sind einfach nur dort "geparkt" und können einfach wieder in den Mailfluss integriert werden. Das macht natürlich nur Sinn, wenn Sie die Ursache gefunden und behoben haben. Ansonsten landet die Mail umgehend wieder in der Poison Queue.

Die Anzahl der Mails in der Poison Queue kann einfach per Performance Counter abgefragt werden.

Im Exchange Management Pack des Operation Manager ist eine passende Regel enthalten, die Alarm schlägt, wenn der Counter länger als 5 Minuten größer als ist.

Auch über das Nachrichtentracking mit Exchange 2007 ist es einfach möglich, solche Vorgänge zu identifizieren.

Get-MessageTrackingLog -EventId Poisonmessage

Es ist also nicht besonders schwer, diese Fehler zu erkennen oder über eine Meldung im Eventlog zu überwachen. Allerdings ist Monitoring nur bedingt eine Funktion von Exchange und sollte über eine andere Software erfolgen. (Vier-Augen-Prinzip)

Weitere Links

Keywords:Routing Transport Queue Poison