Exchange Server 2016/2019: E-Mail-Empfang und -Versand seit Neujahr gestört [Lösung]
Was wäre nicht das neue Jahr ohne Probleme bei Microsoft Exchange Servern. Bereits im Jahr 2021 haben Sysadmins oft Nächte mit wichtigen Updates verbracht, heute Nacht mussten wohl viele nach der Silvesterparty ausrücken. Bei zahlreichen Microsoft-Mailservern werden E-Mails seit Neujahr nicht zugestellt und auch nicht mehr versendet.
Update: Microsoft hat mittlerweile eine offizielle Lösung für das Problem zur Verfügung gestellt. Siehe etwas weiter unten in diesem Artikel, unter „Lösung“.
Ab etwa 01:00 Uhr unserer Zeit (bzw. 00:00 Uhr UTC) dürfte es passiert sein – einige Monitorings dürften sich gemeldet haben, dass es Probleme beim Empfang und Zustellen von E-Mails gibt. Dies betrifft die meisten Exchange Server 2016 und 2019. Vorherige Versionen wie 2013 oder gehostete Dienste wie Microsoft 365 bzw. Office 365 sind nicht betroffen. Die Fehlerbehebung davon ist eigentlich ganz einfach, auch wenn das einige Admins sicherlich Stunden zum Herausfinden gekostet haben könnte.
Zum Abschnitt springen
Microsoft Exchange Server 2016/2019 E-Mail-Ausfall: Ein peinlicher Bug ist das Problem
Bereits vor meiner Zeit – im Jahr 2000 – soll es dasselbe Problem gegeben haben. Eingefleischte Admins dürften also heute ihr Déjà-vu erleben. Das Problem ist ein eigentlich richtig peinliches – das Datum, gemeinsam mit der Uhrzeit ist zu lang, um es als Int32 korrekt parsen zu können. Nerds wissen sicherlich, dass der Wertebereich dessen zwischen -2.147.483.648 und 2.147.483.647 liegt, somit liegt 2.201.010.001 natürlich außerhalb dieses Bereichs. Wieso man überhaupt ein Datum, gemeinsam mit der Uhrzeit in ein Integer speichert – na ja.
So kommt man dem Problem auf die Spur
Microsoft hat der Filtering Engine nämlich genau zu diesem Zeitpunkt (01.01.2022, 00:01 UTC) ein neues Update zukommen lassen, welches über diesen Integer mit der lokalen Virenfilter-Datenbank abgeglichen wird. Je nachdem, wann das Update nun automatisch heruntergeladen wurde (bei uns gegen 02:16 Uhr, siehe Screenshot), läuft der Mailfluss nicht mehr. Der AntiMalware Scanner kann die E-Mails somit nicht mehr verarbeiten und die Zustellung verzögert sich, auch intern – wenn das MalwareFiltering nicht nur für externe Mails aktiv ist. Absender einer E-Mail an einen Exchange Server dürften damit Fehlermeldungen wie „Remote Server returned ‚400 4.4.7 Message delayed'“ sehen.
Der Event Viewer eines Exchange Servers liefert alle nötigen Informationen. Dabei erscheint folgende Fehlermeldung in den Windows Logs unter Application: „The FIP-FS „Microsoft“ Scan Engine failed to load. PID: 19104, Error Code: 0x80004005. Error Description: Can’t convert „2201010001“ to long.“
Lösung – So werden E-Mails wieder zugestellt
Automatische Behebung mithilfe eines Scripts
Update: Microsoft hat das Problem mittlerweile im Exchange Team Blog bestätigt und stellt eine funktionierende Lösung zur Verfügung.
Zu Beginn muss das ResetScanEngineVersion-Script direkt von Microsoft heruntergeladen werden, um die Versionsnummer zurückzusetzen. Der Durchlauf des Scripts kann aktuell einige Zeit in Anspruch nehmen, da die aktuellen Signaturen des Malwarescanners heruntergeladen werden müssen – der Downloadserver scheint hierbei aktuell sehr überlastet zu sein. Nach dem Download das Script im jeweiligen Ordner mit einer Exchange Management Shell als Administrator ausführen:
.\Reset-ScanEngineVersion.ps1
Hinweis: Bei manchen Nutzern bleiben nach der erfolgreichen Durchführung weiterhin E-Mails hängen. Dies ist in unserem Fall zwar nicht passiert, es empfiehlt sich daher aber ein Neustart des kompletten Servers, wenn der Versand und Empfang von E-Mails weiterhin nicht funktioniert.
Manuelle Lösung
Sollte es mit dem Script Probleme geben, so wie etwa bei unserem Leser Rolf (danke für den Hinweis in den Kommentaren), gibt es auch eine manuelle Möglichkeit, den Fehler zu beheben. Wir unterstützen Euch wie gewohnt dabei.
- Zunächst wird überprüft, ob eine Behebung überhaupt notwendig ist – es wird die Version der Engine überprüft (PowerShell als Administrator öffnen):
Get-EngineUpdateInformation
In manchen Fällen funktioniert dieser Befehl nicht und eine Fehlermeldung wird ausgegeben:
Get-EngineUpdateInformation : The term 'Get-EngineUpdateInformation' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Dann muss zuvor noch das entsprechende SnapIn zur PowerShell hinzugefügt werden. Anschließend den Get-Befehl erneut ausführen (mit PowerShell als Administrator).
- Microsoft PowerShell: Fehler ‚Get-EngineUpdateInformation‘ is not recognized as the name of a cmdlet
Add-PSSnapin Microsoft.Forefront.Filtering.Management.Powershell Get-EngineUpdateInformation
Startet die UpdateVersion mit „22“, ist eine Behebung notwendig. Bei „21“ hat sich der Server – zum Glück – noch keine aktuellen Virendatenbanken heruntergeladen und es sind keine Änderungen notwendig.
- Als Nächstes wird zu den Diensten gewechselt und der Filterverwaltungsdienst gestoppt. Dazu wechselt man zum Startmenü -> services.msc -> Microsoft Filterverwaltungsdienst (Englisch: Microsoft Filtering Management Service) -> „Stop“ auswählen. Sollte gefragt werden, ob der Microsoft Exchange Transport Service auch gestoppt werden soll, dies mit „Ja“ bestätigen. Achtung, der Versand und Empfang von E-Mails wird in dieser Zeit nicht möglich sein.
- Task Manager starten und prüfen, ob der Task „updateservice.exe“ läuft. Falls ja, diesen beenden. Andernfalls geht’s gleich weiter (es empfiehlt sich, die folgenden Dateien & Ordner vorher zu sichern, sollte was schieflaufen):
- Folgenden Ordner löschen: %ProgramFiles%\Microsoft\Exchange Server\V15\FIP-FS\Data\Engines\amd64\Microsoft
- Alle Dateien in diesem Ordner löschen (den Ordner „metadata“ selbst nicht löschen): %ProgramFiles%\Microsoft\Exchange Server\V15\FIP-FS\Data\Engines\metadata
- Microsoft Filterverwaltungsdienst (Englisch: Microsoft Filtering Management Service) unter den Diensten wieder starten
- Sollte der Transport Service nicht automatisch ebenso wieder gestartet werden, diesen auch noch starten
- Exchange Management Shell (als Administrator) öffnen und zu %ProgramFiles%\Microsoft\Exchange Server\V15\Scripts navigieren. Dort folgenden Befehl ausführen:
Update-MalwareFilteringServer.ps1 SERVERNAME
- Sollte der Servername nicht bekannt sein, so kann dies durch folgenden Befehl herausgefunden werden, siehe Spalte „Name“:
Get-ExchangeServer
- Hinweis: Bei manchen Nutzern bleiben nach der erfolgreichen Durchführung weiterhin E-Mails hängen. Dies ist in unserem Fall zwar nicht passiert, es empfiehlt sich daher aber ein Neustart des kompletten Servers, wenn der Versand und Empfang von E-Mails weiterhin nicht funktioniert.
- Alles erledigt! Anschließend mit der Überprüfung der Lösung fortfahren, siehe folgender Teil:
Abschließende Überprüfung der Lösung & (Re-)Aktivierung des Virenscanners
Zur Prüfung der Lösung kann man nun die Versionsnummer abgleichen – Microsoft hat hierbei einfach das Jahr 2021 verlängert und die Versionsnummer (Stand: 02.01.2022) auf den 33. Dezember gestellt (2112330001). PowerShell als Admin öffnen:
Get-EngineUpdateInformation
Engine : Microsoft LastChecked : 01.02.2022 05:45:11 +01:00 LastUpdated : 01.02.2022 05:40:18 +01:00 EngineVersion : 1.1.18800.4 SignatureVersion : 1.355.1227.0 SignatureDateTime : 01.01.2022 12:29:06 +01:00 UpdateVersion : 2112330001 UpdateStatus : UpdateAttemptNoUpdate
In manchen Fällen funktioniert dieser Befehl nicht und eine Fehlermeldung wird ausgegeben:
Get-EngineUpdateInformation : The term 'Get-EngineUpdateInformation' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Dann muss zuvor noch das entsprechende SnapIn zur PowerShell hinzugefügt werden. Anschließend den Get-Befehl erneut ausführen (mit PowerShell als Administrator).
- Microsoft PowerShell: Fehler ‚Get-EngineUpdateInformation‘ is not recognized as the name of a cmdlet
Add-PSSnapin Microsoft.Forefront.Filtering.Management.Powershell Get-EngineUpdateInformation
Sollte die „UpdateVersion“ mit 22 beginnen, lief das Update der Signaturen nicht durch und der MalwareFilteringServer sollte weiterhin nicht genutzt werden, da ansonsten der Durchlauf der E-Mails wieder nicht funktioniert.
Zusätzlicher Schritt für Workaround-Nutzer: Hat man den unten beschriebenen Workaround in den letzten Tagen als Zwischenlösung eingespielt, muss der MalwareFilteringServer mit folgendem Befehl nun wieder aktiviert werden:
Set-MalwareFilteringServer -BypassFiltering $False -identity SERVERNAME
Ist der Servername nicht bekannt, so kann dies durch folgenden Befehl herausgefunden werden, siehe Spalte „Name“:
Get-ExchangeServer
Der Virenscanner ist nun wieder aktiv, ohne dabei Fehlermeldungen anzuzeigen oder den Mailfluss zu stören. Allerdings kann es noch einige Stunden dauern, bis der „UpdateStatus“ von „NoUpdate“ auf „Successful“ schaltet, da die Virendatenbanken meist täglich gegen Mitternacht aktualisiert werden.
Hinweis: Bei manchen Nutzern bleiben nach der erfolgreichen Durchführung weiterhin E-Mails hängen. Dies ist in unserem Fall zwar nicht passiert, es empfiehlt sich daher aber ein Neustart des kompletten Servers, wenn der Versand und Empfang von E-Mails weiterhin nicht funktioniert.
Ursprünglicher Workaround
Hinweis: Dieser Workaround sollte nicht mehr verwendet werden, da Microsoft das Problem mittlerweile durch eine andere Methode löst, siehe oben „Lösung“.
Derzeit muss auf eine Zwischenlösung zurückgegriffen werden, um den Mailfluss wieder zum Laufen zu bekommen. Dieser sollte übrigens noch dieses Wochenende eingespielt werden, da der Exchange Server alle Mails nach 48 Stunden aus der Warteschlange löscht und die E-Mails zurückweist.
Zuerst muss der MailwareFilteringServer deaktiviert oder übergangen (bypassed) werden. Heißt gleichzeitig auch, dass Anhänge von E-Mails nicht mehr auf Viren abgeprüft werden – alle davon abhängigen Checks, wie das Abprüfen von Dateiendungen, laufen ebenso dann nicht mehr. Diese sollten auch deaktiviert werden (sofern welche erstellt wurden), da die Zustellung von E-Mails sich sonst um mehrere Minuten verzögern kann.
Folgenden Befehl führt man in der Exchange Management Shell aus:
Set-MalwareFilteringServer -BypassFiltering $True -identity SERVERNAME
Sollte der Servername nicht bekannt sein, so kann dies durch folgenden Befehl herausgefunden werden, siehe Spalte „Name“:
Get-ExchangeServer
Anschließend sollte der Microsoft Exchange Transport Dienst neugestartet werden, um die Zustellung wieder zu ermöglichen. Die dabei angezeigten Warnings können ignoriert werden, auch wenn sie mehrmals erscheinen.
Get-Service MSExchangeTransport | Restart-Service
Damit ist das Problem vorerst behoben. Die Queue bzw. Warteschlange der ausstehenden E-Mails (einkommend und ausgehend) sollte dann wieder automatisch durchgearbeitet werden. Einfach durch Öffnen der Exchange Toolbox oder Ausführung des folgenden Befehls, kann die Warteschlange genauer begutachtet werden:
Get-ExchangeServer | Get-Queue
Sollte ein entsprechendes Update seitens Microsoft kommen, obenstehende Befehle einfach erneut – aber mit $False – erneut ausführen. In diesem Sinne: Gutes neues Jahr, liebe Exchange-Fans und alle, die es in diesem Jahr noch werden wollen!
Well done.
Saved my day.
Hallo David,
das Skript wird bei mir nicht durchgeführt, da der Exchange Server nicht unter Program Files gefunden wird. Der Server ist unter Programme installiert. Kann man das Skript dementsprechend ändern?
Vielen Dank im Voraus.
Hallo Rolf,
ich habe den Artikel nun zusätzlich um die manuelle Lösungsvariante ergänzt. Außerdem habe ich nun konkretisiert, wann und wo welche Shell (PowerShell als Administrator oder Exchange Management Shell) ausgeführt werden muss. Hoffentlich hilft das weiter! LG David
Hallo David,
ich habe ein Problem das Skripts wird nicht ausgeführt obwohl ich es Administrator. Wo kann der Fehler liegen?
Hallo Rolf,
bekommst du irgendeine Fehlermeldung oder sonstige Hinweise darauf, was schiefläuft? Script liegt heruntergeladen im gewünschten Ordner und mit der Exchange Management Shell (als Admin gestartet) bist du auch im selben Verzeichnis wie das Script? LG David
Hallo David,
Bei der Ausführung des Scripts wird angezeigt, das der Path nicht gefunden werden kann oder verschoben ist. Wenn ich die manuelle Lösung erhalte ich bei den Befehlen die Aussage es ist kein Cmdlet. Leider kann ich dir kein Screenshot schicken.
Mhmm, knifflig. Bekommen wir aber hin. Der Fehler mit dem Cmdlet dürfte nur bei der Ausführung von „Get-EngineUpdateInformation“ passieren, die Lösung des Fehlers haben wir auch oben bereits gezeigt bzw. hier in einem separaten Artikel: https://www.techniknews.net/ratgeber/microsoft-powershell-fehler-get-engineupdateinformation-is-not-recognized-as-the-name-of-a-cmdlet/
Die anderen Dinge sollten eigentlich ohne Fehlermeldung durchlaufen.
Sollte es weiterhin nicht klappen, lade den Screenshot einfach auf einen Bildupload-Dienst (wie bspw. https://picr.eu) hoch und poste den Link hier. Gib mir gern ein Update, ob alles funktioniert!
Danke! hat mir geholfen!
…Und da gibt es Leute die denken im Impfstoff seien Nanoroboter drin – die von MS bekommen ja noch nicht mal einen fehlerfreien Exchange zum laufen….
Vielen Dank für die schnelle Veröffentlichung!
Vielen Dank für die schnelle Veröffentlichung, das hat viel Zeit und suchen gespart. Echt TOP.
Freut mich, geholfen haben zu können! LG, David von TechnikNews
danke danke – wir haben es bei uns nun auch hinbekommen ich habe schon die Krise bekommen 🙂
Super, dass ihr wieder online seid – noch einen schönen Samstag! LG, David von TechnikNews
Danke, danke, danke für diesen Artikel!!!! Wochenende ist gerettet!
Gerne, noch ein schönes Wochenende! 🙂 LG, David von TechnikNews