Exchange Y2K22 Bug

Inhaltsverzeichnis

Bin ich betroffen?
Offizieller Fix
Zeitlicher Ablauf
Betroffene Server
Nächster Ablauf
Workaround
Auswirkung
Analyse
Defender Updates
Monitoring
Beifang
Nach dem Spiel ist vor dem Spiel
Weitere Links

Mit dem Jahreswechsel 2021/2022 hat sich der in Exchange 2016/2019 eingebaute Malware-Scanner anscheinend an einer Versionsnummer verschluckt. Das ist nun kein Sicherheitsloch wie der Hafnium Exploit oder Exchange Fail Jan 2019 - CVE-2018-8581, aber Mails, die in einer Warteschlange gehalten und nicht zugestellt werden, können Festplatten volllaufen lassen und letztlich andere Business-Prozesse verzögern. Da hilft es auch wenig, wenn der Fehler an einem Feiertag (Neujahr) ist und der 2. Jan auf einen Sonntag fällt.

Diese Seite als Video erklärt
https://youtu.be/piKuMAxHtCE (Stand 3. Jan 2022)

Bin ich betroffen?

Der beste Indikator: Ihre Kunden oder Mitarbeiter beschweren sich, dass keine Mails zugestellt werden. Aber auch wenn es noch scheinbar funktioniert, sollten sie nachschauen.

Folgende Voraussetzungen müssen nach meiner Analyse zutreffen.

Exchange 2016 oder Exchange 2019 müssen Mails routen
Exchange 2013 und Exchange Online sind nicht betroffen, wenn Sie nicht hinter Exchange 2016/2019-Servern versteckt sind (Hybrid Routing).
Malware Agent muss aktiviert wird
Sie müssen bei der Installation oder danach die Exchange Malware Transport Agenten aktiviert haben.
Malware Patternfile-Version ist größer 2112319999
Das erste Patternfile im Jahr 2022 hat die Versionsnummer 2201010001 und führt zu dem Fehler. Wer noch drunter ist, sollte beim nächsten Update automatisch die Version 2112330001 oder höher bekommen und hat kein Problem

Interessanterweise scheint es Server zu geben, die wider Erwartung immer noch Mails routen. Sie sollten dennoch die Korrekturen vornehmen oder zumindest kontrollieren.

Sie sollten umgehend handeln, wenn sie keine Mails verlieren wollen.
Ohne Korrektur bleiben die Mails in der "Submission-Queue" hängen und werden nicht zugestellt.
Exchange löscht per Default nach 2 Tagen nicht zugestellte Nachrichten!

Besondere Herausforderung: Wie informieren sie ihre Kunden über ein Mail Problem, wenn die vielleicht keine Mails mehr empfangen können?
-> Bitte folgt der MSXFAQ per RSS-Feed über oder auf Twitter (https://twitter.com/msxfaq), um zukünftig informiert zu sein.

Offizieller Fix

Am 02.01.2022 05:45MEZ (1. Jan 2022 10:45 PST) hat Microsoft ihren Blog-Artikel auf https://techcommunity.microsoft.com/t5/exchange-team-blog/email-stuck-in-transport-queues/ba-p/3049447 aktualisiert und mit einem Link auf ein PowerShell Skript ergänzt, welches den Malware-Scanner "zurücksetzt" und die aktuellsten Patterns und Scan-Engine herunterlädt. Die Schritte sind einfach, wenn ihr Exchange Server Internetzugriff hat.

Aktion	Erledigt
Patch-Script von Microsoft laden Herunterladen des PowerShell Skripts von https://aka.ms/ResetScanEngineVersion Das können Sie auf eine PC machen und dann die Datei auf den Exchange Server kopieren
Admin PowerShell auf Exchange starten Melden Sie sich auf jedem Exchange Server an und starten Sie einer PowerShell als Administrator.
Server Maintenance Auch wenn Microsoft dies nicht explizit beschreibt, sollten sie ihre internen Prozesse zur "geplanten Wartung ausführen. Dies gilt insbesondere bei DAGs oder "selbst heilenden Systemen". Es gibt Systeme, die gestoppte Dienste ansonsten automatisch neu starten. Exchange 2016 Update Checkliste
Ausführen von ".\Reset-ScanEngineVersion.ps1" Das Skript stoppt und startet FIPS und Transport-Dienste aber die Anwender sollten davon nichts merken Ich habe im Nachgang die Version kontrolliert. Microsoft hat wohl einfach die Nummerierung von 220101001 auf 211233001 zurückgesetzt und daher wird ein Reset benötigt
Nacharbeiten Auch wenn Microsoft dies nicht gesondert beschreibt, sollten Sie danach kontrollieren, dass die Dienste laufen bzw. zur Sicherheit noch einmal neu gestartet werden. # Option1 Restart-Service fms -Force # Option2 Stop-Service MSExchangeTransport Stop-Service fms Start-Service fms Start-Service MSExchangeTransport Beim Ausführen von ".\Enable-AntimalwareScanning.ps1" wird ein Neustart der Dienste auch angemahnt aber vergisst den FMS-Dienst.
Rückbau des temporären Workaround Wenn Sie vorher einen Workaround umgesetzt haben, um das Mailrouting ohne Malware-Scan zu erlauben, dann sollten Sie dies wieder rückgängig machen
Monitoring Kontrollieren Sie das Eventlog, die Message Queues und das Messagetracking auf "hängende" Mails". Die Queues sollten wieder im normalen Zustand sein und Mails geroutet werden.
Nachbereitung Mittlerweile sind 48h seit dem 1.1.2022 vergangen und wenn ihr Exchange Server noch "Default" konfiguriert ist, dann löscht er nicht zugestellte Mails nach 48h. Sie können versuchen, diese aus einem Backup der "queue.dat" aufwändig zu restaurieren. Aber sie können auch aus dem Messagetracking relativ einfach ermitteln, welche Mails von welchem Absender, Empfänger und Betreff gelöscht wurden und die Absender informieren. Meist reicht dies auch schon aus.

Damit sollte ihr Exchange Server nun wieder sauber "scannen" und Nachrichten abarbeiten.

Achtung:
Das funktioniert nur, wenn ihr Exchange Server die Updates aus dem Internet holen kann. Ansonsten müssen Sie die Schritte auf jedem Server selbst durchführen bzw. die Patterns verteilen.

Ich gehe davon aus, dass Microsoft diesen "Fehler" zum Anlass nimmt, ganz viele Codes dahingehend zu untersuchen, ob Sie auch damit Probleme haben oder den Fehler besser abfangen und in einem der nächsten CUs dann eine verbesserte Version installiert wird.

Zeitlicher Ablauf

Microsoft hat "relativ" schnell reagiert aber leider gibt es keinen Automatismus durch den EEMS - Exchange Emergency Mitigation Service.

Zeitpunkt (MEZ)	Aktivität
01.01.2022_00:00	Mit dem ersten Defender Pattern-Update im Jahr 2022 kommt die Versionsnummer "2201010001". Leider scheint ein Code diese nummer in einen "int32" zu konvertieren, um z.B.: zu vergleichen, ob die Version neuer ist also die vorhandene Version Das bricht aber mit einem Fehler ab, da ein [int32] maximal den Wert 2.147.483.647 annehmen kann. Mails werden zwar noch angenommen aber nicht mehr geroutet oder zugestellt, sondern füllen langsam die Warteschlange auf. Erste Meldungen im Internet erscheinen.
01.01.2022_12:33	Die ersten Monitoring-Instanzen bei Net at Work Kunden schlagen Alarm, dass Queues anwachsen. Als Gegenmaßnahme wird der Bypass bei den Kunden aktiviert, die einen vorgeschalteten Virenscanner haben. Get-Transportservice \| Set-MalwareFilteringServer -BypassFiltering:$true
01.01.2022_15:50	Nach ersten Analysen und Prüfungen in meinen Testumgebungen ist klar: Das Problem ist weitreichend und ich addiere einen ersten Hinweis direkt auf der Homepage der MSXFAQ. Auch weitere Webseiten thematisieren das Problem. https://twitter.com/msxfaq/status/1477291038729506823 Exchange Year 2022 Problem: FIP-FS Scan Engine failed to load – Can’t Convert “2201010001” to long (1.1.2022) https://www.borncity.com/blog/2022/01/01/exchange-fip-fs-scan-engine-failed-to-load-cant-convert-2201010001-to-long-1-1-2022/
01.01.2022_20:38	Es dauert schon etwas, die verschiedenen Versionen und Umgebungen zu prüfen, mögliche alternative Lösungsvorschläge zu analysieren und das Risiko abzuschätzen. Aber am Abend des1. Jan 202 geht diese ausführlichere Seite der MSXFAQ online. Erstmals auch mit dem Hinweis auf das Datenverlustrisiko nach 2 Tagen Inaktivität.
01.01.2022_20:39	Die erste offizielle Meldung (01.01.2022 11:39 PST) in Form eines Blog-Artikels von Microsoft wird veröffentlicht: Email Stuck in Transport Queues https://techcommunity.microsoft.com/t5/exchange-team-blog/email-stuck-in-transport-queues/ba-p/3049447 Microsoft rät zur ersten Abhilfe hier die Abschaltung des Mailware Scanners.
02.01.2022_05:45	Microsoft hat ihren Blog-Artikel (https://techcommunity.microsoft.com/t5/exchange-team-blog/email-stuck-in-transport-queues/ba-p/3049447) am 1/1/22 @10:45pm PST aktualisiert Durch ein "Zurücksetzen" des Malwarescanners kann der Administrator das Problem beseitigen. Es gibt ein PowerShell-Script, welches alle Aktionen alleine macht. https://aka.ms/ResetScanEngineVersion Bitte in einer normalen administrativen PowerShell auf dem Exchange Server starten. Der Download der neuen "Scanengines" ist ca. 180 Megabyte groß und kann einige Minuten dauern. Vergessen Sie danach nicht einen eventuell vorher temporär deaktivierten Malware-Scanner wieder zu aktivieren.
Offen	Ich vermute, dass das manuelle Update auch den fehlerhaften Code beseitigt. Allerdings habe ich noch keine Information, ob das nicht auch durch das reguläre Updates funktionieren würde. Wenn nicht, haben wir die kommende Woche ein hohes Supportaufkommen und vermutlich von Exchange nach 2 Tagen gelöschte Mails. Ich lasse mal einen Server "ohne" Patch um zu sehen, ob er sich selbst fängt.

Die Thematik mit solchen "Datums-Problemen" ist übrigens nicht neu. Die "Endlichkeit" von Zahlen hat die IT schon in der Vergangenheit beschäftigt und wird auch 2038 das nächste mal sicher für Unsicherheit sorgen.

Jahr 2000 Problem
https://de.wikipedia.org/wiki/Jahr-2000-Problem
Jahr 2038 Problem
https://de.wikipedia.org/wiki/Jahr-2038-Problem
Dann erreichen nämlich die Anzahl der Sekunden seit 1.1.1970 den magischen Wert 2.147.483.647 und springen auf -2.147.483.648.

Bis dahin können sie aber den fehlerhaften "Malware TransportAgent" temporär deaktivieren.

Achtung: Wenn Sie ansonsten keinen Malwarefilter zwischen Exchange und Internet oder auf dem Clients haben, erhöhen Sie ihr Risiko, einen Virus nicht zu entdecken.

# Option1: Agent deaktivieren. Er bleibt aber installiert und kann schnell wieder aktiviert werden.
Get-TransportAgent "Malware Agent" | Disable-TransportAgent
Restart-service msexchangetransport


#Option2: Filterung auf allen Transportdiensten deaktivieren. Hier ist kein Neustart des Transport Diensts erforderlich
Get-Transportservice | Set-MalwareFilteringServer -BypassFiltering:$true

#Option3: Agent komplett deinstallieren. Sicher die radikalste Methode, wenn Sie eh eine andere Lösung nutzen.
Disable-AntiMalwareScanning.ps1

Alle drei Optionen deaktivieren den "Attachment Scan" und umgehen damit FIPS. Das bedeutet nicht, dass die Fehlermeldungen im Eventlog weg sind aber das Mailrouting funktioniert wieder, wenn gleich dann der Microsoft Malware-Scanner nicht mehr aktiv ist.

Da die meisten Firmen aber sowieso Scanner auf den Endgeräten haben und meist einen besseren Spam/Malwarefilter davor betreiben, ist das Risiko für einige Zeit vertretbar.

Betroffene Server

Aktuell ist die Liste noch sehr unvollständig und ich kann nur die Feedbacks meiner eigenen Kunden, Server und Lesern sammeln.

Exchange Version	Windows Version	Betroffen	Fix
Exchange 2013	Any	Noch keine Meldungen	entfällt
Exchange 2016 CU22	Windows 2012R2	Betroffen	1/2/3
Exchange 2019	Windows 2019	Es gibt Meldungen, dass kein Problem vorliegt aber auch betroffene Server.	1/2/3
Exchange Online	Entfällt	Sie sind nicht betroffen, wenn Sie eingehende und ausgehende Mails über Exchange Online direkt senden. Wenn ihr MX-Record aber noch auf den On-Premises-Server verweist oder sie ausgehende Mails per Hybrid Centralized Mail Transport versenden. dann müssen Sie auf dem lokalen Server aktiv werden	Nein

Die Aussagekraft ist aber sehr beschränkt, denn es kann sein, dass Server noch kein Update bekommen haben oder schon das neueste Update haben, welches den Fehler korrigieren sollte.

Nächster Ablauf

Wenn Sie sich die Versionsnummern genau anschauen, dann sehen Sie, was Microsoft eigentlich gemacht hat:

Versionsnummern alt	Versionsnummern Neu
2112310005 2112310006 2201010001 2201010002	2112310005 2112310006 2112330001 2112330002

Sie haben einfach die Stelle mit dem Tag von 31 nicht auf 01 gesetzt sondern weiterlaufen lassen. der 1 Jan 2022 ist also nicht 220101 sondern 211233. Ich weiß nun nicht, wie genau Microsoft zukünftig die Pattern durchnummeriert, aber wenn die letzten 4 Stellen weiterhin jeden Tag von 0001 bis maximal 9999 hochzählen und nun die bisherige "Tagesstelle" bis 99 läuft und dann der Monat von 12 auf 13 wechselt, dann hätten wir 214748-211231=3517 Tage oder 9,6 Jahre Zeit.

Update:
Am 4. Jan hatte ich die Version 2112330013 und nicht 2112340001. Insofern zählt Microsoft nun wohl einfach hoch. Damit reicht der Nummernpool dann für 2147483647 - 2112330013 = 35153634 Updates. Auch wenn mehrere Updates/Tag kommen würden, dann haben wir viele Jahrhunderte Ruhe.

Damit ist aber auch klar, warum man ein "RESET" machen muss, denn der Update-Prozess wird die Version 2112330001 nicht als Update der bislang schon heruntergeladenen Versionen 2201010001 und folgende ansehen. Der "Download" der neuer Versionen funktionierte ja schon die ganze Zeit. Das dürfte aber auch bedeuten, dass Exchange Server mit einer Patternversion unter 2112330001 das Problem nicht haben. Das gilt für Umgebungen, bei denen das Update anderweitig verteilt werden oder über den Jahreswechsel ausgesetzt wurde.

Workaround

Der Workaround ist nicht mehr erforderlich, seit dem es von Microsoft einen offiziellen Fix gibt. Ich lasse ihn aber hier stehen, denn er ist sehr schnell umgesetzt, auch wenn der Virenschutz temporär abgeschwächt ist.

Aktuell gibt es erste Gerüchte über ein Updates aber wenn es aber soweit ist, dann könnte manuelles Update des Servers erforderlich sind. Dazu benötigen Sie eine administrative PowerShell.

# Erforderliches Snapin laden
Add-PSSnapin Microsoft.Forefront.Filtering.Management.Powershell

# Aktuelle Version ausgeben
Get-EngineUpdateInformation

# Update-Script von Exchange starten
& $env:ExchangeInstallPath\Scripts\Update-MalwareFilteringServer.ps1 -Identity ($env:computername)

# Das Skript startet den Update-Prozess aber wartet nicht auf dessen Abschluss

# Ergebnisse vergleichen
Get-EngineUpdateInformation

Mein letzter Stand (1. Jan 2022 20:09) war folgender und hat noch KEINE Lösung gebracht.

Engine            : Microsoft
LastChecked       : 01.01.2022 08:02:44  +01:00
LastUpdated       : 01.01.2022 05:57:14  +01:00
EngineVersion     : 1.1.18800.4
SignatureVersion  : 1.355.1247.0
SignatureDateTime : 01.01.2022 12:29:06  +01:00
UpdateVersion     : 2201010009
UpdateStatus      : UpdateAttemptNoUpdate

Manually update scan engines in Exchange Server
https://docs.microsoft.com/en-us/exchange/troubleshoot/setup/manually-update-scan-engines

Auswirkung

Die betroffenen Exchange Server nehmen weiterhin Mails entgegen aber Sie werden nicht mehr weiter geroutet oder lokal zugestellt. Die Auswirkungen sind:

Die "Submission" Warteschlange wird immer größer
Das können Sie sehr schnell mit "Get-Queue" feststellen. Der "Message Count" ist ja wohl

[PS] C:\>get-queue

Identity            DeliveryType Status MessageCount Velocity RiskLevel OutboundIPPool NextHopDomain
--------            ------------ ------ ------------ -------- --------- -------------- -------------
EX16\Submission     Undefined    Ready  723          -7       Normal    0              Submission

Messagetracking
Auch in Blick auf die EventIDs im Messagetracking der letzten Stunden zeigt, dass es hier keine "SEND" Einträge und stattdessen viele "DEFER" und "AGENTINFO"-Meldungen gibt. Letzere sind die "Verzögerungsmeldungen" an den internen Absender, die aber natürlich auch nicht zugestellt werden.

[PS] C:\>Get-MessageTrackingLog -start (get-date).addhours(-1) | group eventid -NoElement
WARNING: There are more results available than are currently displayed. To view them, increase the value of the
ResultSize parameter.

Count Name
----- ----
   34 RECEIVE
  467 AGENTINFO
  467 DEFER
   26 DSN
    3 NOTIFYMAPI
    3 SUBMIT

[PS] C:\>Get-MessageTrackingLog -start (get-date).addhours(-1) -EventId DEFER
01.01.2022 18:18:35 DEFER AGENT prtg.service@msxfaq... {naw.prtg.service@... PRTG Roundtrip...
01.01.2022 18:18:42 DEFER AGENT MicrosoftExchange3...  {prtg.service@msxf... Verzögerte Zustell...

Im Extremfall kann die Partition mit der Queue.dat voll laufen
Exchange beendet die Dienste. Die meisten Mailserver versuchen Nachrichten weitere 24h zuzustellen aber dies ist nicht garantiert.
Mitarbeiter bekommen keine Mai
Das wird aber dann wohl eher am Montag den 3. Jan wieder interessant, wenn die Anwender als "lebendige Systemmonitore" dann beim Administrator Alarm schlagen
Automatische Prozesse können Mails einliefern aber Sie werden nicht weiter geroutet
Das ist dann ein Problem, wenn eingehende Mails von Exchange wegen "Überalterung" verworfen werden und ein NDR an den Absender geht, der aber ebenfalls nicht geroutet wird.
Mailverlust
Normalerweise löscht Exchange eine nicht zugestellte Nachricht nach 48 Stunden. Ich weiß nicht, ob das auch hier in der Submission Queue der Fall ist. Wenn dies aber zutrifft, dann ist Gefahr im Verzug, denn am Montag morgen den 3.1.2022 sind die ersten Mails schon älter als 48h.
Use the Exchange Management Shell to configure the message expiration timeout interval on Mailbox servers or Edge Transport servers
https://docs.microsoft.com/en-us/exchange/mail-flow/queues/configure-message-intervals?view=exchserver-2019#use-the-exchange-management-shell-to-configure-the-message-expiration-timeout-interval-on-mailbox-servers-or-edge-transport-servers

# Optional kann man die Expiration Time mal hochsetzen
Get-Transportservice | Set-Transportservice -MessageExpirationTimeOut 5.00:00:00
Es ist KEIN Sicherheitsloch
Es gibt keine Anzeigen, dass dieses Problem irgendwie ihre Umgebung direkt gefährdet. Allerdings möchten Sie ja die Funktion schnell wieder bereitstellen. Dazu können Sie den internen Scanner deaktivieren. Dann könnte Malware durchschlüpfen, wenn Sie keine weiteren Produkte davor (Mailrelay) und danach (Auf dem Client) einsetzen.

Sie können also nun darauf warten, ob Microsoft ein Update schnell bereitstellt oder sie temporär.

Analyse

Seit Exchange 2013 (E2013:MalwareScan/Ex2016 Antimalware und AntiSpam) liefert Microsoft kostenfrei einen Malware-Scanner mit, der auf dem Exchange Transport nach Viren und anderem Schadcode sucht. Es ist im wesentlichen ein Transport Agent, der bei der Installation oder nachträglich aktiviert werden kann und jede geroutete Mails mit den klassischen Defender-Patterns untersucht. Wie üblich kommen die Pattern-Dateien regelmäßig als Update und haben natürlich eine Versionsnummer, so dass die Scanengine erkennen kann, ob eine neue Version vorliegt. Ein Versionsvergleich ist üblicherweise ein Größer/Kleiner-Vergleich von Zahlen. Wenn die Pattern-Dateien aber ein String sind, muss dieser erst in eine Zahl konvertiert werden. Das ist auch der erste Anhaltspunkt im Eventlog. Im System Eventlog habe ich das auf meinem Server das erste mal gegen 02:11 gefunden. Anhand der Zeitzone wäre das dann 01:11 UTC und nicht direkt nach Mitternacht.

Log Name:      System
Source:        Service Control Manager
Date:          01.01.2022 02:11:25
Event ID:      7034
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      NAWEX16.netatwork.de
Description:
The Microsoft Filtering Management Service service terminated unexpectedly. It has done this 2 time(s).

Die Meldung im System-Eventlog wiederholt sich, da der Service ja wieder gestartet und abgebrochen wird. Im Applicationseventlog finde ich dann die FIPS-Meldungen

Die Fehlermeldung im Eventlog mit der EventID 5300 ist schon ein guter Hinweis:

Event Id 5300
The FIP-FS „Microsoft“ Scan Engine failed to load. PID: 21744, 
Error Code: 0x80004005. 
Error Description: Can’t convert „2201010001“ to long.

Die Scan-Engine versucht den String "2201010001" in einen "long"-Wert zu konvertieren. In einer 64bit oder 32bit PowerShell ist das aber kein Problem:

PS C:\> [long]"2201010001"
2201010001

Aber das gilt nicht für C++. Hier ist die Obergrenze leider 2147483647

Quelle: Limits on Integer Constants
https://docs.microsoft.com/en-us/cpp/cpp/integer-limits?view=msvc-170#limits-on-integer-constants

Hätte Microsoft damals einfach "Unsigned int" genutzt, wäre diese Umrechnung vermutlich nie aufgefallen.

Defender Updates

Natürlich wollte ich nun sehen, wie es um die Forefont Patterns aussieht. Über die normale PowerShell kann ich den aktuellen Stand anzeigen lassen.

PS C:\> Add-PSSnapin Microsoft.Forefront.Filtering.Management.PowerShell
PS C:\> Get-EngineUpdateInformation

Engine            : Microsoft
LastChecked       : 01.01.2022 06:31:50  +01:00
LastUpdated       : 01.01.2022 05:57:14  +01:00
EngineVersion     : 1.1.18800.4
SignatureVersion  : 1.355.1247.0
SignatureDateTime : 01.01.2022 12:29:06  +01:00
UpdateVersion     : 2201010009
UpdateStatus      : UpdateAttemptFailed

Hier ist zwar der letzte Update fehlgeschlagen, aber das kann ja mal passieren. Aber die Version ist hier (1.Jan 2022 18:58) schon auf 2201010009 angestiegen. Entsprechend finde ich auch den Fehler im Eventlog.

Log Name:      Application
Source:        Microsoft-Filtering-FIPFS
Date:          01.01.2022 18:54:41
Event ID:      5300
Task Category: None
Level:         Error
Keywords:      
User:          LOCAL SERVICE
Description:
The FIP-FS "Microsoft" Scan Engine failed to load. PID: 18104, Error Code: 0x80004005. 
Error Description: Can't convert "2201010009" to long.

Die eigentlichen Updates der Pattern-Dateien laufen also weiter und auch in der Update-Konfiguration steht alles sauber drin:

C:\Program Files\Microsoft\Exchange Server\V15\FIP-FS\Data\UpdateInformation.xml

<?xml version="1.0" encoding="utf-16"?>
<UpdateInformation xmlns="http://schemas.microsoft.com/forefront/2010/1/fs-updateinformation">
   <Properties>
      <ProductGUID>{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}</ProductGUID>
   </Properties>
   <Engines>
      <EngineStatus id="Microsoft">
         <ID>1</ID>
         <Name>Microsoft</Name>
         <LastChecked>2022-01-01T18:01:55Z</LastChecked>
         <LastUpdated>2022-01-01T16:57:14Z</LastUpdated>
         <LastDefinitionsUpdate>2022-01-01T11:29:06Z</LastDefinitionsUpdate>
         <EngineVersion>1.1.18800.4</EngineVersion>
         <SignatureVersion>1.355.1247.0</SignatureVersion>
         <UpdateVersion>2201010009</UpdateVersion>
         <EngineUpdateStatus>UpdateAttemptNoUpdate</EngineUpdateStatus>
         <LastUpdateStreamId>{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}</LastUpdateStreamId>
         <AdditionalEngineInformation></AdditionalEngineInformation>
      </EngineStatus>
   </Engines>
</UpdateInformation>

Genau genommen könnte ich de Update-Prozess anhalten und ein Rollback auf eine frühere Version der Pattern-Datei machen. Dann wäre mein Schutz nicht aktuell, aber ich hätte zumindest eine Erkennung aller bis 31. Dez 2021 bekannten Schadprogramme. Für kleine Firmen, die tatsächlich nur auf den eingebauten Virenscanner in Exchange bauen, wäre das wohl besser.

Leider habe ich auf meinem Server nur die aktuellste Version gefunden.:

Quelle: C:\Program Files\Microsoft\Exchange Server\V15\FIP-FS\Data\Engines\amd64\Microsoft\Package

Hier gibt es zumindest bei mir keine "vorherige Version".

Monitoring

Diese "Störung" ist wieder ein gutes Beispiel, wie wichtig die Überwachung von Servers ist. In dem Fall ist in den ersten zwei Tagen erst einmal kein Datenverlust zu befürchten aber durchaus eine Störung, die ein einzelnen Fällen auch schnell sehr teuer werden kann. Denken Sie an eingehende Bestellungen, den Versand von Frachtbriefen an eine Spedition oder auch nur ein elektronisches Bahn/Flug-Ticket oder eine Covid19-Testbestätigung. Auch wenn die Wichtigkeit von Mails oft kleingeredet wird um vielleicht Kosten zu sparen, so darf Mail natürlich "nie" ausfallen und muss "ganz schnell" sein. Solche Aussagen kennt sicher jeder Administrator, wenn es um die nächsten Budgetgespräche und Festlegung von SLAs geht.

Der "günstige" Ansatz ist natürlich ein Monitoring ihrer Umgebung, die sowohl Kennzahlen auswertet aber auch End2End-Tests durchführt. Können Sie alle drei Punkte mit ruhigem Gewissen als erledigt kennzeichnen?

Punkt	Beschreibung	Erledigt
Eventlog	Der Y2K22-Fehler hat sich sehr schnell und wiederkehrend im Eventlog als Fehlermeldung gezeigt. Das macht es einfach, diesen ansonsten "nie gesehenen" Fehler als "neu" zu melden.
Queues	Die Exchange Warteschlangen können Sie recht einfach per PowerShell und eingeschränkt auch per Performance Counter überwachen. Über so eine Überwachung können Sie zum einen den "Füllstand" von Warteschlangen sehen aber auch die Zunahme/Abnahme und die "Velocity". Diese Werte sind sehr hilfreich um diverse Situationen sehr früh zu erkennen, z.B.: Offenes Relay Dann haben Sie sehr schnell sehr viele Mails, wobei hier auch das Messagetracking ausgewertet werden kann. Unterbrochene Connectoren So erkennen Sie, wenn andere Systeme nicht erreichbar sind, z.B. Faxserver, ERP-System etc. BadMails Es gibt auch Mails bei denen Exchange einen Fehler bei der Verarbeitung hat und diese in eine BadMail-Queue legt. Bei dem Y2K22-Bug wäre so sehr schnell aufgefallen, dass die "Submission Queue" laufend zunimmt, d.h. es wäre sicher der "absolute" als auch der "differenzielle" Warn-Wert erreicht worden.
End2End-Mail	Queues und Eventlog sagen aber wenige aus, wenn wie an einem Feiertag eher wenig Mails übertragen werden oder die Fehlermeldungen erst mal auf "später" zurückgestellt werden. Daher ist es immer ratsam auch ein paar echte Applikationstests zu machen, z.B. indem Sie alle 10 Minuten eine Testnachricht an die verschiedenen Gegenstellen senden und die Rückantwort (Zugestellt-Quittung als auch NDR-Quittung) auswerten. Bleibt die Meldung aus, dann klemmt es irgendwo. End2End-SMTPFlow Mit SMTP-Sensoren ausgehende E-Mails monitoren https://www.paessler.com/de/smtp-monitoring
Exchange Health	Exchange hat auch ein "Selbst Monitoring". Allerdings hat beidem Fehler kein Report angeschlagen. Der Status meines Servers ist "Healthy" und der letzte Wechsel ist schon fast 18 Monate her. [PS] C:\>Get-HealthReport nawex16 -HealthSet fips Server State HealthSet AlertValue LastTransitionTime MonitorCount ------ ----- --------- ---------- ------------------ ------------ ex16 NotApplicable FIPS Healthy 11.03.2020 22:11:47 6 Auch wenn hier der Report nicht geholfen hat, sollten Sie die Funktionen von Exchange nutzen, die "Gesundheit" auszuwerten. Exchange 2013 Managed Availability Verwaltete Verfügbarkeit https://docs.microsoft.com/de-de/exchange/high-availability/managed-availability/managed-availability
FIPS	Zuletzt sollten Sie auch noch prüfen, wie aktuell ihr Patternfile ist. Es könnte ja sein, dass die Updates gar nicht mehr funktionieren. Am einfachsten geht das mit einer administrativen PowerShell. Add-PSSnapin Microsoft.Forefront.Filtering.Management.Powershell Get-EngineUpdateInformation Die Rückgabe liefert nicht nur die Version sondern auch den letzten Updatestatus und das Datum. Hinweis: Die laufende Nummer des "UpdateStatus" folgt nicht mehr dem Schema YYMMDDxxxx.

Diese Möglichkeiten der Überwachung sollen nun aber nicht davon ablenken, dass das Problem bei Microsoft zu suchen ist und von dort auch eine Lösung kommen muss. Aber Monitoring hilft sehr schnell den Start, die Existenz und das Ausmaß einer Störung zu erfassen und auch die erfolgreiche Entstörung schnell erkennen zu können.

Auf der anderen Seite haben die Firmen, die mangels 24x7-Operating schon Exchange Online mit direkten Ein/Ausgang über die Cloud (Kein Hybrid Centralized Mail Transport) natürlich dieses Problem nicht.

Beifang

Auf der Seite Alte OWA-Dateien löschen habe ich ja schon einmal beschrieben, dass man ältere Versionen von Dateien auch entfernen kann. Bei der Suche nach den Engine-Updates bin ich auf folgendes Verzeichnis gestoßen.

C:\Program Files\Microsoft\Exchange Server\V15\FIP-FS\Data\ProgramLogArchive

Es hat ca. 1 GB alte ETL-Traces, die anscheinend auch niemand wegräumt.

Schauen Sie vielleicht einmal, ob sich bei ihnen hier auch große Datenmengen angesammelt haben.

Nach dem Spiel ist vor dem Spiel

Nachdem wir nun das "Jahr 2000"-Problem und nun auch das Januar 2022-Problem überstanden haben, sollten wir uns nicht so früh freuen. Wenn nichts passiert, dann erlebe ich auch noch die nächste Schaltschwelle, die uns Programmierer in den Weg gelegt haben.

"Many network protocols and filesystems store timestamps in the original UNIX format: a signed 32-bit integer representing the number of seconds since the beginning of 1970. This format will expire in 2038. Other protocols store timestamps as unsigned 32-bit integers representing the number of seconds since 1900; this format will expire in 2036."
Quelle: https://cr.yp.to/libtai/tai64.html

WireGuard als relativ junges Protokoll nutzt daher schon TAI64