[English]Nachdem das Sicherheitsupdate für den Monat August 2023 für Exchange 2016 und 2019 bei nicht englischen Installationen mit massiven Installationen Wellen geschlagen hat, musste Microsoft reagieren. Die Updates für deutsche Exchange-Installationen wurden zurückgezogen, und es gibt von Microsoft einen Workaround, um den Patch manuell zu installieren. Jetzt informierte mich ein Blog-Leser, dass auch die englischen Sicherheitsupdates zurückgezogen wurden. Zudem hat Microsoft eine entscheidende Änderung am Workaround vorgenommen, der neu angelegte AD-Account darf nicht mehr gelöscht werden. Ein weiterer Blog-Leser hat mich auf einen Bug hingewiesen, der nach dem Update auftritt. Ergänzung: Zum 16. August 2023 (deutscher Zeit, 15.8.2023 US-Zeit) sind neue Versionen der Updates bereitgestellt worden.
Anzeige
Rückblick auf das August 2023 Patch-Desaster
Microsoft hat zum 8. August 2023 Sicherheitsupdates für On-Premises Exchange Server 2016 und 2019 veröffentlicht, um mehrere Sicherheitslücken zu schließen. Ich hatte im Blog-Beitrag Microsoft Security Update Summary (8. August 2023) berichtet und auch Hinweise zu den Schwachstellen gegeben. Bereits kurz nach Freigabe der Sicherheitsupdates für August 2023 bzw. fast zeitgleich mit der Veröffentlichung meines Blog-Beitrags machten deutsche Administratoren die betrübliche Feststellung, dass sich die Updates nicht unter deutschsprachigen Exchange Servern installieren ließen.
Ich hatte daher im Blog-Beitrag Desaster Exchange August 2023-Sicherheitsupdate – nicht installieren! davor gewarnt, diese Sicherheitsupdates zu installieren. Später wurde von Microsoft ein Workaround veröffentlicht, mit dem sich ein vorhandenes nicht englisches Update mit manuellen Eingriffen installieren lassen sollte. Die Details finden sich in meinem Blog-Beitrag Workaround für Exchange August 2023 Sicherheits-Update Installationsprobleme. Gleichzeitig wurden die deutschen Sicherheitsupdates für Exchange Server 2016/2019 zurückgezogen. Administratoren warteten seitdem auf die Freigabe eines revidierten Sicherheitsupdates, welches sich installieren lässt und mit dem der Exchange Server auch noch funktioniert.
Updates zurückgezogen; Workaround geändert
Es deutet sich an, dass das Patch-Desaster rund um die Exchange Sicherheitsupdates noch größer als befürchtet ist. Stefan K. hat mich vor einigen Stunden per Mail kontaktiert, und seine neuesten Beobachtungen mitgeteilt (danke dafür). Ich gebe mal seine Informationen weiter:
Neue Infos zum Exchange Update / Workaround geändert
Moin Günter,
ich wollte heute Abend unseren Exchange Server 2016 CU23 auf das SU9 per Workaround patchen. Da der Server im Backend steht und aus dem Internet nicht erreichbar ist, haben wir bis jetzt auf einen aktualisierten Patch gehofft.
Zwei Dinge haben mich überrascht:
1. Offenbar ist auch der Download des englischen Patches aus dem Internet verschwunden. Ich finde nichts mehr das nicht auf einen 404 Fehler läuft.
Ich habe es beim Schreiben des Blog-Beitrags ebenfalls geprüft, die Sicherheitsupdates sind zurückgezogen. Da deutet sich doch ein größeres Problem mit den August 2023 SU für Exchange 2016/2019 an. Und es gibt eine weitere Neuigkeit, die Stefan erwähnt:
Anzeige
2. Des Weiteren hat Microsoft wohl die Anleitung zum Workaround geändert. Unter Schritt 6 heißt es nun:
Speziell der letzte Punkt, hier als Schritt 6 bezeichnet, könnte für einige Administratoren von Wichtigkeit sein. Denn in der alten Fassung wies Microsoft die Leute noch an, den neuen AD Account nach der Installation des Sicherheitsupdates wieder zu löschen.
Neue Update-Versionen verfügbar
Ergänzung: Zum 15. August 2023 (16. August deutscher Zeit) sind neue Versionen der Updates verfügbar, wie inzwischen aus den nachfolgenden Kommentaren hervorgeht. Die Updates sind im Techcommunity-Beitrag Released: August 2023 Exchange Server Security Updates neu verlinkt worden;
Der neue Techcommunity-Beitrag Re-release of August 2023 Exchange Server Security Update packages dokumentiert, welche Änderungen Microsoft vorgenommen hat. So soll das Update V2 auf jeden Fall installiert werden. Gab es Probleme mit der Version 1, ist diese zu deinstallieren, und der Exchange-Server neu zu starten, bevor der neue Patch in der Version 2 installiert wird.
Probleme mit Patch
Blog-Leser Andreas G. hat mich noch per Mail auf ein Problem (bisher mit der V1 des Updates) hingewiesen:
Hallo Herr Born,
vielleicht ist das für Sie oder ihre Leser relevant/interessant, aber vielleicht tritt der Fehler auch nur bei uns auf…
Seit wir unseren On-Prem Exchange 2019 (Deutsch) auf CU13 SU2 aktualisiert haben, hat die Exchange Weboberfläche Probleme mit Benutzernamen wo ein Leerzeichen enthalten ist.
Ein abspeichern von Änderungen wie z.B. E-Mail Weiterleitungen ist somit nicht mehr möglich.
Wir behelfen uns aktuell damit, in der Weboberfläche das Leerzeichen zu entfernen und unter Active Directory Benutzer und Computer dies wieder hinzuzufügen.
Ergänzung 2: In diesem Kommentar zum Techcommunity-Beitrag beklagt , dass sie das Zertifikat nach dem Upgrade auf die neueste Version nicht mehr erneuern können. In den Kommentaren gibt es Hinweise, wie sich das lösen lässt. Weiterhin bemängelt ein Nutzer in diesem Kommentar, dass das alte Update V1 noch am WSUS angeboten wird. Noch jemand, dem das aufgefallen ist?
Ähnliche Artikel:
Microsoft Security Update Summary (8. August 2023)
Patchday: Windows 10-Updates (8. August 2023)
Patchday: Windows 11/Server 2022-Updates (8. August 2023)
Exchange Server Sicherheitsupdates (8. August 2023)
Desaster Exchange August 2023-Sicherheitsupdate – nicht installieren!
Workaround für Exchange August 2023 Sicherheits-Update Installationsprobleme
Anzeige
Na dann sind wir Mal gespannt wann "soon" ist ;)
————–
Nino Bilic
Microsoft
Aug 15 2023 10:50 AM
We will have updates on this soon. Stay tuned…
————-
Warum, zum Teufel, halten alle große Kunden dieses "Softwarelieferanten" still, und verklagen MS nicht, für die Fehler der letzten Monate und Jahre, bis auf die blanken Knochen?
Ob die MS Mitarbeiter, Aktionäre und ihre Manager anschließend unter der Brücke schlafen oder den sprichwörtlichen Kitt aus den Fenstern fressen müssen, kümmert mich nicht im Geringsten … wir sollten als Dienstleister endlich die Samthandschuhe gegenüber MS ausziehen … und ich bin ein freundlicher Mensch …
Ohne jetzt eine politische Diskussion anzetteln zu wollen: mir fallen hier in Deutschland etliche Personen und Institutionen ein, die noch viel schädlicher für die Wirtschaft sind…
Lag das Problem nicht primär darin, daß eine non-englische Windows-Basis-Installation dazu führt, dass die System-User in deutscher Sprache angelegt wurden, und nicht an der non-englischen Exchange-Version? Das Update hat den Bug, dass darin der Englische Display-Username verwendet wird anstatt der well-known SID.
Rein theoretisch sollte auf einem englischen Server auch mit einem deutschen Exchange dieses Problem nicht auftreten. Aber das wird ja wohl kaum gemacht jemand haben, außer im Labor.
Das Leerzeichen-Problem im Webinterface wird wohl auch die englische Version betreffen. Das würde die Rücknahme der englischen Version erklären.
Gibt's das Webinterface auch in der Cloud-Version?
Es wird ja eigentlich von seinem Einsatz abgeraten.
es gibt keine Sprachversion der Patches, es gibt nur eine Version für alle, deshalb wurde der Patch zurückgezogen damit keiner mit einer non-english Windows Server Version den versehentlich einspielen kann.
Ich weiß ja nicht so genau was da im Hintergrund läuft.
Ich könnte mir vorstellen, das da Geld im Hintergrund fließt.
Geld, das ein Linux-Consultant/Distributor nicht zur Verfügung hat. (Was ist eigentlich mit LiMux? Lange nichts davon gehört).
Aber ich habe bestimmt nur eine schmutzige Fantasie.
Dazu kommt das Millionenfliegen-Syndrom.
(Millionen Fliegen fressen Sch…warum sollten wir nicht?)
Dann MS ist der Standard. Welcher Cheffe wird sich für etwas anderes entschieden und dies gegenüber Gesellschaftern vertreten, wenn es schief geht, die Verantwortung übernehmen?
Wegen ein paar Euro Miete?
Das er jetzt er immer wieder keine E-Mails bekommen/schreiben kann freut ihn vielleicht sogar. Wenn nicht, wird er das seiner "unfähigen" IT anlasten, aber gewiss nicht MS. Da wird er drüber stehen. Wenn er seiner IT vertraut, dann wird er seine Server in die Cloud schieben. Da gibt es ja keine Probleme.
Das sieht zur Zeit ja so aus als sei das kostengünstiger als teuere Lokale Server mit eigenem, unkündbarem Personal zu betreiben. Das MS die Gebühren mit der Zeit immer mehr erhöhen wird interessiert ihn jetzt doch nicht.
Dann hat man dutzende Zusatzprodukte für etliche 10000sende.
Die müssen auch ersetzt werden.
Mal kurz die Produktions-Datenbank nebst Frontend von einem Windows auf Linux schieben?
Schau Dir die Katastrophe an, die bei der Deutschen Bank resp. Postbank läuft (oder halt nicht) die über 10 Jahre daran rumgedoktort haben und nun wohl zumindest einen strengen Verweis von der BaFin erwarten können und viele Kunden verloren haben.
Microsoft verdient Geld in diesem (Office) Bereich nur noch mit der Cloud und ein paar großen cloud-ähnlichen Installationen z.B. für die US-Regierung.
KMUs mit lokalen Installationen sind nicht mehr zeitgemäß nach ihrem Geschäftsmodell und kriegen das zunehmend zu spüren. Sie werden nur noch widerwillig supported (lokaler Skype-for-Business-Server, anyone?).
Die Preisschrauben sind absolut kein Argument, da das OnPrem genauso passiert und gemacht wird, das hat nix mit Cloud zu tun außer du willst Software außerhalb von jeglichem Support betreiben, dann musst natürlich nicht upgraden.
Man kann danna also nur von einem Hersteller zum nächsten gehen, aber viele gibt's da ja leider nicht die den Funktionsumfang zB wie Exchange abdecken. Und endet dann zB wie Anydesk und Teamviewer, die sich preislich nun wieder annähern, obwohl Anydesk langezeit als die kostengünstige Alternative gefeiert wurde.
Jetzt gibts einen neuen Tech Community Artikel:
Re-release of August 2023 Exchange Server Security Update packages
Interessant ist, dass alle, die den Workaround genutzt haben, dass SUv1 deinstallieren müssen und danach das neue SUv2 wieder installieren müssen. Sonst wird zukünftig immer der Dummy "Network Service" Account benötigt.
https://techcommunity.microsoft.com/t5/exchange-team-blog/re-release-of-august-2023-exchange-server-security-update/ba-p/3900025
Danke, ich habe es nachgetragen, hat dann zwischen dem Posten meines Beitrags und dem Update durch Microsoft nicht lange gedauert.
Im oben angesprochenen Microsoft-Blog steht:
"To help you understand the actions needed, we use the following naming convention to distinguish between the original August 2023 SU and the re-release:
* Aug SUv1: original August 2023 SU (released on 8/8/2023)
* Aug SUv2: re-released August 2023 SU (released on 8/15/2023)"
Hat hier schon jemand dieses SU v2 installiert und kann sagen, ob es sich jetzt problemärmer verhält? Der Beschreibung nach soll man es ja jetzt auf jede Mischform (OS EN/non-EN, Exchange EN/non-EN) installieren können.
auf dem wsus ist das kb503524 heute nacht wieder aufgetaucht
https://techcommunity.microsoft.com/t5/exchange-team-blog/re-release-of-august-2023-exchange-server-security-update/ba-p/3900025
Bei mir kam das auch im WSUS Sync, wird aber nicht als "unapproved" & "failed/needed" angezeigt, so als ob der Exchange Server mit dem Update nichts anfangen kann.
Das V1 war sichtbar, wurde dann aber zurückgezogen.
Wird Dir das bei Dir auch nicht angezeigt unter "unapproved" & "failed/needed"?
v1 wurde automatisch (so hab ich es eingestellt) "declined" nachdem MS es zurückgezogen hatte.
v1 hatte ich aber vorher schon ohne Probleme installiert, da ich nur engl. server verwende.
v2 wird trotzdem für die EX2016 die bereits das v1 haben als "needed" gefunden.
v2 läst sich problemlos darauf installieren (was MS im KB als "optional" auch beschreibt)
Kann ich nicht bestätigen.
Nach der Update-Synchronisierung des WSUS von letzter Nacht wird das "Security Update For Exchange Server 2016 CU23 (KB5030524)" von unserem Exchange Server als erforderlich erkannt.
Wobei wir (begründet aus negativen Erfahrungen in der Vergangenheit) Updates für Exchange und MS SQL Server nicht über WSUS verteilen, sondern diese immer manuell herunterladen und installieren.
Wolfgang Sommergut hat auf dem WindowsPro Blog heute noch eine Artikel veröffentlicht, siehe:
https://www.windowspro.de/news/microsoft-ersetzt-fehlerhafte-exchange-security-updates-sus-fuer-august/05471.html
Wichtig!
Die SUs für Exchange 2016 und 2019 beheben unter anderem CVE-2023-21709, wofür allerdings zusätzlich die Ausführung eines PowerShell-Scripts erforderlich ist, siehe:
https://microsoft.github.io/CSS-Exchange/Security/CVE-2023-21709/
Kein Wunder läuft bei MS vieles schief
https://harrisbricken.com/de/cannabis-in-washington/
Das betroffene SU wurde in v2 released. Siehe
Auf ein Neues….
Details:
https://techcommunity.microsoft.com/t5/exchange-team-blog/re-release-of-august-2023-exchange-server-security-update/ba-p/3900025
Hallo Günther, das alte Update (auch Englisch) wurde zurückgezogen, da ein neues veröffentlicht wurde. Es ist z.B. das Security Update For Exchange Server 2016 CU23 SU9V2 (KB5030524).
VG,
ZAcho
Leider hat der WSUS da Dinge nicht mitbekommen.
Für Exchange 2016 steht jetzt das "defekte" SU vom 08.08 KB5029388 sowie das neue KB5030524 zur Verfügung. Laut WSUS ersetzt aber v2 nicht die v1 daher wird v1 auch noch an die Server ausgerollt.
Das stimmt so nicht. Die v1 wurde doch (auch für den WSUS) am 9.8 zurückgezogen und sollte daher schon längst auf "declined" stehen! Wenn du das nicht automatisch machen läßt müsstest du dich schon selbst drum kümmern.
Kann ich bestätigen, V1 wurde am WSUS automatisch zurückgezogen.
V2 wurde zwar gesynct, scheint nun aber nicht unter "not approved" & "failed/needed" auf, was mich stutzig macht.
Zu den 2016ern kann ich nichts sagen, die sind hier über die Optionen abgewählt.
Bei den 2019ern sieht hier aber alles korrekt aus. Die neue Version wurde letzte Nacht bei der Synchronisation heruntergeladen und erscheint im WSUS auch unter "Alle" / Erforderlich" / "Fehlerhaft oder Erforderlich" (wir haben hier die DE-Version in Betrieb).
Die Vorgängerversion hatte ich wegen der Probleme manuell auf "Abgelehnt" gestellt, die erscheint in der Liste "Abgelehnt" immer noch, wird jetzt aber zusätzlich als "abgelaufen" und "nicht für die Installation genehmigbar" gekennzeichnet.
Sieht soweit alles völlig ok aus.
Das kann ich bestätigen. Die 2019er SUs wurden hier auch zurückgezogen und das 2016er SU nicht. Hab mich da auch schon etwas gewundert…
Das Update v2 ist installiert und ich konnte keine negativen Effekte feststellen. Scheint daher zu laufen.
du hattest vorher keinen Workaround gemacht? also hast gewartet?
also quasi gewartet auf das neue v2 Update ? und vorher nicht das defekte Update installiert ?
Um eine korrekte Entscheidung treffen zu können, gibt es eine lecker "if-and-then" Tabelle:
https://techcommunity.microsoft.com/t5/exchange-team-blog/re-release-of-august-2023-exchange-server-security-update/ba-p/3900025
Wenn's nicht so traurig wäre, könnte man sich wirkich gut belustigen.
Warum hab ich so Angst vor der Installation…?
Hallo citizen, danke dir – das habe ich schon in der Theorie gelesen.
Möchte aber gerne von Cedric Fischer | CeFiSystem die Praxiserfahrung wissen :) ?
Na Prima, läuft ja bei Microsoft.
Wir haben die Version 1 des August Update auf dem 2019er CU13 Exchange mit Workaround installiert. Läuft soweit auch.
Die AD User hatten nicht gelöscht, soll man ja wohl auch nicht mehr machen!
Soll man jetzt einfach die V2 des Updates drüberschieben oder doch erst wieder die V1 deinstallieren und dann die V2 drauf?
Und wie verhält es sich ( sollte eine Deinstallation der V1 notwendig sein ) mit dem dafür angelegten Dummy AD User`?
Schöner Mist von MS und danke an alle die hier Ihre Erfahrungen Teilen.
Danke an Citizen für die What-IF Tablle:
https://techcommunity.microsoft.com/t5/exchange-team-blog/re-release-of-august-2023-exchange-server-security-update/ba-p/3900025
Demnach können wir einfach die V2 ( müssen aber nicht ) drüberschieben.
In einer Testumgebung habe ich das auf gerade per Manueller installation gemacht. Das lief sauer durch und nach dem Neustart des Server wurde die Buildnummer korrekt angehoben und der Exchange lief auf den ersten Blick normal.
Ich verstehe das so, wenn du das V2 „drüberschiebst", ohne das V1 zu deinstallieren, dann bist du zukünftig weiterhin auf den Dummy Account angewiesen.
Folgendes ist in den FAQs zu lesen:
What would happen if we installed the Aug SUv1 by following the workaround and don't uninstall it as recommended?
If you're running Exchange Server on a non-English OS and were only able to install the Aug SUv1 by following the workaround we provided, you should uninstall the Aug SUv1 first. If you don't remove the Aug SUv1, the requirement for the dummy "Network Service" account will remain and persist with any future SUs that are applied to the CU version that is installed on the machine.
In other words: If you used the workaround, and don't uninstall Aug SUv1 but you delete the "Network Service" dummy account, then installation of Aug SUv2 (or later SUs) will fail with the same behavior as Aug SUv1.
Guten Morgen zusammen,
eine kurze Story aus der "Externer-IT-Admin-Real-World" :=)
Ein Kunde reif mich heute, am 16.8. um 9:10 Uhr an dass die Clients nicht mehr auf den Exchange zugreifen können. Zu Arbeitsbeginn heute um 6 Uhr war der Exchange noch erreichbar.
Sinngemäßer Anruf des Kunden: "Auf dem Exchange läuft ein Update und steht schon länger bei 92%, was soll er tun? Abbrechen??? …. Hart ausschalten ???"
Ich: "NEEEEEEEEEEIIIIIIN … bloß nicht! Laufen lassen!" … 15 Min. später war der Exchange wieder verfügbar. Der Server hatte aber KEINEN vollständigen reboot gemacht soweit ich das an der Uptime sehen konnte.
Folgendes steht im Updateverlauf:
Security Update For Exchange Server 2016 CU23 (KB5030524)
Erfolgreich installiert am 16.08.2023
2023-08 Kumulatives Update für .NET Framework 4.8 für Windows Server 2016 für x64 (KB5028952)
Erfordert einen Neustart, um die Installation abzuschließen
2023-08 Cumulative Update for Windows Server 2016 for x64-based Systems (KB5029242)
Erfordert einen Neustart, um die Installation abzuschließen
>>>>>>> Nutzungszeit ist 06:00 bis 18:00 Uhr
Wie kann es sein dass der Exchange MITTEN IN DER NUTZUNGSZEIT das Zeugs installiert und meine Clients rauskickt? :-(
Hab ich die letzten 42 Jahre noch nicht erlebt.
Danke für eure Hilfe und Info.
Euch allen noch ein möglichst "exchange-sorgloses" Leben
Gerd
Die Nutzungszeit gilt nur für Updates für Windows selbst, nicht für Updates sonstiger Software. Und zu sonstiger Software gehört auch z.B. der Exchange, SQL-Server, etc.
Und dieses "Nutzungszeit" ist ja auch neu seit Windows 10/Server 2016.
Vorher gabs das schlicht nicht.
Diese Nutzungszeit sorgt aber nur für Probleme, zumindest auf Desktops.
Denn in der Nutzungszeit erfolgt kein Neustart und außerhalb der Nutzungszeit sind die Desktops heruntergefahren, also passiert da kein Neustart nach dem Update.
Und nach 7 Tagen macht der PC dann einen Zwangs-Neustart auch in der Nutzungszeit.
Das Verhalten von Windows 7/8 fand ich da deutlich besser:
Updateinstallation beim Herunterfahren/Starten.
Da sind dann die Windows-Updates spätestens am nächsten Arbeitstag installiert und nicht erst nach 1 Woche. Und es unterbricht auch nicht die Arbeitszeit.
Bei Server 2008 bis 2012R2 konnte man eine exakte Uhrzeit festlegen, wann der Neustart statt finden soll, z.B. 4 Uhr morgens.
Das Update wurde vom Kunden entweder manuell installiert bzw. aktiv auf "Updates suchen" geklickt. Oder die GPOs für den WSUS sind nicht korrekt.
Ein Admin hatte hier mal während meines Urlaubs die GPO angepasst und damit exakt das von Dir beschriebene Verhalten ausgelöst:
Configure automatic updating: 4 – Auto download and schedule the install
The following settings are only required and applicable if 4 is selected.
Install during automatic maintenance ENABLED
Scheduled install day: 5 – Every Thursday
Scheduled install time: 01:00
If you have selected "4 – Auto download and schedule the install" for your scheduled install day and specified a schedule, you also have the option to limit updating to a weekly, bi-weekly or monthly occurrence, using the options below:
Every week Enabled
"Install during automatic maintenance" muss unbedingt auf DISABLED stehen, da sonst die anderen Einstellungen nicht beachtet werden!
Das wirkt irgendwie so, als würde dic Update-Installation abzüglich des Neustarts zu beliebeigen Zeiten durchgeführt und erst der System-Neustart außerhalb der Nutzungszeit ausgeführt, kann das sein?
Das hieße allerdings auch, dass die Installation von Updates immer automatisch durchgeführt wird. Ist das unbedingt erforderlich?
Bei uns wurden beide Updates angeboten, KB5029388 v. 09.08.2023 und KB5030524 v. 16.08.2023.
Letzter Sync heute 05:41 Uhr.
Installiert, funktioniert bisher problemlos.
Ich habe den Patch heute installiert. Ausgangslage:
– Exchange Server 2016 CU23 SU8 auf Windows Server 2016
– Active Directory, Exchange und alle Server sind deutsche Versionen
Server vor den Update mit HealthChecker geprüft. Updates für HealthChecker gemacht. Es gibt eine neue Version 23.08.15.2342. Server auf "Pending Reboot" geprüft.
Deutsche Version des Updates in der Version SU9V2 (KB5030524) manuell aus einer elevated Shell angeschoben und dieses ist ohne Probleme installiert worden. Wie immer am Ende einen Reboot gemacht.
Health Checker meldet nach dem Update noch CVE-2023-21709. Das Skript von Microsoft in einer EMS-Shell als Admin gestartet -> Success -> Heath Checker glücklich
Bzgl. AES256-CBC bleibt ein gelber Eintrag zurück. Wurde nicht addressiert, da der Server On-Prem ohne Verbindung zu Azure oder M365 betrieben wird.
Zertifikate waren nach dem Update sauber, ich müsste aber auch nichts erneuern. Das Thema mit dem Benutzeranmeldename existiert bei uns nicht, da es keine Benutzeranmeldenamen mit Leerzeichen gibt.
Gruß Singlethreaded
Installation auf Exchange 2019 mit Server 2022 erfolgreich.
Script führe ich noch aus. Was ist eigentlich RMS bzw. Purview Information Protection ?!
Hallo
Microsoft hat am Mittwoch neue Updates herausgegeben.
Server 2022 – Exchange 2019 deutsch
Nach immerhin 14 Minuten wurde ich zu einem Neustart aufgefordet
Mein Exchange-Server ist halt nicht der Schnellste
Alles paletti nun
so long
Yumper
Exchange Server 2019 mit V2 auf einem Windows Server 2022 erfolgreich gepatcht, ohne vorher den Workaround angewendet zu haben (warten war diesmal ne gute Entscheidung) und Script erfolgreich ausgeführt (auf deutscher Version)
Zu …2. Des Weiteren hat Microsoft wohl die Anleitung zum Workaround geändert. Unter Schritt 6 heißt es nun:…
Hierzu gibt's scheinbar wieder einen neuen Stand: die verlinkte Anleitung sieht inzwischen wieder anders aus. Nach Schritt 1 a / b / c wird in Schritt 2 gleich auf die Anleitung zur neuer Prozedur abgebogen.
Follow the steps in the re-release announcement for the August 8, 2023, SUs.
Es wäre schön gewesen, eine Vorwarnung zu erhalten, dass man das Update KB5030524 nicht einfach so auf einem funktionierenden Exchange Server installieren kann. Nach dem Durchlaufen der kompletten Katastrophe der V1 (KB5029388) inkl. Durchführung des händischen Workarounds (danach war ja alles wieder gut) hat unser WSUS nun V2 (KB5030524) gezogen und nachdem ich diese auf unserem Echchange 2016 CU23 installiert habe OHNE zuvor die V1 zu deinstallieren, passierte das gleiche Schlamassel wie mit der V1.Das ist nun echt nicht mehr spassig…
Habe daraufhin die ServiceControl.ps1 erneut durchlaufen lassen um dem Exchange wieder Leben einzuhauchen und im Anschluss die V1 deinstalliert, danach den Server gebootet und die V2 (KB5030524) erneut installiert.
Dieser zweite Versuch lief fehlerlos durch.
Im Anschluss noch die neuste HealthChecker Version 23.08.15.2342 durchlaufen lassen und den Punkt zu "Aktivieren der Unterstützung für AES256-CBC-verschlüsselte Inhalte in Exchange Server August 2023 SU" abgearbeitet. Nun ist auch das HealthChecker Resultat wieder durchgehend "grün".
Trotzdem graut mir schon jetzt vor dem nächsten Security Update und ich frage mich, wie lange ich es zukünftig aufschieben soll und in der Zwischenzeit die guten Foren (so wie dieses – Chapeau an dieser Stelle!) durchforsten muss, bis ich mich traue, das Update zu installieren…
Eben 2x Exchange 2016 auf WS2016 geupdated – direkt mit dem re-release, also dem v2.
Das v1 hatten wir übersprungen aufgrund der Probleme, die man lesen konnte.
Server jeweils 2x rebootet – zuerst für die Windows-Updates, dann fürs Exchange SU.
Keine Auffälligkeiten, alles normal, alle Dienste laufen nach Neustart, Zertifikate sind auch ok, Mailflow läuft.
Happy Weekend :)
Vor einigen Tagen habe ich den Workaround mit dem August Sicherheitsupdate v1 (KB5029388) in englischer Sprache auf meinem Exchange 2016 Server angewendet. Nachdem ich diesen Schritt ausgeführt hatte, entfernte ich das zuvor erstellte Network Service Konto. Am 17.08. wurde dann versucht, über die automatischen Updates das August Sicherheitsupdate v2 (KB5030524) zu installieren. Dies führte jedoch zu einem Fehler und die Exchange-Dienste wurden daraufhin deaktiviert.
Mein Versuch, das Update manuell zu installieren, scheiterte erneut. Daraufhin folgte ich den Anweisungen unter https://techcommunity.microsoft.com/t5/exchange-team-blog/re-release-of-august-2023-exchange-server-security-update/ba-p/3900025 wobei das etwas abweichend verlief:
1. Ich erstellte erneut das Network Service Konto.
2. Der Versuch, das v1 Sicherheitsupdate zu deinstallieren scheiterte mit einer verwirrenden Meldung auf das v2, obwohl dieses nicht installiert war. Nach mehreren Versuchen lief aber dann die Deinstallation vom v1 durch.
3. Nach einem Neustart entfernte ich erneut das Network Service Konto.
4. Ich installierte das v2 Sicherheitsupdate.
Trotz dieser Schritte waren bei mir die relevanten Exchange-Dienste weiterhin deaktiviert. Die Aktivierung mit dem Skript "ServiceControl.ps1 AfterPatch" verlief erfolglos, vermutlich weil die Dienste bereits zuvor deaktiviert waren. Es schien, dass dies mit meinem vorherigen Versuch, das v2 Update erneut zu installieren, zusammenhing. Daher war ich gezwungen, das PowerShell-Skript von https://blog.heeb-online.ch/Archive/668 zur Aktivierung der deaktivierten Exchange-Dienste zu verwenden. Nach der Anwendung dieses Skripts lief alles wieder wie gewohnt. Was mir nicht klar ist, ob auch der damalige im Workaround mit der ACL bleiben soll. Ich habe hierzu keine Hinweise gefunden.
Ja, der ACL-Workarround kann bleiben, weil bei der Installation der v1 ja die Rechte für den neu angelegten Benutzer "Network Service" erstellt werden. Die Rechte müssen aber auf den richtigen Benutzer "Netzwerkdienst" zeigen. Und das macht man mit dem Workarround.
Bei der Installation der v2 werden die Rechte für den richtigen Benutzer "Netzwerkdienst" angelegt, aber da die schon wegen des Workarrounds richtig sind, muß der Installer der v2 da nichts machen.
Und man muß den Workarround deswegen auch nicht rückgängig machen.
Diese ganze hin und her macht einen verrückt. AD User wieder löschen, dann doch nicht löschen.
Die V2 kann installiert werden muss nicht.
V2 kann einfach drüber installiert werden, muss aber nicht. Oder aber eben V1 muss vorher deinstalliert werden.
Was genau ist denn unserem Fall nun korrekt?
Wir hatten mit der V1 Probleme. Aber statt den Server mit Scripte wieder zum laufen zu bewegen, habe ich ich die Backup zurück geholt. Dann etwas gewaret und später stressfrei die V1 per Workaround installiert.
Zwischendrin hieß es ja dann der AD User soll bleiben.
Nun habe ich die V2 normal per Windowsupdate installieren können, ohne vorher die V1 zu deinstalliert. Das Update lief vollkommen normal und der Exchange läuft aktuell reibungslos.
Nein meiner Interpretation der Tabelle von Microsoft:
https://techcommunity.microsoft.com/t5/exchange-team-blog/re-release-of-august-2023-exchange-server-security-update/ba-p/3900025
habe ich mich in dieser Spalte gesehen:
"…was installed manually without any problems or issues"
Demnach auch die V2 optional drauf und gut.
Jetzt ist aber auch zu lesen das die V1 deinstalliert werden hätte müssen?
Hat hier jemand Infos?
Die der Punkt in der Tabelle von MS bei dem die V1 deinstalliert werden soll hat als Ausgangssituation:
"…failed during Setup, and left Exchange services disabled"
Durch die zurückgeholten Backup hatte unsere diesen zustand aber nie.
Wie gesagt die V2 läuft Problemlos soweit ich aktuell sagen und ich habe den AD user schlicht stehen lassen.
Vielen Dank für alle die sich dieser Fragen annehmen.
Ich hatte dir weiter oben einen Kommentar (16.08.) geschrieben, wie ich das verstehe:
https://www.borncity.com/blog/2023/08/15/exchange-server-august-2023-update-patches-zurckgezogen-workaround-erneut-gendert/#comment-154943
Ich verstehe die Zeile: "…was installed manually without any problems or issues…" so, dass es auf anhieb komplett ohne Workaround funktioniert hat (englisches AD).
Inzwischen wurde ja sogar nochmal eine Zeile in der Tabelle ergänzt, die die Vorgehensweise erklärt:
https://techcommunity.microsoft.com/t5/exchange-team-blog/re-release-of-august-2023-exchange-server-security-update/ba-p/3900025
Ich gehe davon aus, dass bei dir der "Network Service" Account noch existiert und nur deswegen V2 über V1 klappte.
Wir haben den Workaround bzw. V1 ausgelassen, daher kann ich dir hier nicht mit der Praxis helfen, nur wie ich es interpretieren würde!!
Danke Stefan A für deine erneute Antwort und sorry das ich diese Nachricht vom 16.08 gedanklich schlicht nicht einbezogen hatte.
Du hast recht, insgesamt wäre die V1 wohl besser zu deinstallieren gewesen.
MS beschreibt ja also Konsequenz lediglich der der Network-Service Nutzer dann halt für alle Zukünftigen Updates stehen bleiben müsste.
Ich sehe keinen Grund warum dies ein Problem sein sollte. Oder siehst du das anders?
Im Gegenteil, wenn es ein solches Problem (wenn auch unwahrscheinlich) mit falsch Lokalisierten Updates geben würde hätte ich dieses eher nicht.
Ich werde mir aber mal den Spaß machen in einer Testumgebung die V2 zu deinstallieren, dann den Nutzer löschen und die V2 wieder zu installieren und berichte im Anschluss, sollte ich heute noch schaffen.
Die Frage die sich mir noch stellt, sollte das normal klappen: Muss dann das CVE 2023 21709 Script nochmal laufen?
Nochmals Danke!!
Hallo nochmal,
ich habe inzwischen die Schritte auf einer Testumgebung ausgeführt.
Ausgangspunkt V2: (15.02.1258.025)
1. V2 Deinstalliert
Server war dann auf Stand V1: (15.02.1258.023)
2. V1 Deinstalliert
Server war dann auf Stand V1: (15.02.1258.016)
3. Dummy User aus AD gelöscht und Replikation abgewartet
4. V2 über CMD als Admin installiert (Server war nicht online und WSUS nicht in Testumgebung)
5. Neustart (Server nun wieder auf Version 15.02.1258.025)
Lief alles Problemlos.
Die Frage nach dem CVE 2023 21709 Script hat sich erledigt. Es ist entkoppelt von den Updates.
Demnach werden ich diese Schritte Vermutlich doch noch am Produktivsystem vornehmen.
Erneut danke an alle.
Hat noch jemand massive Probleme mit den Bug dass man keine Postfächer-Einstellungen mehr speichern kann innerhalb der EAC – wenn im Benutzeranmeldename Leerzeichen sind? Ist ziemlich uncool wenn man ~250 Benutzer hat, und alle haben ein Leerzeichen im Benutzeranmeldename (Vorname und Nachname auseinander geschrieben). Über das Problem liest man nahezu garnichts im Internet außer dass es hier mal mit "erwähnt" wurde. Gibt es da einen hotfix oder ist da etwas bekannt dass es ein folgeupdate geben wird, damit man auch die Postfächer wieder bearbeiten kann ohne die Benutzer vorher umzubenennen und danach wieder so zu benennen wie sie seit Jahren schon sind?
-V2 per Online Updates installiert (kein V1 vorher drauf gewesen), scheinbar keine Fehler mit Clients
– OWA + ECP hat nicht mehr gemacht außer Plain-Text anzuzeigen
– in den neu erstellten Versions-Ordnern unter ClientAccess vom OWA/ECP haben sämtliche Dateien welche die Seiten benötigen gefehlt