Das Blockieren von Werbung entzieht uns die Finanzierung!
Das Recherchieren und Verfassen von Artikeln kostet viel Zeit. Das Betreiben unserer Infrastruktur kostet Geld.
All das wird mit Werbeeinnahmen finanziert.
Wir mögen Werbung ebenso wenig – deswegen verzichten wir auf nervige Banner und Pop-Ups.
Bitte gib uns eine Chance und deaktiviere Deinen Adblocker!
Alternativ kannst Du uns hier freiwillig unterstützen.
>> Zeig uns Dein Talent – wir suchen Dich! <<

Sprache:  Deutsch English (Beta)

Folgen:

Exchange Server 2016/2019: E-Mail-Empfang und -Versand seit Neujahr gestört [Lösung]

Microsoft Exchange Server
Bild: Microsoft
(Beitragsbild: © 2021 Microsoft)

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.

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.“

Microsoft Exchange-Server E-Mail Bug 2022

Gutes neues Jahr … mit einem Exchange-Problem. (Bild: TechnikNews/Screenshot)

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).

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).

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!

Empfehlungen für Dich

>> Unterstütze uns durch den Kauf über unsere Partner <<

David Wurm

Macht das TechnikNews-Ding gemeinsam mit einem tollen Team schon über einige Jahre lang. Werkelt im Hintergrund an der Server-Infrastruktur und ist auch für alles redaktionelle zuständig. Ist an der aktuellen Technik fasziniert und bloggt gerne über alles Digitale. Ist sonst in der Freizeit oftmals beim Webentwickeln, Fotografieren oder Radiomachen anzutreffen.

David hat bereits 842 Artikel geschrieben und 347 Kommentare verfasst.

Web | Facebook | Twitter | Insta | YouTube
Mail: david.wurm|at|techniknews.net | bitte NICHT für allgemeine Anfragen, Kooperationen! Hier lang: Kontakt
guest
Dein Name, der öffentlich angezeigt wird.
Wir werden Deine Mailadresse nicht veröffentlichen.
15 Comments
neueste
älteste beste
Inline Feedbacks
View all comments
OKI

Well done.

Saved my day.

Rolf Dau

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.

Rolf Dau

Hallo David,
ich habe ein Problem das Skripts wird nicht ausgeführt obwohl ich es Administrator. Wo kann der Fehler liegen?

Rolf Dau

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.

Jimly

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….

Nils

Vielen Dank für die schnelle Veröffentlichung!

Stefan

Vielen Dank für die schnelle Veröffentlichung, das hat viel Zeit und suchen gespart. Echt TOP.

Monika

danke danke – wir haben es bei uns nun auch hinbekommen ich habe schon die Krise bekommen 🙂

Paul Winzinger

Danke, danke, danke für diesen Artikel!!!! Wochenende ist gerettet!