[English]Kleiner Nachtrag vom August 2023-Patchday, der Administratoren von Microsoft Exchange 2016/2019-Installationen zur Verzweiflung trieb. Auf nicht englischsprachigen Systemen klappte die Installation nicht und der Exchange-Server war danach teilweise tot. Ich hatte ja zeitnah in meinen Beiträgen gewarnt und von Microsoft wurden die Sicherheitsupdates August 2023 für Exchange wieder zurückgezogen. Nun hat Microsoft einen Supportbeitrag mit einem Workaround zu diesen Problemen veröffentlicht.
Anzeige
Update-Probleme mit August 2023-Updates
Bereits im Blog-Beitrag Exchange Server Sicherheitsupdates (8. August 2023) hatte ich darauf verwiesen, dass Benutzer in Deutschland massive Probleme bei der Installation der August 2023-Sicherheitsupdates für Exchange 2016/2019 hatten. Mit den Updates sollten folgende Schwachstellen geschlossen werden (siehe Microsoft Security Update Summary (8. August 2023)):
- CVE-2023-21709: EoP Schwachstelle in Microsoft Exchange Server; CVEv3 Score 9.8, important; Ein nicht authentifizierter Angreifer könnte diese Schwachstelle ausnutzen, indem er versucht, das Passwort für gültige Benutzerkonten zu erzwingen. Bei erfolgreicher Ausnutzung (als wenig wahrscheinlich eingestuft) könnte sich der Angreifer "als ein anderer Benutzer anmelden". Laut dem Advisory sind zusätzliche Schritte erforderlich, um diese Sicherheitslücke zu schließen. Nach der Anwendung des Patches muss ein PowerShell-Skript ausgeführt werden. Es wird empfohlen, die neuesten Informationen von Microsoft im Advisory nachzulesen, um diese Sicherheitslücke erfolgreich zu beheben.
- CVE-2023-38181, CVE-2023-38185, CVE-2023-35368, CVE-2023-38182, CVE-2023-35388, Microsoft Exchange Server Schwachstellen; CVEv3 Score 8.0 – 8.8 , important; Ein authentifizierter Angreifer kann durch Ausnutzung dieser Schwachstellen (als wenig wahrscheinlich eingestuft) Code über eine PowerShell-Remoting-Sitzung ausführen. Um diese Schwachstelle erfolgreich auszunutzen, müsste der Angreifer zunächst über LAN-Zugang und gültige Anmeldeinformationen für einen Exchange-Benutzer verfügen.
Administratoren von nicht englischsprachigen Exchange-Installationen liefen bei der Installation der Sicherheitsupdates vom August 2023 in Installationsfehler (z.B. 0x80070643 oder 1603 (siehe auch den Beitrag von Frank Zöchling). Zum 9. August 2023 hat Microsoft dann das Update zurückgezogen und empfahl die Installation zurückzustellen:
We are aware of Setup issues on non-English servers and have temporarily removed August SU from Windows / Microsoft update last night. If you are using a non-English language server, we recommend you wait with deployment of August SU until we provide more information. Update: Please see Known Issues below for more information.
siehe den Hinweis im Techcommunity-Beitrag Released: August 2023 Exchange Server Security Updates sowie in meinem Blog-Beitrag Desaster Exchange August 2023-Sicherheitsupdate – nicht installieren!.
Es gibt einen Workaround
Microsoft hat in der Nacht vom 9. auf den 10. August 2023 dann einen Supportbeitrag Exchange Server 2019 and 2016 August 2023 security update installation fails on non-English operating systems veröffentlicht ((danke an Stefan A für den entsprechenden Kommentar). Zum Fehlerbild bestätigt Microsoft die Beobachtungen der Blog-Leser:
Anzeige
Wird das Microsoft Exchange Server 2019 oder 2016 August 2023 Sicherheitsupdate (SU) auf einem Windows Server-basierten Gerät installiert, auf dem eine nicht-englische Betriebssystemversion ausgeführt wird, wird das Setup plötzlich angehalten und die Änderungen werden zurückgesetzt. Die Exchange Server-Dienste bleiben jedoch in einem deaktivierten Zustand.
Interessant ist da die Begründung für dieses Verhalten, denn Microsoft gibt ein ein Lokalisierungsproblem im Exchange Server August 2023 SU-Installationsprogramm an, der zu diesen Installationsproblemen führt, wenn es sich um ein nicht englischsprachiges Windows Server-System handelt, auf dem Exchange läuft. Meine Interpretation ist, dass ein AD-Benutzer Network Service nicht angelegt werden kann.
Um die August 2023-Updates erfolgreich zu installieren, schlägt Microsoft betroffenen Administratoren folgende Schritte vor. Sofern bereits versucht wurde, die SU zu installieren, ist der Dienststatus zurückzusetzen, bevor das Setup erneut ausgeführt wird. Dies lässt sich mit einem PowerShell-Skript, welches mit folgenden Schritte in der PowerShell-Konsole mit Administratorrechten auszuführen ist:
- Wechseln Sie in das folgende Verzeichnis:: \Exchange Server\V15\Bin.
- Führen sie folgendes Script .\ServiceControl.ps1 AfterPatch aus .
Im Anschluss ist der Windows Server neu zu starten. Nach dieser Vorbereitung muss dann das fehlende Konto im Active Directory (AD) manuell angelegt werden. Dazu gibt Microsoft vor, den folgenden Befehl auszuführen:
New-ADUser -Name "Network Service" -SurName "Network" -GivenName "Service" -DisplayName "Network Service" -Description "Dummy user to work around the Exchange August SU issue" -UserPrincipalName "Network Service@$((Get-ADForest).RootDomain)"
Danach ist die AD-Replikation abzuwarten (bis zu 15 Minuten). Im Anschluss kann dann die Installation des Exchange Server Sicherheitsupdates neu gestartete werden. Die Installation sollte nun erfolgreich verlaufen, verspricht Microsoft zumindest. Nach der Installation sind folgende Befehle auszuführen.
$acl = Get-Acl -Path "HKLM:\SOFTWARE\Microsoft\MSIPC\Server"
$rule = New-Object System.Security.AccessControl.RegistryAccessRule((New-Object System.Security.Principal.SecurityIdentifier("S-1-5-20")), 983103, 3, 0, 0)
$acl.SetAccessRule($rule)
Set-Acl -Path "HKLM:\SOFTWARE\Microsoft\MSIPC\Server" -AclObject $acl
Im Microsoft Support-Beitrag ist das obige Script in der Zeile $rule nicht lauffähig, weil die schließende Klammer fehlt – ist in obigem Code korrigiert.
Im Anschluss ist der Exchange-Server neu zu starten, um die Installation abzuschließen. Im Nachgang zur erfolgreichen Installation des Sicherheitsupdates auf dem Exchange-Servers lässt sich das obige, manuell angelegte, AD-Konto wieder löschen.
Ähnliche Artikel:
Microsoft Security Update Summary (8. August 2023)
Exchange Server Sicherheitsupdates (8. August 2023)
Desaster Exchange August 2023-Sicherheitsupdate – nicht installieren!
Anzeige
Ist das wirklich klug, den Patch SO in das System 'reinzuprügeln'. Sind da evtl. Side-Effects berücksichtigt/getestet? Möchte nicht wissen, wo dann möglicherweise 'unter der Haube' etwas fehlt bzw. nicht ordnungsgemäß installiert wird. Ist es da nicht sinnvoller auf ein korrigiertes offizielles MS-Release zu warten?
das werde ich auch so machen – hier geht es glaube eher darum die kaputten Server auch wieder zum Laufen zu bekommen.
Server einfach vorübergehend extern nicht erreichbar machen! und abwarten
Na ich denke schon, dass man das so machen kann (wenn man den Patch noch hat). Man kann ja ziemlich genau herauslesen, was die Ursache für den ganzen Spaß ist. Man nutzt offenbar den Dienstaccount "Network Service", der z.B. auf dem deutschen Server "Netzwerkdienst" heißt. Normalerweise sollte man den über seine SID S-1-5-20 ansprechen und nicht über seinen Namen, aber wahrscheinlich hat man tatsächlich ChatGPT drauf angesetzt.
Wie auch immer, man legt halt einen Account im AD mit diesem Namen an und zieht am Ende die Berechtigungen in der Registry glatt. Ist eigentlich relativ unspektakulär und nicht wirklich "reinprügeln".
Aber trotzdem: Ich warte auch auf das neue Release und werde es nicht auf diese Weise installieren.
Das ist ein Quick Hack.
Du hast eine weitere historische Leiche in Deinem gehassliebten Windows-Moloch…
Vermutlich ist es nicht so schnell möglich einen neuen Update durch das QM zu prügeln wie einfach den falsch referenzieren Account anzulegen.
Außerdem betrifft es nur den "Rest der Menschheit", nicht Amerika, ist also nicht tragisch…
Es gibt sie noch – die Exchange Server welche von extern erreichbar sind….
Ja und zwar sehr viele, wichtig wäre nur der Zusatz via VPN ;)
Was ist mit dem ActiveSync? Ist es auch angreifbar?
Fefe hat dazu bereits einen gewohnt bissigen Kommentar veröffentlicht: https://blog.fefe.de/?ts=9a2d74da
wobei man dazusagen muss, dass man in Microsofts Cloud dieses Problem eben nicht hat ;)
Und bei anderen Produkten der Konkurrenz gabs auch Scheunentore. Liest man vielleicht nicht so häufig, weil die nicht so häufig verwendet werden.
Witz lass nach. Natürlich hast Du das Patch-Problem bei Exchange Online nicht. Aber war da nicht was mit generierten Sicherheitstokens, so Storm-0558 munter durch alle Konten spazieren konnte?
Das hat nach dieser Anleitung mit dem US Patch prima geklappt. Läuft wie es sein soll.
Danke für die Anleitung! :)
gut gefrickelt ist halb gewonnen, nicht Bernd?
| Im Microsoft Support-Beitrag ist das obige Script in der Zeile
| $rule nicht lauffähig, weil die schließende Klammer fehlt – ist
| in obigem Code korrigiert.
Die scheinen da echt am Rande der Verzweiflung zu rotieren. Nicht einmal das kurze Skript veröffentlichen sie ohne Fehler. Unerklärlich.
:-(
YMMD! Das hab ich auch gedacht, als ich das las.
bei copy&paste ist es auch schon schwer die ganze Zeile zu erwischen. Und wenn man sowieso nicht so genau weiß was man macht passiert das halt…
Immerhin erklären sie fein was da passiert ist.
Und wenn die Ursache im non-englischen AD liegt, dann erklärt es auch, warum sie den Fehler in ihrem Test bed nicht finden oder reproduzieren konnten… sie haben da wohl nur einen der in Englisch installiert wurde…
Aua.
Ne, das ist ein Test: Wer es nicht hinbekommt, in einem Powershell-Skript eine fehlende Klammer zu bemerken sollte auch nicht am Exchange-Server rumpfuschen :-p
Das Update versucht scheinbar der Access Control List (ACL) des Registry Keys HKLM\SOFTWARE\Microsoft\MSIPC\Server ein Access Control Entry (ACE) für den Account 'Network Service' hinzuzufügen. Unglücklicherweise referenziert das Update diesen Account nicht über seinen sprach-neutralen Well-known Security Identifier 'S-1-5-20' sondern über den englischen Account Name. Auf Windows-Installationen die von einer deutschen Installationsquelle installiert wurden, heißt der Account jedoch 'Netzwerkdienst'. Entscheidend ist hier einzig die Sprache des Installationsmediums; nachträgliche Änderungen der Sprach- oder Regionseinstellungen ändern den Account Name nicht.
Der Microsoft Workaround macht sich zu Nutze, dass die GetSidFromName() Funktion im Active Directory (AD) nach dem 'Network Service' Account sucht, wenn es diesen in der lokalen Datenbank nicht findet. Legt man diesen Account also im AD an, so schlägt die Name-to-SID Translation anschließend zumindest nicht mehr fehl, auch wenn das Ergebnis natürlich Unsinn ist und nicht den gewünschten Account referenziert. Daher enthält der Microsoft Workaround auch noch einen Set-Acl Aufruf, der die ACE für den korrekten Account hinzufügt. Leider ist fehlt in dem Microsoft Skript eine Klammer, wie hier schon andere Leser angemerkt haben. Richtig wäre:
$rule = New-Object System.Security.AccessControl.RegistryAccessRule((New-Object System.Security.Principal.SecurityIdentifier("S-1-5-20")), 983103, 3, 0, 0)
Kann man sich nicht mehr ausdenken. Fehlt nur noch dass sie das Update einfach unverändert wieder freigeben und es dabei belassen weil jetzt ein Frickelaround existiert.
Nein, der Frickelaround wird zum neuen Standard!
Zukünftig werden bei nicht-englischen Installationen vor dem Update einfach die englischen Prinzipals per Script im AD angelegt, der Patch durchgeführt und hinterher wieder gelöscht. Was soll da schon schiefgehen! 🤣
Bei mir hat der Workaround nicht geklappt, hab nach 2 Std. aufgegeben. Mein Server war allerdings sehr langsam. Rücksicherung vom Systemlaufwerk, fertig (mit Tests nicht mal eine Std.).
Bei mir Exchange 2016. Es wäre interessant, bei welchen Versionen der Workaround funktioniert hat. In anderen Foren, wo die Version angegeben wurde, war immer von 2019 die Rede.
Hallo Rolf,
ich habe bei mir nen Server 2012 R2 mit Exchange 2016 CU23 am laufen welcher heute nacht neugestartet ist. Ich habe mich an o.s. Anleitung gehalten (Danke an Herr Born). Die Updates wurde lt. Statusanzeige unter Systemsteuerung > Programme erfolgreich installiert, das Skript "ServiceControl.ps1 AfterPatch" habe ich zuerst ausgeführt, da gab es den Rückgabewert 0 als Ergebnis. Dann den Server neu gestartet und erstmal die Dienste geprüft. Hier waren mehrere auf deaktiviert gestellt u.a. "Microsoft-Filterverwaltungsdienst" welcher vom "Microsoft Exchange-Transport" Dienst benötigt wird. Ggf. diese Liste von MS zu den notwendigen Diensten einmal durchgehen: https://learn.microsoft.com/de-de/exchange/plan-and-deploy/deployment-ref/services-overview?view=exchserver-2016 Gruß Mick
Damit macht sich Microsoft keine Freunde!
Anfang des letzten Jahres stand der Server still, weil keine Mails mehr verarbeitet wurden, nur weil die Benennung der Datei mit den Virensignaturen nicht mehr in den Datentyp gepasst hat und nun solch eine Kleinigkeit mit riesen Wirkung.
Entweder möchte man alle in die Cloud pressen oder man weiß bei MS nicht mehr, was vorne und hinten ist.
Ich meine, sowas kann mal passieren, aber ich mache mir schon wieder Gedanken um die endlosen Kommentare der MS-Hasser und Linux-Verfechter…
Microsoft hat noch Freunde?
OK, es soll Frauen geben die lieben ihren schlagenden Mann…
und mit solchen Aktionen macht sich MS bei den Admins beliebt (auch wenn es keiner zugeben wird) denn so wird der Admin sichtbar und kann seine Existenzberechtigung beweisen.
Aber der Nachteil ist, das die Cloud-Lösung auch dieses mal – rein zufälligerweise wenn die Story stimmt – nicht betroffen war. Und Cheffe fragen könnte, wer denn eigentlich den Patch Ungerester in das Produktiv-System eingespielt hat…und warum er nicht in die viel billigere Cloud gegangen ist…
Nicht schön was da läuft…
Interessant, genau das gleich Problem hatte ich schon Mal mit einem Exchange 2013, wo es mir damals meine Installation zerschossen hat, das ging auch genau auf den Network Service User zurück der auf einem deutschen OS anders heißt. Habe dann fehlende Files wiederhergestellt und konnte dann so die Services starten. Den Network Service user hatte ich dann glaube ich durch Local Service ersetzt und lief damit problemlos…bin den Server aber zum Glück seit heuer los.
Und wieder einmal bestätigt sich die Rechnung "Patchday plus 2 Wochen" zur Ermittlung des Installationszeitpunkts für M$ Serverupdates jeglicher Art…
Trotzdem Danke an alle Early-Adopter und Schnellklicker, welche die Fehler zeitnah aufdecken.
Das kann auch gefährlich werden. 2 Wochen sind eindeutig zu langen, 3 Tage würden langen. Bei Exchange lieber umgehend…wenn auch mal so etwas passiert – da kann dann mal ein Restore getestet werden ;)
2 Wochen ist für einen Server der bei vielen von extern erreichbar ist, einfach zu lange.
Vermutlich hat man die letzten verbliebenen "Kapazitäten" auf das höchst lukrative und nachhaltig Ertrag bringende Cloud-Geschäft gesetzt.
Das der Rest nun in jeder Hinsicht überfordert ist (zeitlich und know how mässig) ist ein gern gesehener Nebeneffekt um die Onprem zu zumachen…
Direkte Ansicht sehe ich da nicht dafür ist der Fehler zu schön.
Andererseits hatte die NSA auch eine Abteilung, die dafür sorgte, das es zu klar illegal ergatterten Informationen eine glaubwürdige legale Geschichte erfand, damit diese vir Gericht verwendet werden durfte. (In USA dürfen illegal gewonnene Informationen nicht in einem Gerichtsverfahren verwendet werden. In Deutschland übrigens schon.)
Ein Spruch des weisen slten Indianders soll lauten:
Und wenn ihr den letzten Onprem Server in die Cloud verlagert habt, werdet ihr sehen, dass Microsoft nicht die edlen Ritter sind wie ihr glaubt er und gnadenlos die Preise erhöhen wird.
Hallo,
also der Workaround für die Installationsroutine funktioniert (Im Labor probiert)
Den User kann man dann aus der AD wieder löschen.
Die Berechtigungen des Dienstes von Hand zu ändern sind auch nicht das Problem.
Das Security Update selbst scheint ja in Ordnung zu sein.
Welches Risiko wählt man jetzt. Entweder die Durchführung des Updates mit den Fix der Installationsroutine. Oder man wartet darauf das MS ein neues Update mit funktionierender Installationsroutine herausbringt. Warten ist ja auch nicht ohne Risiko!
Ich empfehle generell Updates von kritischen Diensten immer vorher irgendwie zu testen.
MS Updates zu vertrauen zahlt sich nicht aus!
Es sind eigentlich 3 Fehler:
1.
Die Verwendung eines sprachspefischen Accounts
2.
Das Testen in einem falsch installierten Test bed
3.
Das nicht reaktivieren der Serverdienste nach auftreten des Problems und roll backs.
Hammer.
Mal noch eine ganz dumme Frage:
Woher bekomme ich jetzt noch einen Download mit der deutschen Exchange-Version?
Hier gibt es nur noch den englischen (Umstellung auf englisch nicht möglich), stelle ich die URL um auf wird angezeigt, dass der Download nicht mehr verfügbar ist.
Weiss jemand, ob man da die en-exe verwenden kann?
Ich habe die englischer Version auf dem deutschen Exchange nun installiert Exchange 2019 CU13 – mit den oben benannten Workaround. Das ist kein Problem (trägt je den korrekten ad-User ein – Network Service). Hat einwandfrei funktioniert und Healthchecker war auch glücklich. Server läuft einwandfrei und im Ereignisprotokoll sind auch keine Auffälligkeiten vorhanden. NorbertFe hat das auch so vorgeschlagen – ob de oder en spielt in diesem Fall keine Rolle.
Ebenso aus dem Exchange Team Blog:
Nino Bilic Microsoft
Aug 10 2023 05:45 AM
@FloydH80 You can get the English versions of updates by following the links in this blog post (also the download links in the KB under Method 3).
Also ist das Update eigentlich sprachunabhängig, wie ja bei reinen Systemupdates erwartbar.
Umso schlimmer für den Tropf, der da nicht die SID genommen hat. Der arme Newbie.
Oh, könnte es sein, das MS das Update, weil ja eigentlich sprachunabhängig, überhaupt nicht für nicht-englische Systeme getestet hat? Kostet ja Zeit und Geld und was kann da schon schief gehen?
Was ist das für eine mickerige Klitsche geworden?
Jetzt mal im Ernst. Die eine Sicherheitslücke sagt ja aus: "Ein nicht authentifizierter Angreifer könnte diese Schwachstelle ausnutzen, indem er versucht, das Passwort für gültige Benutzerkonten zu erzwingen."
Dazu muss er ja erstmal im Netzwerk sein (dann hat man aber ganz andere Probleme)
Exchange nach außen über Port 443 direkt sollte man ja eh nicht mehr machen und mit deaktivierten OWA passiert doch quasi auch nichts.
Dazu müsste er die Domäne kennen und die Benutzerkonten und gleichzeitig noch die Passwörter "erhacken".
Das ist aber der heutige Sicherheitsstandard, dass man von einem Breach intern ausgehen muss und deshalb auch intern in Zonen aufteilt und absichert, daraus wurde ja auch der Gedanke von ZeroTrust geboren. Vor etwas über 10 Jahren hat man noch geglaubt eine Firewall am Perimeter reicht, aber deshalb geht man nun dazu über Netzwerke so stark wie möglich zu segmentieren.
Verliere hier langsam den Überblick… :-(
Falls es wen interessiert: Hab das Update Exchange2016-KB5029388-x64-de.exe gerade auf einem Server 2016 mit Exchange 2016 CU23 de-de mithilfe des Workarounds erfolgreich installiert. Die Datei Exchange2016-KB5029388-x64-de.exe hatte ich gestern in der Früh schon manuell runtergeladen.
MEINE Vorgehensweise (ohne Garantie auf Erfolg):
1. Benutzer gemäß Workaround anlegen
2. Patch installieren – lief bei mir ohne Probleme durch (nicht rebooten!)
3. Registry-Eintrag gemäß Workaround überarbeiten
4. Rebooten
Der Exchange kam nach dem Reboot sauber hoch und alle Dienste liefen fehlerfrei.
Hab dann den Benutzer wieder im AD gelöscht und das CVE-2023-21709.ps1 ausgeführt.
Nach erneutem Reboot das aktuelle HealthChecker.ps1 Skript laufen lassen: alles gut! :-)
Ging schneller als gedacht, aber ich würde mich freuen, wenn das nächste SU wieder ohne Frickelei zu installieren wäre.
"Die Hoffnung stirbt zuletzt. Aber sie stirbt." (c) Nico Semsrott
Danke fürs Teilen Deiner Erkenntnisse!
Ich habe im Exchange Team Blog noch vom dortigen User "Julian_Haupt", der einer der ersten beim Melden der Probleme an MS über das Blog war, noch eine URL gefunden, wo er das de-Update für andere zur Verfügung stellt:
*ttps://backofficeplusgmbh-my.sharepoint.com/personal/julian_haupt_backoffice_plus/_layouts/15/onedrive.aspx?
id=%2Fpersonal%2Fjulian%5Fhaupt%5Fbackoffice%5Fplus%2FDocuments%2FExchange2016%2
DKB5029388%2Dx64%2Dde%2Eexe&parent=%2Fpersonal%2Fjulian%5Fhaupt%5Fbackoffice
%5Fplus%2FDocuments&ga=1
-> Au weia, hoffe die URL funktioniert so…und sorry, dass ich hier den Kommentar damit zumülle!
Download/Verwendung auf eigene Gefahr, hat aber in den Dateieigenschaften diese gleiche Version (15.1.2507.31) wie die en-Ausgabe und auch der Dateihash passt zum Wert für die deutsche Version aus der CSV von der KB5029388-Beschreibungsseite (gecheckt mit certutil).
Achtung, wer das ServiceControl Script ausührt: Startet danach erst noch das HealthChecker Script! Bei waren immer noch 3 Dienste deaktiviert!
Leistungprotokoll
IIS Verwaltungsdienst
WWW-Publishier Dienst
Der Link funktioniert hier nicht mehr. Hab den daher deaktiviert.
Ich habe mal eine Frage zur Entfernung des TokenCacheModule.
Diejenigen welche das bereits durchgeführt haben:
Gibt es irgendwelche Performance Probleme danach?
Danke
Micha
Hatte ich gestern Abend durchgeführt.
Bis jetzt ist mir (und den "normalen" Benutzern) nichts Negatives aufgefallen.
Sind allerdings auch nur etwa 50 Benutzer/Postfächer auf dem Exchange.
Kann ja sein, dass das erst bei weit mehr Benutzern/Postfächern Auswirkungen auf die Performance hat.
Daher keine Garantie…
Ich hatte gestern mittels:
Clear-WebConfiguration -Filter "/system.webServer/globalModules/add[@name='TokenCacheModule']" -PSPath "IIS:\"
das Cache Module entfernt, da gabs noch keine Probleme. Über Nacht dann die Windowsupdates(kein Exchange SU) installiert und den Exchangeserver neugestartet. Seit heute früh melden sich User das deren Outlook immer wieder hängt mit der Meldung "Daten werden vom Server abgerufen". Kann noch nicht sagen ob es am Cachemodule oder den anderen Updates hängt.
Ich hab mit dem MS Skript das Cachemodule wieder aktiviert, dies brachte keine Besserung. Hab den Server nochmal neugestartet und seit dem läuft es wieder ohne Probleme. Leicht bescheiden… Ich werde es wohl nach rerelease des deutschen SU's nochmal prüfen.
habe das Update und Script bereits seit Mittwoch laufen, keine Probleme festgestellt auf EX 2019 (CU12-EN). Der Server wird aber nur als Hybrid ohne lokale Postfächer und als Mail Relay verwendet.
Die große Frage ist sowieso, ob MS überhaupt nochmal ein anderes SU herausbringt oder es so lässt ?
Weiß das jemand?
Vielen Dank für das ganze Zusammentragen an Infos. Ich habe trotzdem mal eine Frage zu dem Workaround.
Nach der Installation vom dem Update sollen ja noch folgendes ausgeführt werden:
$acl = Get-Acl -Path "HKLM:\SOFTWARE\Microsoft\MSIPC\Server"
$rule = New-Object System.Security.AccessControl.RegistryAccessRule((New-Object System.Security.Principal.SecurityIdentifier("S-1-5-20")), 983103, 3, 0, 0)
$acl. SetAccessRule($rule)
Set-Acl -Path "HKLM:\SOFTWARE\Microsoft\MSIPC\Server" -AclObject $acl
1. Frage: Auf dem DC oder auf dem Exchange?
2. Frage: Es sieht für mich aus wie mehrere einzelne Befehle. Muss ich entsprechend einzeln ausführen oder kann das ganze auf einmal in die Powershell?
Sorry und danke.
Das musst du in der Exchange Powershell ausführen.
1. Exchange Powershell
2. Egal, wie du willst
Vielen Dank für die Antwort. Läuft soweit. :)
Das Update ist drin und läuft soweit ich das in den ersten Tests sehen kann normal.
Eine Frage stellt sich mir noch: Sollte man den Dummy AD User "Network Service" eventuell einfach stehen lassen fall es nochmal ein Lokalisierungsproblem gibt oder ist besser diesen einfach aus dem AD zu löschen?
Danke
ich wüsste nicht, was dagegen spricht, wenn man ihn da lässt ?
https://support.microsoft.com/en-us/topic/exchange-server-2019-and-2016-august-2023-security-update-installation-fails-on-non-english-operating-systems-ef38d805-f645-4511-8cc5-cf967e5d5c75
gibt schon wieder ne Änderung, nämlich, dass man den User nicht löschen soll…
MS Artikel wurde aktualisiert!
Nachdem alle Exchange-Server aktualisiert wurden, behalten Sie das AD-Konto, das in Schritt 2 erstellt wurde. Wenn das Konto gelöscht wurde, sollten Sie es neu erstellen, indem Sie den Befehl in Schritt 2 erneut ausführen. Es spielt keine Rolle, dass das neue Konto eine andere SID hat.
After all Exchange servers are updated, keep the AD account that was created in step 2. If the account was deleted, you should re-create it by running the command in step 2 again. It won't matter that the new account will have a different SID.
So ist es! Sogar beim Gefrickel wird gefrickelt. Mal gespannt, wie viele Leute beim nächsten CU/SU plötzlich massive, unerklärliche Probleme haben, weil sie das Update nicht gelesen haben. Es bleibt spannend /s
das ist echt hart, weil vorher ja beim Artikel stand, dass der User anschließend gelöscht werden soll…
nun soll er bestehen bleiben… herrlich…
Hallo Dominik. Danke für das Update hier.
Passend das ich den User noch nicht gelöscht hatte.
es wäre einfach mal schön, wenn MS sich mal äußert, ob es ein neues Update gibt oder es beim Workaround bleiben soll ?!
Diese Unklarheit hat mich am Ende auch bewogen den Workaround zu machen.
Ich gehe davon aus das es erst zu nächste Patchday ein neues Update gibt das die aktuellen und neuen CVEs patchen wird.
Microsoft interessiert der Aufwand dahin denke ich herzlich wenig, leider.
Ich suche gerade den Link zum Download des Updates für Exchange Server 2016 CU23 in Englisch und habe wohl Tomaten auf den Augen. Alle Links, welche ich finde sind "no longer available". Wurde die Englische Version jetzt auch komplett zurückgezogen?
Dem Anschein nach ja. Es gibt aber keine offizielle Meldung von Microsoft dazu. Man muss keine Fehler beheben, wenn man alle Spuren der Fehler verschwinden lässt ;)
Vielleicht kommt auch bald eine gefixte Version raus. Man kann nur vermuten.
Moin zusammen!
Das Update wurde überarbeitet und steht jetzt als KB5030524 bereit.
Wenn ich die Exchange Server meiner Kunden überfliege, wird das in deren WSUS für alle angezeigt.
Auch für die, wo ich das KB5029388 mithilfe des Workarounds bereits installiert hatte.
Mit dem KB5030524 warte ich aber noch ein bisschen… ;-)
PS: da wurde übrigens noch mehr gefixt, als "nur" das "non-English"-Desaster:
– Exchange Server 2019 and 2016 August 2023 security update installation fails on non-English operating systems
– DST settings are inaccurate after an OS update
– Microsoft Exchange replication service repeatedly stops responding
– Chinese coded characters aren't supported in Exchange Admin Center
– External email address field doesn't display the correct username
Hi zusammen,
bei uns kam das KB5030524 über Windows Updates rein. Jetzt ist das Verhalten des Exchange so wie beim KB5029388 – sprich: nichts geht mehr.
Leider kann ich aber auch das KB5029388 in diesem Status nicht mehr deinstallieren (Fehlermeldung: Setup Wizard for Security Update for Exchange Server 2016 Cumulative Update 23 (KB5025903) ended prematurely because of an error.). Es wird also auf eine völlig anderes Update verwiesen… seltsam.
Eine Installation des KB5030524 auf manuellem Weg schlägt ebenfalls fehl.
Hat jemand eine Idee?
Guten Morgen!
Stehe gerade vor dem selben Problem, dass das KB5030524 "vorzeitig endet" und die Dienste nicht mehr zur Verfügung stehen.
Gibt es schon eine Möglichkeit, dieses Update doch noch korrekt zu installieren oder wenigstens wieder zu entfernen?
habe eben KB5030524 installiert aber www publischer dienst ist dektiviert. Habe den aktiviert es tut sich aber nichts. Irgendwelche Ideen? Powershell kann sich nicht zum Exchange verbinden
Gibt es was neues ?Bin ebenfalls offline mit dem Exchange2016-KB5030524-x64-de
kann jemand einen workarround empfehlen ?