[English]Microsoft hat inzwischen einen temporären Fix für das Problem geliefert, dass (On-Premises) Exchange Server seit dem 1. Januar 2022 keine Mails mehr transportieren können. Da ich davon ausgehe, dass Montag, den 3. Jan. 2022, einige Leute feststellen, dass der Exchange Server "kaputt ist", fasse ich in diesem Nachtrag nochmals alles Wissenswerte zusammen.
Anzeige
Das Problem
Ab dem 1.1.2022 00:00 Uhr (UTC) können weltweit viele (On-Premises) Exchange Server keine E-Mails mehr transportieren. Das Problem besteht darin, dass ein Signatur-Update für die FIP-FS "Microsoft" Scan Engine einen Konvertierungsfehler erzeugte, so dass die Engine nicht mehr startet. In den Protokollen findet sich das Ereignis:
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
Hintergrund ist, dass in der Signatur-Datei wohl das codierte Jahresdatum (2201010001 oder eine höhere letzte Ziffer) enthält und bei einer Umwandlung in einen signed long Integer-Wert einen Überlauf erzeugt, der dann den obigen Fehlerabbruch bedingt. Ich hatte im Blog-Beitrag Exchange Year 2022 Problem: FIP-FS Scan Engine failed to load – Can't Convert "2201010001" to long (1.1.2022) erstmals darüber berichtet und einen temporärer Workaround genannt.
Wer ist betroffen
Microsoft schreibt im Techcommunity-Beitrag Email Stuck in Transport Queues, dass Exchange Server 2016 und Exchange Server 2019 betroffen seien. Frank Carius schreibt in diesem Beitrag, dass Exchange 2016 oder Exchange 2019 Mails routen müssen, um betroffen zu sein. Dort findet sich auch die Aussage, dass Exchange Online sind nicht betroffen ist und auch Exchange 2013 sei nicht betroffen, wenn Sie nicht hinter Exchange 2016/2019-Servern versteckt sind (Hybrid Routing).
Dem steht aber die Aussagen in diesen Kommentaren zu meinem Blog-Beitrag Exchange Year 2022 Problem: FIP-FS Scan Engine failed to load – Can't Convert "2201010001" to long (1.1.2022) entgegen, wo Exchange Server 2013 als betroffen genannt wurde. Lasse ich hier erst einmal so stehen.
Anzeige
Um den obigen Fehler auszulösen, muss zudem der Malware-Agent installiert sein. In obigem Tweet weist jemand darauf hin, dass die Anti-Spam-Komponente nicht standardmäßig installiert werde. Das wäre die Erklärung, dass nicht alle Exchange-Server betroffen sind.
Der Fix von Microsoft
Microsoft hat im Techcommunity-Beitrag Email Stuck in Transport Queues eine Erklärung für das Problem bereitgestellt (siehe auch den den Blog-Beitrag Microsoft bestätigt Exchange Year 2022 Problem FIP-FS Scan Engine failed to load (1. Jan. 2022)). Wenige Stunden später wurde dann in einem Nachtrag ein temporärer Fix nachgeliefert, der aber bei betroffenen Systemen einen Eingriff des Administrators erfordert.
Der Fix besteht einmal aus einem PowerShell-Script https://aka.ms/ResetScanEngineVersion, welches herunterladen werden und dann ausgeführt werden kann. Zu beachten ist, dass die PowerShell Execution Policy:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned
aktiviert werden muss, damit das Script läuft. Das Script ist in einer administrativen Exchange Management Shell des betroffenen Exchange-Servers auszuführen. Das Script stoppt bestimmte Dienste, löscht den Ordner mit den Signaturdateien der Scan Engine und fordert dann ein neues Signatur-Update an. Microsoft hat dabei zu einem Trick gegriffen und dieses Update mit der Signatur-Version 2112330001 oder höher versehen. So tritt dann kein Konvertierungsfehler mehr auf.
Wer das Ganze lieber von Hand erledigt, für den hat Microsoft im im Techcommunity-Beitrag Email Stuck in Transport Queues eine Schritt-für-Schritt-Anleitung veröffentlicht.
Was man noch wissen sollte
In diesem Kommentar berichtet Michael, dass bei ihm der Download der EngineUpdates bei 92% und ca. 179 MByte hängen geblieben sei. Einen ähnlichen Hinweis habe ich auch auf Facebook zu meinen Posts als Rückmeldung bekommen. Das könnte an der Auslastung der Microsoft-Server hängen. Es kann durchaus eine halbe Stunde dauern, bis der Download fertig ist (siehe diesen Kommentar).
Wichtig: Wer den vom mir im Blog-Beitrag Exchange Year 2022 Problem: FIP-FS Scan Engine failed to load – Can't Convert "2201010001" to long (1.1.2022) erwähnten schnellen Workaround zum Deaktivieren der Scan-Engine angewandt hat, muss diesen im Anschluss wieder rückgängig machen. Robert schreibt in diesem Kommentar:
Was sich bei mir bewährt hat, war dass ich nach dem Fix einspielen (Script laufen lassen) den Server erst komplett rebootet habe. Dann erst wieder ein Enable-AntimalwareScanning.ps1 durchgeführt und den Transport-Dienst neu gestartet.
Vielleicht hilft das den einen oder anderen Betroffenen. Falls es bei der Ausführung des Microsoft-Fixes zu einem Fehler 0x84004003 kommt, sollte der Server, auf dem Exchange läuft, neu gebootet und der Versuch wiederholt werden (siehe diesen Kommentar).
Ergänzung: Falls es nach Anwendung des Fixes immer noch Probleme mit dem Mail-Transport gibt, bitte die Kommentare hier durchlesen – der folgende Befehl kann helfen.
Restart-Service FMS -Force
Sofern die Störung des Mail-Transports länger andauert, kommen auf Administratoren zwei Probleme zu. Einmal können die angenommenen Mails nicht weiter zugestellt werden. Dann läuft die Warteschlange mit den "Submissions" voll den Postfächern geroutet werden. Möglicherweise kann dies zu einer vollen Partition mit der Queue.dat führen, wie Frank Carius hier ausführt. Und es steht die Möglichkeit im Raum, dass empfangene, aber nicht zugestellte Mails, die älter als 48 Stunden sind, gelöscht werden.
Vielleicht helfen die obigen Hinweise ja weiter. Unter dem Strich könnte das Year 2022-Problem ein gewollt cleverer Schachzug von Microsoft gewesen sein. Das BSI und CERT-Bund warnen seit Monaten vor ungepatchten und unsicheren Exchange Servern (siehe z.B. BSI/CERT-Warnung: Kompromittierte Exchange-Server werden für E-Mail-Angriffe missbraucht (Nov. 2021) und CERT-Bund-Warnung: 30% der deutschen Exchange Server mit offenem OWA angreifbar). Wenn jetzt solche nicht betreuten Exchange-Server keine Mails mehr zustellen, werden Kunden Dienstleister mit der Fehlersuche beauftragen. Dann besteht die Möglichkeit, diese auf den neuen Patchstand zu bringen.
Ähnliche Artikel:
Exchange Year 2022 Problem: FIP-FS Scan Engine failed to load – Can't Convert "2201010001" to long (1.1.2022)
Microsoft bestätigt Exchange Year 2022 Problem FIP-FS Scan Engine failed to load (1. Jan. 2022)
Anzeige
Der letzte Exchange 2013 CU23 auf Win2012R2 hier war nicht davon betroffen. Die Version abgefragt mit Get-EngineUpdateInformation war eine 220101xxxx und FIPS lief noch. Auf einem Testsystem habe ich dann trotzdem einmal das Script "ResetScanEngineVersion" durchlaufen lassen und anschließend neu gestartet, funktioniert auch einwandfrei auf einem Exchange 2013. Hab dies dann trotzdem auch am Produktivsystem gemacht. Nicht dass der Updater aufgrund der von Microsoft zurückversetzten UpdateVersion ins Taumeln kommt oder nicht mehr aktualisiert.
Vielen Dank Herr Born! Sie sind mein Held!
Dank Ihrem Beitrag wusste ich heute früh gleich, was Sache ist, als keine Mails aus dem neuen Jahr eingetroffen sind und konnte die Antimalware-Engine updaten.
Danke für die Infos!
Das Antimalwareupdate wurde mit satten 1Mbit/s heruntergeladen aber davon abgesehen lief es durch.
An verschiedenen Stellen wird berichtet, Microsoft könne nun die Versionsnummer bis 2147483647 hochzählen. Auch Frank Carius meint in diesem Sinne auf https://www.msxfaq.de/exchange/update/y2k22_bug.htm#fix_in_3517_tagen, wir hätten noch 3517 Tage, oder 9,6 Jahre Zeit. Sollte Microsoft jedoch auf dem eingeschlagenen Weg bleiben, dürfte der nächste Ärger aber schon deutlich früher, nämlich bereits am 10.03.2022 drohen. Dann wechselt die Versionsnummer der Signatur von 2112*99*0001 auf 2112*100*0001 und sprengt damit wieder die Grenzen des Datentyps.
Ich versteh ja den Ansatz dieser langen Zahl nicht. Jahreszahl und 5 mal fortlaufend würde wohl auch reichen (202200001-202299999). Ich glaube nicht, dass es im Jahr 99.999 Updates gibt. Selbst wenn es jede Stunde ein Update gibt sind das pro Jahr 8760 (8784 im Schaltjahr). Vor allem ist die SignaturDateTime selbst dadurch gar nicht beeinträchtigt und die SignatureVersion ist wieder eine andere Zahl. Dann hätte man Zeit bis ins Jahr 21474
Einfach nur fortlaufende Nummern würde auch schon bereits ausreichen, also einen simpler Zähler.
Man beginnt bei 0 und zählt dann bei jedem Update um 1 hoch.
Ein unsigned int 32 Bit reicht für mehr als 4 Milliarden Updates, was also offensichtlich garantiert ausreichend wäre und keinerlei Probleme verursachen würde.
Das wäre KISS (keep it simple stupid).
Wen interessiert denn die Jahreszahl oder das Datum, wenn eine ganz simple Versionsnummer ausreichend ist?
Wer das Datum des Updates wissen will, der kann ja in die Dateieigenschaften reinschauen oder in eine MS-Datenbank.
Stimmt, ich stell mir grad vor wir hätten bei den KB-Artikeln überall Jahr Monat Tag mit drin stehen :D
Das ist wojl die Version Vieren signaturen.
Die will man gerne überall haben, auch im Dateinamen und sie soll einfach sortierbar sein.
Pro Tag kann es mehrere gebe. Und wenn man kostbaren Speicher und Zeit sparen muß?
(früher hat man in 64kByte einen Pascal Compiler nebst Editor unyergebracht… )
Warum hat man nicht einfach eine Milliarde abgezogen sondern hat so dicht am Limit laviet?
Jetzt hat man den Werte ja auch geändert. Geht jetzt bis zum März 2022. Bin ich hier in einem schlechten Alptraum?
Gibt es irgendwelche Libraries die dieses seltsame Format verwenden oder warum tritt der Fehler jetzt scheinbar überall auf?
Warum hat man versäumt den Kunden Geld aus der Tasche zu wie damals beim Y2K Panik jeder schnell noch ein kostenpflichtiges, zwingendes Update angeboten hat?
Ich glaube so hat auch der gedacht, der sich das mal unsigned int32 ausgedacht hat.
Er wollte das Signatur Datum einfach lesbar machen.
Bei einer laufenden Nummer ist das nicht der Fall.
Man stelle sich vor, das MHD würde als laufende Seriennummer auf der Dose stehen…
Er hat einfach nicht damit gerechnet das manche Compiler bei if- vergleichen beide Wert auf dasselbe Format casten, das ist eine ganz gemeine Newbie-Falle.
Bei guten compileren kommt u. U. Eine Warnung, das diese Anfrage wegoptimiert wurde, weil konstant.
Aber wenn man nervende Warnings abgeschaltet hat, nicht jede Funktion vollständig durchtesten kann weil man unbedingt abliefern muss und man sich aufgrund seines Monopols ein -"reift beim Kunden" leisten kann, dann passiert so etwas.
Bill Gates hat angeblich mal fragen lassen :
Wollt ihr für Fehler-Beseitigung zahlen?
Seltsamerweise wollten Kunden lieber für neue Features zahlen…
"2147483647…. Dann wechselt die Versionsnummer der Signatur von
2112*99*0001 auf 2112*100*0001"
wohl hoffentlich
211299001 auf
211301001, oder?
oder zweifelt irgendwer an die Fähigkeit der MS Programmierer?
Interessant wird es aber nach der Version
2147…
Ich bin mal gespannt wie MS aus der Nummer raus kommt. Die Maschinen die den Wert vorzeichenbehaftet interpretieren sind ja draußen.. Und neue Versionen müssen ja größer sein.
Ein Rollback ist prinzipiell hier gefährlich… .
Und irgendwann werden unsere Enkel uns nivht mehr fragen, wieso
Der Dezember der 12. Monat ist und nicht der 10…und als 37 numerisch dargestellt wird…
Ich denke mal, die sind da inzwischen auch drauf gekommen.
Musste heute früh schmunzeln, als ich folgendes gesehen habe…
Engine Version:1.1.18800.4
Signature Version:"1.355.1485.0"
Update Version:2112330030
:)
bezgl. Betroffenheit vom Exchange 2013: Die fehlerhafte Signatur lässt den Transport Service nicht crashen (bei EX2016/2019 schon), die Malware ScanEngine funktioniert aber wie bei allen dann nicht mehr.
Der Fix funktionierte bei meinen Kunden mit Exchange 2016 & 2019 einwandfrei.
Kein Neustart etc. danach nötig.
Vielen Dank für den Artikel und auch die anderen, die dieses Thema betreffen. Das hat mir echt geholfen.
Seit den letzten Patch für 2019 tritt genau das genannte Problem bei mir auf. Hat noch jemand dieses Verhalten?