Exchange meldet „poisoned“: Poison Messages und Quarantäne-Postfächer richtig behandeln

In der Warteschlangenanzeige steht plötzlich „Poison“ mit einer Nachricht darin, oder ein einzelner Benutzer kommt nicht mehr an sein Postfach, während alle anderen normal arbeiten. Beides ist kein Zufall, sondern ein Schutzmechanismus von Exchange. Dieser Beitrag zeigt, was dahintersteckt, wie Sie die betroffenen Nachrichten und Postfächer sicher bearbeiten und wie Sie die eigentliche Ursache finden.

Was „poisoned“ bei Exchange bedeutet

Exchange isoliert Objekte, die einen seiner Prozesse wiederholt zum Absturz bringen. So bleibt der Rest des Systems verfügbar. Es gibt zwei Varianten, die völlig unterschiedlich behandelt werden:

Eine Poison Message entsteht, wenn EdgeTransport.exe bei derselben Nachricht wiederholt abstürzt. Nach Erreichen des Schwellenwerts (Standard: 2 Abstürze) landet sie angehalten in der Warteschlange „Poison“. Dort bleibt sie ohne Ablaufzeit, bis ein Administrator entscheidet.

Ein Quarantäne-Postfach entsteht, wenn Zugriffe auf ein bestimmtes Postfach den Store-Worker wiederholt abstürzen lassen. Standardmäßig geschieht das nach 3 Abstürzen innerhalb von 2 Stunden. Exchange sperrt das Postfach dann für 24 Stunden und gibt es danach automatisch frei. Ist die Ursache bis dahin nicht beseitigt, folgt die nächste Quarantäne.

Sofortmaßnahmen

1. Feststellen, welche Variante vorliegt: Poison-Warteschlange oder Quarantäne-Postfach.
2. Prüfen, ob der Transportdienst stabil läuft. Eine Absturzschleife hat Vorrang vor einzelnen Nachrichten.
3. Betroffene Nachrichten exportieren, bevor irgendetwas gelöscht oder freigegeben wird.
4. Nachrichten nicht vorschnell freigeben, denn sie können den Dienst sofort wieder abstürzen lassen.
5. Das Anwendungsprotokoll zum Zeitpunkt der Abstürze sichern.
6. Auf Muster bei Absender, Betreff und Anhängen achten. Mehrere Poison Messages vom selben Absender sind ein Angriffsverdacht.

Poison-Warteschlange bearbeiten

1. Anzeigen

Zuerst alle Server auf eine nicht leere Poison-Warteschlange prüfen:

Get-ExchangeServer | Where-Object { $_.ServerRole -match "Mailbox|Edge" } |
    ForEach-Object { Get-Queue -Server $_.Name -ErrorAction SilentlyContinue } |
    Where-Object { $_.Identity -like "*\Poison" } |
    Format-Table Identity, MessageCount -AutoSize

Get-Message -Queue "EX01\Poison" |
    Format-List Identity, FromAddress, Recipients, Subject, Size, DateReceived, LastError

Alternativ öffnen Sie die Warteschlangenanzeige in der Exchange Toolbox und filtern auf die Warteschlange „Poison“.

2. Sichern

Nachrichten in der Poison-Warteschlange sind bereits angehalten und lassen sich direkt als .eml exportieren:

$Ziel = "C:\Temp\Poison_$(Get-Date -Format yyyyMMdd_HHmm)"
New-Item $Ziel -ItemType Directory -Force | Out-Null

Get-Message -Queue "EX01\Poison" | ForEach-Object {
    $name = ($_.InternetMessageId -replace '[<>:\\/\*\?"|]', '_')
    if (-not $name) { $name = "Msg_" + $_.Identity.InternalId }
    $exp  = Export-Message -Identity $_.Identity
    [System.IO.File]::WriteAllBytes("$Ziel\$name.eml", $exp.FileData)
}

3. Analysieren

Eine .eml-Datei ist reiner MIME-Text. Auf diese Punkte sollten Sie achten:

• extrem lange oder ungewöhnlich viele Kopfzeilen
• tief verschachtelte multipart-Teile oder fehlerhafte Boundary-Angaben
• ungültige Charset-Angaben
• beschädigte Anhänge
• auffällige Kalenderelemente

Die Nachrichtenverfolgung zeigt, wann und wo die Nachricht als Poison Message markiert wurde:

Get-ExchangeServer | Get-MessageTrackingLog -EventId POISONMESSAGE -Start (Get-Date).AddDays(-7) -ResultSize Unlimited |
    Format-Table Timestamp, ServerHostname, Sender, MessageSubject -AutoSize

4. Freigeben oder löschen

Resume-Message -Identity "EX01\Poison\81604378566"
Remove-Message -Identity "EX01\Poison\81604378566" -WithNDR $false -Confirm:$false

Quarantäne-Postfächer bearbeiten

1. Erkennen

Get-MailboxDatabase -Status | ForEach-Object { Get-MailboxStatistics -Database $_.Name } |
    Where-Object { $_.IsQuarantined } | Format-Table DisplayName, Database -AutoSize

Get-MailboxStatistics "max.mustermann@firma.de" |
    Format-List IsQuarantined, QuarantineDescription, QuarantineLastCrash, QuarantineEnd

2. Reparieren

Eine Quarantäne hat fast immer einen logischen Defekt im Postfach als Ursache. Lassen Sie die Online-Reparatur zuerst nur prüfen und erst im zweiten Lauf reparieren:

New-MailboxRepairRequest -Mailbox "max.mustermann@firma.de" `
    -CorruptionType SearchFolder, AggregateCounts, ProvisionedFolder, FolderView -DetectOnly

Get-MailboxRepairRequest -Mailbox "max.mustermann@firma.de" |
    Format-List Status, CorruptionsDetected, CorruptionsFixed

# Reparatur ausführen (ohne -DetectOnly), danach Quarantäne aufheben
New-MailboxRepairRequest -Mailbox "max.mustermann@firma.de" `
    -CorruptionType SearchFolder, AggregateCounts, ProvisionedFolder, FolderView
Disable-MailboxQuarantine -Identity "max.mustermann@firma.de"

3. Verschieben, wenn die Reparatur nicht reicht

Beim Verschieben in eine andere Datenbank baut Exchange das Postfach neu auf und lässt defekte Elemente aus:

New-MoveRequest -Identity "max.mustermann@firma.de" -TargetDatabase "DB02" -BadItemLimit 50
Get-MoveRequestStatistics "max.mustermann@firma.de" | Format-List Status, PercentComplete, BadItemsEncountered

Typische Auslöser für eine Quarantäne sind:

• defekte Kalender-Serientermine
• kaputte Posteingangsregeln
• riesige Ordner
• fehlerhafte ActiveSync-Geräte
• beschädigte Daten aus PST-Importen

Fehlersuche: die Ursache finden

Ereignisprotokoll

Get-WinEvent -FilterHashtable @{ LogName = "Application"; ProviderName = "MSExchange Common"; Id = 4999 } -MaxEvents 20 |
    Format-List TimeCreated, Message

Steht im Watson-Bericht der Name eines Drittanbieter-Agenten, ist der Schuldige meist schon gefunden.

Patchstand

Ein veralteter Build ist eine der häufigsten Ursachen. Prüfen Sie ihn mit Get-ExchangeServer | ft Name, AdminDisplayVersion und gleichen Sie ihn mit der aktuellen Buildliste von Microsoft ab. Noch gründlicher ist das Microsoft-Skript HealthChecker.ps1 aus dem CSS-Exchange-Repository. Es prüft auch .NET-Version und Virenscanner-Ausnahmen.

Transport-Agenten

Agenten für Signaturen, Disclaimer, Virenschutz oder Verschlüsselung laufen im Prozess EdgeTransport.exe. Stürzt ein Agent ab, stürzt der ganze Dienst ab. Deaktivieren Sie verdächtige Agenten einzeln und geben Sie danach eine gesicherte Poison Message gezielt frei:

Get-TransportAgent | Format-Table Identity, Enabled, Priority -AutoSize
Disable-TransportAgent -Identity "Name des Agenten" -Confirm:$false
Restart-Service MSExchangeTransport

Für eine genauere Analyse schreibt die Pipeline-Ablaufverfolgung (Set-TransportService -PipelineTracingEnabled $true -PipelineTracingSenderAddress ...) den Zustand der Nachricht nach jedem Agenten auf die Platte. Schalten Sie sie danach sofort wieder ab, denn die Dateien enthalten Nachrichteninhalte im Klartext.

Virenscanner und Ressourcen

Ein Dateiscanner ohne Ausnahmen für die Ordner Queue, Pickup und Replay sowie die Datenbankpfade erzeugt Sperrkonflikte und defekte Nachrichten. Grenzen Sie außerdem Back Pressure ab: Bei Platz- oder Speichermangel nimmt Exchange keine Nachrichten mehr an. Für Benutzer sieht das ähnlich aus, hat aber nichts mit Poison Messages zu tun.

Angriff ausschließen

Nachrichten, die den Transportdienst gezielt abstürzen lassen, sind ein bekannter Weg für Denial-of-Service-Angriffe. Sie können außerdem auf eine ausnutzbare Schwachstelle hinweisen. Bei Mustern im Absender sperren Sie die Domäne sofort, sichern die Nachrichten als Beweis und prüfen, ob ein Sicherheitsupdate aussteht:

New-TransportRule -Name "BLOCK Poison-Absender" `
    -FromAddressMatchesPatterns "@angreifer-domain\.tld$" `
    -RejectMessageReasonText "Nachricht abgelehnt" -StopRuleProcessing $true -Priority 0

Typische Fallstricke

• Alles auf einmal freigeben: Der Dienst gerät sofort in die nächste Absturzschleife.
• Löschen ohne Export: Danach ist keine Ursachenanalyse mehr möglich, und bei einem Angriff fehlt der Beweis.
• Poison-Erkennung abschalten oder den Schwellenwert erhöhen: Dann reicht eine einzige defekte Nachricht, um den gesamten Mailfluss des Servers zu stoppen.
• Quarantäne ohne Reparatur aufheben: Beim nächsten Zugriff stürzt der Store-Worker ab, und alle Benutzer der Datenbank sind kurz betroffen.
• Zu kleines Anwendungsprotokoll: Die entscheidenden Absturzereignisse sind schon überschrieben, wenn man nachsehen will.

Fazit

Die Poison-Warteschlange und Quarantäne-Postfächer schützen Exchange davor, dass ein einzelnes defektes Objekt den ganzen Server lahmlegt. Der richtige Ablauf ist immer derselbe: sichern, analysieren, Ursache beheben und erst dann freigeben oder löschen. Ein aktueller Patchstand, saubere Virenscanner-Ausnahmen und wenige, gepflegte Transport-Agenten verhindern die meisten Fälle. Eine stündliche Prüfung auf Poison Messages und Quarantäne-Postfächer sorgt dafür, dass Sie es merken, bevor sich ein Absender beschwert.