Henning Uhle

The FIP-FS „Microsoft“ Scan Engine failed to load – Damit wurde ich Neujahr 2022 geweckt. Ich möchte gern ein paar Worte zu dem merkwürdigen Ereignis erzählen. Denn da ist etwas schief gegangen, woran man erstmal gar nicht gedacht hat. Soweit ich das Thema mitbekomme, scheint sich das nun schon wieder erledigt zu haben. Dennoch müssen wir uns ein paar Gedanken zu diesem Vorfall machen. Denn das war schon prekär. Und – mal wieder – handelte es sich um eine Kleinigkeit, die Microsoft verdaddelt hatte.

FIP-FS? Was soll das sein?

Bei FIP-FS handelt es sich laut Microsoft um die Inhaltsüberprüfung, die vom Antischadsoftware-Agent und den Funktionen zur Verhinderung von Datenverlust ausgeführt wird. Dazu gehört die Scan Engine, der eigene Scan-Prozess und der eigene Update-Prozess. Damit kann das Schlimmste verhindert werden, was Malware- und Spam-Angriffe betrifft. FIP-FS ist somit ein integraler Bestandteil von Exchange Server Installationen. Relevant sind hier die Versionen Exchange Server 2016 und 2019.

Ich kann mich daran erinnern, in früheren Jahren haben sie auch so etwas schon gehabt. Microsoft hatte sich irgendwann Sybari Antigen eingehandelt und den Dienst kontinuierlich weiterentwickelt. Im Groben ist daraus dann die Exchange Online Protection geworden. Aber auch für Exchange Server bietet der Dienst Schutz. Es ist praktisch eine Antivirensoftware, die im Exchange Server integriert ist. Und mit dieser gab es nun gewaltige Probleme.

Hilfe! Es ist kein Email-Verkehr möglich!

Ich hatte über Silvester Bereitschaft im Support. Wie ihr wisst, ist das mein Job seit vielen Jahren. Nachdem ja nun mal Silvester war und es im Viertel ziemlich gekracht hatte, habe ich dann vielleicht so gegen 3 Uhr morgens auch geschlafen. Kurz nach 8 klingelte mein Bereitschaftstelefon. Ein Kunde rief an. Er hätte bemerkt, dass sein Exchange Server keine Emails mehr schickt, weder intern noch extern. Und er hatte bemerkt, dass ein Update davor erfolgt ist.

Wie das nun mal in der Bereitschaft ist: Du hast nicht lang Zeit, darüber nachzudenken. Ich hatte ihm gesagt, er soll mir mal zusammenschreiben, was passiert ist und notfalls von einer alternativen Email-Adresse eine Mail an uns als Support schicken. Gemeldet hatte er dann so etwas, was auch Microsoft derzeit angibt:

Log Name: Application 
Source: FIPFS 
Logged: 1/1/2022 1:03:42 AM 
Event ID: 5300 
Level: Error 
Computer: server1.contoso.com
Description: The FIP-FS "Microsoft" Scan Engine failed to load. PID: 23092, Error Code: 0x80004005. Error Description: Can't convert "2201010001" to long.

Wer diesen Blog verfolgt, ahnt schon, dass ich mich sofort an diese Nummer erinnert fühlte. Aber das musste etwas anderes sein. Da es ein Update war, was Microsoft selbst umher schickt, war mein Vorschlag an den Kunden, sofort Microsoft zu involvieren. Gesagt, getan.

Verspäteter Jahr-2000-Bug? Wollt ihr mich veralbern?

Beim Frank Zöchling habe ich dazu etwas gelesen, was mich vom Glauben abfallen lässt: Im Prinzip versucht Microsoft, ein Datum in einen Integer-Wert zu speichern. Da aber der 01.01.2022 vorlag, wurde der Wert letztlich einfach zu groß. So, wie das schon beim Jahreswechsel 1999/2000 angenommen wurde. Nur kam das halt jetzt, weil jetzt der Wert zu groß wurde. Der FIP-FS meldet das sogar im Eventlog. Nämlich oben mit der Fehlermeldung.

Aber mal ganz ehrlich unter uns Gebetsschwestern: Das hätte man nicht vorhersehen können? Ist der Jahreswechsel einfach so vom Himmel gefallen? Ich tippe mal darauf, dass man hier Vorkehrungen hätte treffen können. Da das Antimalware-Feature im Exchange Server standardmäßig aktiviert ist, dürften recht viele Exchange-Administratoren an Neujahr aus dem Bett gefallen sein. Denn der Umstand brachte eben das Feature und den dazugehörigen Malware Agent aus dem Tritt, was dann dafür sorgte, dass die Emails in den Warteschlangen festhingen.

Und wie kommt man nun wieder aus der Nummer heraus?

Zurück zu meinem Kunden: Ich bin nun am Neujahrsmorgen Microsoft auf die Nerven gegangen. Ich habe ein Ticket eröffnet und das dann als „Critical Situation“ einstufen lassen. Normalerweise fummle ich immer erst mit den Kunden herum, bevor ich Microsoft kontaktiere. Aber ich konnte mir halt so gar keinen Reim auf den Fehler und das Fehlerbild machen. Deshalb der direkte Kontakt zu Microsoft.

Jedenfalls hatte der Kunde weiter geforscht. Und während ich auf die Kontaktaufnahme durch Microsoft gewartet habe, habe ich auch mal geforscht. Wir beide – der Kunde etwas eher als ich – sind dann auf so Diskussionen gestoßen, die eine Lösung der misslichen Situation verhießen. Der Ali Ajran hatte dazu als erstes etwas stichhaltiges und hat seinen Artikel kontinuierlich ausgebaut zu einer echten Lösung. Als Workaround können wir so etwas annehmen:

1. Läuft der Malware-Agent? Befehl: Get-TransportAgent
2. Bei „True“ bleiben die Mails in den Warteschlangen
3. Dann rufen wir Scripts-Verzeichnis das Script zum Deaktivieren des Agents auf. Befehl:
   & $env:ExchangeInstallPath\Scripts\Disable-AntimalwareScanning.ps1
4. Nun muss der Transportdienst noch neugestartet werden. Befehl: Get-Service MSExchangeTransport | Restart-Service

Danach sollten sich die Warteschlangen nach und nach entleeren und der Email-Verkehr wieder möglich sein. Aber Achtung: Damit ist kein Malware-Scanning mehr möglich. Das Ganze sollte also wirklich nur für den Übergang gelten. Der Ali hat aber in seinem Artikel noch eine Lösung angeboten. Die betrifft ein Script namens ResetScanEngineVersion.ps1. Das steht alles in seinem Artikel, den ich oben verlinkt habe.

Und wie geht das weiter?

Microsoft hat zwischenzeitlich zugegeben, dass ihnen da ein Fehler passiert ist. Der FIP-FS wird wohl vorerst diese blöden Fehler werfen, wenn man ihn nicht deaktiviert. Sie arbeiten an einem neuen Update und werden uns wohl dieser Tage damit beglücken. Hoffen wir dabei aber mal, dass uns der FIP-FS nicht gleich wieder um die Ohren fliegt. Meinem Kunden hatte Microsoft den eigenen Lösungsartikel angeboten.

Und dann stolpere ich nun über einen weiteren Lösungsartikel von Microsoft. In diesem ist die Lösung von Ali geschildert. Jetzt können wir uns lange darüber unterhalten, wer das nun zuerst hatte. Jedenfalls ist klar: Wenn Exchange Server 2016 oder 2019 in diesen Zustand versetzt werden, wird zwar erstmal FIP-FS deaktiviert und der Malware Agent zurückgesetzt. Aber die Installation ist vorbereitet, damit beim nächsten Update-Versuch weniger kaputt geht.

Im verlinkten zweiten Artikel von Microsoft steht auch die Ankündigung für das neuerliche Update, und sie streuen sich Asche aufs Haupt:

We expect to have this update to you shortly along with the actions required by you. We are sorry for any inconvenience that this issue has caused.

(The Exchange Team)

Hoffen wir, dass diese missliche Situation dann damit aus der Welt ist. So muss nicht unbedingt ein Jahr anfangen, oder? Unser Kunde jedenfalls kann erstmal weiterarbeiten. Sie hatten nämlich über das Neujahrs-Wochenende eigentlich was anderes vor. Und das Update werden sie wohl dann im Auge behalten, wenn es denn kommt.