{"id":261091,"date":"2022-01-02T00:01:00","date_gmt":"2022-01-01T23:01:00","guid":{"rendered":"https:\/\/www.borncity.com\/blog\/?p=261091"},"modified":"2022-01-03T00:30:49","modified_gmt":"2022-01-02T23:30:49","slug":"microsoft-besttigt-exchange-year-2022-problem-fip-fs-scan-engine-failed-to-load-1-jan-2022","status":"publish","type":"post","link":"https:\/\/borncity.com\/blog\/2022\/01\/02\/microsoft-besttigt-exchange-year-2022-problem-fip-fs-scan-engine-failed-to-load-1-jan-2022\/","title":{"rendered":"Microsoft bestätigt Exchange Year 2022 Problem FIP-FS Scan Engine failed to load (1. Jan. 2022)"},"content":{"rendered":"

[English<\/a>]Weltweit haben (On-Premises) Exchange Server seit dem 1. Januar ein Year 2022 Problem, weil Mails wegen eines \"Datumsfehlers\" nicht mehr transportiert werden. Inzwischen hat Microsoft diesen Sachverhalt in einem separaten Blog-Beitrag best\u00e4tigt. Die Entwickler arbeiten an einem Fix, der zeitnah ausgerollt werden soll. Erg\u00e4nzung: Microsoft hat vorl\u00e4ufige Fixes vorgestellt.<\/p>\n

<\/p>\n

Das Exchange Year 2022 Problem<\/h2>\n

\"\"Das Jahr 2022 fing f\u00fcr Administratoren von Exchange Servern (On-Premises) mit einem fetten Year 2022 Problem an, weil Mails wegen eines \"Datumsfehlers\" nicht mehr transportiert werden k\u00f6nnen. Die Microsoft Scan Engine FIP-FS kann nicht geladen werden – und in den Protokollen findet sich das Ereignis:<\/p>\n

The FIP-FS \"Microsoft\" Scan Engine failed to load. PID: 39268, Error Code: 0x80004005. Error Description: Can't convert \"2201010003\" to long. \/ Event ID 5300<\/p><\/blockquote>\n

Hintergrund ist mutma\u00dflich, dass ein in einem signed long Integer codierter Datumswert mit 2022 einen \u00dcberlauf erzeugt, der dann den obigen Fehlerabbruch bedingt. Der Workaround besteht darin, den Malware-Scan bzw. die Malware-Filterung tempor\u00e4r auszusetzen. Ich hatte ja hier im Blog den Beitrag Exchange Year 2022 Problem: FIP-FS Scan Engine failed to load \u2013 Can't Convert \"2201010001\" to long (1.1.2022)<\/a> mit zus\u00e4tzlichen Erl\u00e4uterungen dazu ver\u00f6ffentlicht.<\/p>\n

Mein deutschsprachiger Blog-Beitrag und das englischsprachige Pendant war wohl weltweit der Erste, der das Problem samt Workaround zusammen fasste. Die Beitr\u00e4ge wurden binnen 12 Stunden gut 29.000 Mal abgerufen – und inzwischen habe ich bei heise das Thema auch kurz untergebracht<\/a> – wobei dort mutma\u00dflich keine Betroffenen mitlesen – den Schluss ziehe ich, wenn ich die Kommentare zum Artikel verfolge.<\/p><\/blockquote>\n

Auf Twitter gab es auch die Diskussion<\/a>, dass der 2021 neu eingef\u00fchrte Microsoft Exchange Emergency Mitigation Service<\/em> (siehe Exchange Server September 2021 CU kommt zum 28.9.2021 mit Microsoft Exchange Emergency Mitigation Service<\/a>) eigentlich eine automatische Korrektur durch Microsoft erm\u00f6glichen sollte.<\/p>\n

\"Exchange<\/a><\/p>\n

Die Bereitstellung einer solchen L\u00f6sung ben\u00f6tigt aber Zeit, wie nachfolgend durch Microsoft erl\u00e4utert wird.<\/p>\n

Microsoft best\u00e4tigt den Bug<\/h2>\n

Blog-Leser DW weist in diesem Kommentar<\/a> (danke daf\u00fcr) auf den inzwischen von Microsoft ver\u00f6ffentlichten Techcommunity-Beitrag Email Stuck in Transport Queues<\/a> hin. Dort hei\u00dft es, dass sich Microsoft sich eines Problems bewusst sei, das dazu f\u00fchrt, dass Nachrichten in den Transportwarteschlangen von Exchange Server 2016 und Exchange Server 2019 stecken bleiben. Dass dies meinen Informationen nach auch Exchange Sever 2013 betrifft, wird nicht erw\u00e4hnt.<\/p>\n

Das Problem bezieht sich auf einen Fehler bei der Datums\u00fcberpr\u00fcfung zum Jahreswechsel und nicht auf einen Fehler der AV-Engine selbst. Es handelt sich nicht um ein Problem mit dem Malware-Scanning oder der Malware-Engine, und es ist kein sicherheitsrelevantes Problem. Die Versionspr\u00fcfung der Signaturdatei f\u00fchrt zu einem Absturz der Malware-Engine, was dazu f\u00fchrt, dass die Nachrichten in den Transportwarteschlangen stecken bleiben. Also das, was ich vor einigen Stunden im oben verlinkten Blog-Beitrag beschrieben habe.<\/p>\n

Microsoft arbeitet an der Behebung dieses Problems. Man will voraussichtlich im Laufe des Tages (beim Schreiben des Texts war dies noch nicht der Fall) Details zur L\u00f6sung dieses Problems ver\u00f6ffentlichen.<\/p>\n

In der Zwischenzeit schl\u00e4gt Microsoft vor, Malware-Scans von Nachrichten au\u00dferhalb des lokalen Exchange-Servers (z. B. durch Weiterleitung von E-Mails \u00fcber Exchange Online oder durch Verwendung einer Nachrichtenhygienel\u00f6sung eines Drittanbieters) durchzuf\u00fchren, oder die Malware-Scans auf betroffenen Exchange-Servern zu deaktivieren und die Transportwarteschlangen zu l\u00f6schen. Microsoft schreibt aber, dass man eine dieser Umgehungsl\u00f6sungen nur dann verwenden sollte, wenn Administratoren einen anderen Malwarescanner f\u00fcr E-Mails als die Engine in Exchange Server einsetzen. Weitere Informationen zum Deaktivieren oder Umgehen von Malware-Scans finden Sie in den folgenden Artikeln:<\/p>\n