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

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:

• Kategorien in Kontakten in öffentlichen Ordnern
  Exchange 2003 erlaubt das Anlegen von Kontaktordnern in öffentlichen Ordnern, welche bei einer Migration natürlich auch auf das neue System übertragen werden müssen. Dazu bedient sich Exchange selbst entsprechender Replikationsmails, die dann auf dem Zielsystem wieder in den Ordner abgelegt werden. Exchange 2007 und höher sind aber etwas "strenger" bei der Validierung der Inhalte, so dass verschiedene Inhalte nicht auf einem Exchange 2007/2010-Server abgelegt werden können. Der entsprechende Prozess produziert quasi eine "Schutzverletzung" und schon landet die Mail in der Poison-Queue
• Exchange Programmfehler
  Bei einem Support Call dürfte es an einer falschen DLL gelegen haben. Zumindest weist das Eventlog darauf hin, dass "EdgeTransport.exe" eine Ressource in der DLL "Microsoft.Exchange.Store.dll" nicht laden konnte.
  
  Ein Vergleich der Versionsnummern zeigte, dass die Build-Nummer von Exchange und der DLL stark abwichen, so als wäre das ServicePack nicht komplett installiert worden oder eine vorherige Version wieder hergestellt worden. Auch dieser Abbruch führte letztlich zur Ablage der Mails in der Poison Queue

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

• FixCategories
• Pipelinetracing
• Nachrichtentracking mit Exchange 2007
• Understanding Transport Queues
  http://technet.microsoft.com/en-us/library/bb125022.aspx
• Resume-Message
  http://technet.microsoft.com/en-us/library/bb124421.aspx
• Resubmit Messages in Queues
  http://technet.microsoft.com/en-us/library/aa995987.aspx
• Poison Queue Length - sustained für 5 minutes - Yellow(>1) - Edge Transport
  http://technet.microsoft.com/en-us/library/bb217352(EXCHG.80).aspx
• Poison Message Handling
  Achtung: Diese Beschreibung gilt nicht für Exchange aber zeigt die Thematik auch bei WCF
  http://msdn.microsoft.com/en-us/library/ms789028.aspx