Microsoft bietet Lösung für Y2K22-Bug in Exchange 2016/2019

Durch den dadurch verursachten Absturz der Malware-Engine stockt der Transport von Nach­richten. Außerdem schreibt das System die Ereignisse 5300 und 1106 (FIPFS) in den Application Eventlog auf dem Exchange-Server. Diese Einträge erhält man auch bei der Ausführung des HealthChecker-Scripts, so dass man dieses nutzen kann, um das Problem zu verifizieren.

Da sich dieser Vorfall am Neujahrs­wochenende ereignete, dürften viele Anwender erst spät reagiert haben. In diesem Fall könnten viele Mails aufgelaufen und möglicherweise von Exchange automatisch aus der Warte­schlange entfernt worden sein.

Viele Admins wurden über soziale Medien wie Reddit oder Twitter aufmerksam, da Microsoft erneut nur langsam reagierte. Eine vorüber­gehende Maßnahme bestand darin, die Malware-Engine zu deaktivieren.

Eingriff von Admins erforderlich

Microsoft hat nun eine Lösung in Form eines PowerShell-Scripts bereitgestellt, das Admins auf jedem Mailbox-Server in einer Sitzung mit administrativen Rechten ausführen sollen. Falls noch nicht erfolgt, muss dort die Execution-Policy für PowerShell auf RemoteSigned geändert werden.

Transport-Server sind von diesem Problem ebenso wenig betroffen wie reine Management-Server in einer hybriden Konfiguration mit Office 365. Versendet in einer Hybrid-Bereitstellung jedoch ein On-prem-Server die Mails, dann wird der Fix auch dort benötigt.

Keine Signatur-Updates mehr für Exchange 2013

Außerdem führt das Datums­problem nur bei Exchange 2016 und 2019 zu einem Absturz der Malware-Engine. Daher stauen sich die Mails in Exchange 2013 zwar nicht, aber falls diese Version bereits ein Antimalware-Update erhalten hat, das mit "22" beginnt, dann erhält dies in Zukunft keine neuen Signaturen mehr.

"Neue" Versionierung

Das Script ersetzt die Scan-Engine und zugehörige Metadaten durch ein Update, dessen Schema für die Versionierung weiterhin mit einer "21" beginnt. Dabei handelt es sich offensichtlich um eine vorüber­gehende Lösung, der Microsoft eine grundsätzliche Fehler­behebung folgen lassen dürfte.

Kommentare zum Blog-Post, in dem Microsoft die Problem­behebung ankündigt, berichten davon, dass die vollständige Ausführung des Scripts mehr als eine Stunde dauern kann. Außerdem finden sich dort zahlreiche Klagen, wonach die Ausführung des Scripts gescheitert sei oder nach dessen Beendigung die Nachrichten sich weiter in der Warteschlage stauen.

Manuelle Behebung als Alternative

In einigen Fällen ließ sich das Problem der Mail-Queue durch einen Neustart des Servers beheben. Als Hindernis für das Script kann sich der BITS-Dienst erweisen, der das Löschen von Dateien durch das Script verhindert und daher temporär angehalten werden muss.

Außerdem scheint das Script manchmal daran zu scheitern, dass die Beendigung des Transport­dienstes zu lange dauert und dadurch ebenfalls Dateien weiter geöffnet sind. Für solche Situationen beschreibt Microsoft, wie man die einzelnen Schritte des Scripts manuell abarbeiten kann. Dies ist unter Exchange 2013 generell notwendig, weil das Script nicht für diese Version ausgelegt ist.

Verfügbarkeit

Das Script ResetScanEngineVersion kann von Microsofts Website herunter­geladen werden. Eine genaue Anleitung für das manuelle Zurücksetzen der Engine-Version findet sich im oben erwähnten Blog-Beitrag.