[English]Ziemliches Desaster für Administratoren von Microsoft Exchange Server 2016- und 2019-Systemen, die die Sicherheitsupdates vom 12. November 2024 installiert haben. Die Transportregeln funktionieren im Anschluss nicht mehr. Nun hat Microsoft die Bereitstellung der November 2024-Sicherheitsupdates zum 14. 11. 2024 gestoppt, um die Probleme zu untersuchen.
Anzeige
Die November 2024-Updates
Microsoft hatte zum 12. November 2024 Sicherheits-Updates (SU) für Exchange Server 2016 und 2019 veröffentlicht. Diese Updates sollen Schwachstellen, die durch Microsoft oder Sicherheitspartner in Exchange Server gefunden wurden, schließen. Zudem werden einige neue Funktionen wie Verbesserungen bei der Exchange Server AMSI-Integration oder Warnung vor Spoofing-E-Mails eingeführt. Ich hatte im Blog-Beitrag Microsoft Exchange Server Updates 12. November 2024 berichtet.
Transportregeln funktionieren nicht mehr
Hier im Blog gab es zum 14. November 2024 diesen Kommentar, der berichtete, dass die Transportregeln zum Kennzeichnen von Mails nach Installation der Sicherheitsupdates KB5044062 vom November 2024 nicht mehr funktionieren. Die Anwendung solcher Regeln zur Kennzeichnung von Mails ist hier an einem Beispiel erläutert.
Im Kommentarbereich des Blog-Beitrag Microsoft Exchange Server Updates 12. November 2024 bestätigen viele Administratoren, dass die Transportregeln nach Installation des Updates nicht mehr funktionieren.
Es gab zwar den Tipp, den Dienst MSExchangeTransport neu zu starten. Das hilft aber nur temporär, die Transportregeln funktionieren lediglich für etwa 30 bis 60 Minuten wieder.
Anzeige
Auf reddit.com gibt es diesen Thread, der die gleichen Probleme mit nicht funktionierenden Transportregeln beklagt. Weiterhin weist auch dieser Kommentar zum Techcommunity-Beitrag Released: November 2024 Exchange Server Security Updates auf das Problem mit den kaputten Transportregeln hin.
Microsoft setzt die Updates temporär aus
Zum Nachmittag (MEZ) des 14. November 2024 gab es dann von Microsoft die Meldung im Techcommunity-Beitrag Released: November 2024 Exchange Server Security Updates, dass das Rollout der November 2024-Sicherheitsupdates gestoppt sei.
Der Download der SU-Pakete wurde temporär von den Microsoft-Servern entfernt und das Rollout auch über Windows Update gestoppt. Microsoft untersucht die oben beschriebenen Probleme und wird die SU-Pakete so bald als möglich wieder freigeben.
Im Techcommunity-Beitrag wurde zwischenzeitlich ein "Know issues"-Eintrag ergänzt. Dort heißt es, dass bei Kunden die Transportregeln nach der Installation dieses Updates in regelmäßigen Abständen angehalten werden. Nach ersten Untersuchungen kann dies bei Kunden auftreten, die ihre eigenen Transport- oder DLP-Regeln verwenden. Wenn dieses Problem bei auftritt, müssen Administratoren möglicherweise die November-SU deinstallieren, bis diese erneut veröffentlicht werden.
Ähnliche Artikel:
Microsoft Security Update Summary (12. November 2024)
Patchday: Windows 10/Server-Updates (12. November 2024)
Patchday: Windows 11/Server 2022-Updates (12. November 2024)
Patchday: Windows Server 2012 / R2 und Windows 7 (12. November 2024)
Anzeige
Sieht nach Amok-KI-Spaghetti-Code-Programmierung aus. Ich denke da braucht es noch mehr AKWs, bis das bei M$ mal harmoniert. In der Klaud wäre das übrigens nicht passiert.
Na dann werde ich das geplante Update beim Kunden heute gleich mal verschieben. Gut, daß ich hier davon lese.
Update am Freitag? Wo gibt es denn sowas…
Bei jedem Student der etwas mit Medien machen will und am Ende nicht mal Windows installieren kann. (Selbst erlebt)
Der Wochentag spielt doch keine Rolle.
Doch ein Update am Freitag kann das ganze Wochenende versauen.
Dann lieber montags und den Kunden 2-3 Arbeitstage lahmlegen….
Ist man durch die "gute" MS Software ja mittlerweile gewohnt.
Dilemma: Sofort patchen oder nicht. Mit dem sofortigen Einspielen aller Patches kann man seine Infrastruktur abschießen. Wartet man zu lange kann es auch böse enden. Die Frage ist doch wofür die Hersteller eigentlich Geld bekommen. Für den Mist den sie fabrizieren, sollten sie den Kunden Entschädigung zahlen müssen. Bleibt zu hoffen, daß die neue Produkthaftungsrichtlinie auch die Softwarehersteller entsprechend schadenersatzpflichtig macht.
Ich würde mir wünschen das einige "Namhafte" Konzerne jetzt mit der neuen Produkthaftung mal so richtig an die Eier genommen werden….. es ist teilweise kaum noch zu ertragen, was für einen Schrott die Hersteller, ganz vorne MS mittlerweile auf den Markt werfen…
weiß jemand wie man das SU deinstallieren kann per Commandline? Wir haben Exchange 2019 Server Core und die gängigen Methoden über wusa uninstall, msiexec oder uninstall-package funktionieren nicht
Exchange SUs sind idR nicht entfernbar, demnach müsste ein BackUp zurückgespielt werden.
per CMD (nicht PS!)
msiexec /i {CD981244-E9B8-405A-9026-6AEB9DCEF1F1} MSIPATCHREMOVE={12cff7a6-ce91-419c-82cd-2f4251dec686}
Quelle: registry
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Patch
warum das nicht per
wusa /uninstall /kb:…
oder per Uninstall-Package
geht weiß der Henker
Bei mir im WSUS wurde das Update auf nicht freigegeben geändert. Da schein MS ja mal was richtig gemacht zu haben :-)
Wieder mal gut, etwas zu warten mit der Installation!
Exchange-Updates sollte man nicht automatisch installieren lassen!
Also auch nicht per WSUS verteilen.
Best Practice bei Exchange-Updates ist es, die Updates von Microsoft Update Catalog herunterzuladen und dann manuell zu installieren.
leider kann man diese EX Patche nicht per WSUS deinstallieren. Muss man also wenn diese schon installiert sind per Hand machen
Ich wüsste nicht, warum man das nicht tun sollte. Ob man das Paket manuell ausführt, oder es nach Freigabe im WSUS startet oder automatisch installieren lässt, es ist immer dasselbe Update.
Schlimm genug, dass man seit 2016 die CUs manuell installieren muss und es jedes Mal komplette Neuinstallationen sind, so dass man stundenlang mit Warten (und Hoffen) beschäftigt ist.
Bei den SUs gebe ich mir das ganz bestimmt nicht, war auch nie ein Problem.
Weil es wie anderswo geschrieben mit Installation über Windows Update/WSUS immer wieder Probleme gibt. Komischerweise treten diese Probleme dann nicht auf, wenn man es händisch installiert. Es mag das selbe Update sein, aber das Format ist unterschiedlich und es verhält sich definitiv nicht identisch.
Daher installiere ich Exchange Updates immer von Hand und bisher bin ich damit immer gut gefahren.
Ich kann nur aus eigner Erfahrung berichten dass es sich sehr bewährt hat, VOR der Installation eines Exchange SU bzw. auch CU a) den Wartungsmodus zu aktivieren, b) einen Reboot durchzuführen, c) den AV zu deaktivieren und d) die Installation der "Exchange20xx-KBxyz.exe" in einer CMD im Admin-Kontext zu starten. Damit hatten wir bisher noch niemals Probleme und es kostet nicht extrem viel Zeit. Dies ist aber sicherlich mit einer Windows-Update-Installation (zumal unter WinServer 2016 ja direkt nach der Suche unmittelbar das gefundene Update installiert wird) sicher nur schwer möglich – und eben eine mögliche Fehlerquelle. Wir halten uns strikt an den o.g. Ablauf und hatten bisher immer saubere Installationsvorgänge, daher kann ich das nur empfehlen.
Kann ich nur bestätigen, die oben genannten Punkte sind leider notwendig, helfen aber. Von einer Installation via WSUS ist grundsätzlich abzuraten!
Seit Exchange 2010 bis heute nie Probleme mit WSUS und Exchange gehabt.
Ich würde sagen: "Von einer Installation via WSUS ist grundsätzlich abzuraten!" gehört eher in die Kategorie Mythen und Gerüchte.
DANKE für diese Info – ein Glück, das ich diese Woche keine Zeit hatte, die Updates einzuspielen. Manchmal hat Stress auch was Positives :-)
Als Notlösung starten wir den Transport Service jetzt automatisch jede Stunde neu. Soweit scheint das ohne Nachteile zu funktionieren und die Regeln werden wieder angewendet.
Inzwischen kann man glaub ich jedes Microsoft Produkt und Update als "Bananaware" (Software reift beim Kunden) abstempeln.
Ich kann mich nicht erinnern wann der letzte Patchday war wo man nichts von Problemen gelesen oder selbst erlebt hat.
Wie gern würde ich komplett auf Linux bzw. OSS umstellen aber es gibt soviel Software die da eben nicht läuft…
Deshalb wurschteln wir weiter bis gar nichts mehr geht…
in diesem Sinne schönes Wochenende.
Es ist kein Problem, dass sich nur bei Microsofts Produkte manifestiert. <Deren Software ist allerdings weit verbreitet und es gibt sehr viele Produkte von denen.
Ich kenne andere Systeme und die sin auch nicht besser aufgestellt.
Und selbst wenn der OSS /Linux solche Produkte bereitstellen würden, wären Probleme dennoch vorhanden. Die nennen sich nur anders. Machen wir uns doch nichts vor. Die Systeme werden immer komplexer und die Software-Produkte müssen immer schneller am Markt verfügbar sein. Bei Updates kommt noch die Sicherheitskomponente dazu. Sicherheit / Fehlerarmut steht der kurzen Marktverfügbarkeit entgegen. Grobe Fehler und aus Zeit- und Kostengründen gewählte suboptimale Designs sind die Folge. Ich hoffe, dass uns die KI bei der QS der Produkte zukünftig etwas mehr helfen wird, Fehler in der Logik des Programms zu reduzieren. Fehler in den Libraries und Compiler wäre hier ganz sicher hilfreich. Wenn dann noch RUST statt C/C++ in der Entwicklung Verwendung findet, könnte es tatsächlich mal besser werden.
Während der Fehlersuche bin ich auf einen sanfteren Workaround gekommen als einen Neustart des Transport Dienstes. Nachdem ich eine neue Nachrichtenflussregel angelegt hatte, funktionierten plötzlich alle Regeln wieder…für kurze Zeit.
Das hat mich auf die Vermutung gebracht, dass eine Änderung an den Nachrichtenflussregeln einen Reload der Dienstkonfiguration auslöst und diesen wieder zur Normalfunktion bringt.
Anstatt also den Dienst per Skript neu zu starten habe ich eine beliebige Nachrichtenflussregel angelegt, die ich per Skript alle 30 Minuten deaktiviere und gleich wieder aktiviere (Disable-TransportRule / Enable-TransportRule)