Microsoft hat neue Sicherheitsupdates für Exchange Server 2016 und 2019 veröffentlicht. Das Update behebt 6 Schwachstellen, welche als Wichtig gekennzeichnet sind. Außerdem sind nach der Installation der Updates weitere Anpassungen nötig. Derzeit gibt es keine Hinweise, dass die Schwachstellen ausgenutzt werden.
Hier geht es direkt zu den Download der Updates:
Die folgenden Schwachstellen werden behoben:
- CVE-2023-35368 (Remote Code Execution)
- CVE-2023-38181 (Spoofing)
- CVE-2023-38182 (Remote Code Execution)
- CVE-2023-21709 (Elevation of Privilege)
- CVE-2023-35388 (Remote Code Execution)
- CVE-2023-38185 (Remote Code Execution)
- CVE-2023-38185 (Remote Code Execution)
Nachdem das Sicherheitsupdate für den August 2023 installiert wurde, muss zusätzlich ein von Microsoft bereitgestelltes PowerShell Script ausgeführt werden, damit die Schwachstelle CVE-2023-21709 behoben wird. Das erforderliche Script kann hier runtergeladen werden:
Hier gibt es weitere Informationen zu dem Script:
Falls RMS bzw. Purview Information Protection zum Einsatz kommt, sind weitere Schritte erforderlich. Die Details können der Grafik aus dem Exchange Team Blog entnommen werden:
Hier noch der Link zum zum Artikel aus dem Exchange Team Blog:
Update 08.08.2023: Scheinbar lässt sich das Update auf Betriebssystemen und Exchange Servern in deutscher Sprache nicht erfolgreich installieren. Das Setup scheitert mit dem Fehlercode 1603 und hinterlässt eine fehlerhafte Exchange Installation. Nutzer von Exchange Servern und Betriebssystemen in deutscher Sprache sollten daher das Update zunächst nicht installieren.
Update 09.08.2023: Mittlerweile hat Microsoft bestätigt, dass das Update auf nicht englisch sprachigen Servern Probleme macht:
Due to reports that Exchange setup fails on servers running on several languages other than English, we have temporarily removed August SU from Microsoft / Windows update until we find the root cause of the problem. We recommend our customers running non-English servers to pause installation until we provide more information. If your server has been already impacted by failed setup, please do not try uninstalling anything. Re-enable Exchange Services by running the following from the \Exchange Server\V15\Bin folder. Reboot the server after this and services should start:
.\ServiceControl.ps1 AfterPatch
Update 16.08.2023: Es wurde eine neue Version des Updates veröffentlicht. Siehe hier: Neue Sicherheitsupdates für Exchange Server (August 2023)
sehe ich es richtig, das wenn man nach erfolgreichem Workaround v1 auf v2 updaten möchte, erst das v1 deinstalliert werden „muss“ ?
Hallo Tobias,
auch bei uns gibt es diese Probleme wir bekommen nach dem aufrufen 440 Login Timeout.
Haben die .\UpdateCas.ps1 & .\UpdateConfigFiles.ps1 Scripte aus dem Installpfad ausgeführt einen iisreset gemacht und auch nochmals die virtualdirectorys recreated.. alles nichts geholfen.
Hast du schon eine Lösung?
Bei uns tritt nach dem ausführen des Scripts das Problem auf das kein ECP Login mehr möglich ist.
Wir haben für das ECP einen extra Port eingerichtet wie hier (https://www.frankysweb.de/exchange-2016-eac-nur-im-internen-netzwerk-freigeben/).
Nutzt diese Konfig noch jemand und kann mir einen Tipp geben? Danke!
Hi,
ja selbes Problem bei mir.
Habe es jetzt so gelöst wie in den Kommentaren von „Exchange 2016: EAC nur im internen Netzwerk freigeben“ beschrieben.
Die Seite kann zwar aufgerufen werden, aber der Login klappt nicht mehr.
Zitat von Tobias 04.05.2020
Anleitung:
„Installation von IP und Domäneneinschränkungen für IIS über den Server Manager.
Dann im IIS unter Default Website ECP auswählen und dort auf
Einschränkungen für IP Adressen und Domänen.
Dort wird ein neuer Zulassungseintrag erstellt, der alle lokalen Subnetze beinhaltet (Netzwerkadresse eintragen und im zweiten Feld 255.255.255.0).
Außerdem dann noch rechts im Menü unter „Featureeinstellungen bearbeiten“ Zugriff für nicht angegebene Clients auf
Verweigern setzen und Deny Action Type auf Not found.
Neustart des IIS anschließend“
Hallo Tobias,
auch bei uns gibt es diese Probleme wir bekommen nach dem aufrufen 440 Login Timeout.
Haben die .\UpdateCas.ps1 & .\UpdateConfigFiles.ps1 Scripte aus dem Installpfad ausgeführt einen iisreset gemacht und auch nochmals die virtualdirectorys recreated.. alles nichts geholfen.
Hast du schon eine Lösung?
Hallo,
seit Installation des Updates und des Scripts (SUv1 und CVE-2023-21709.ps1) haben wir mit Outlook flächendeckend massive Performanceprobleme (lange Startzeiten, Abstürze im Betrieb etc.) Der Cache Modus läuft einigermaßen stabil, im Onlinemodus ist kein Arbeiten möglich. Der bereits bekannte Workaround hat zwar dazu geführt das wir das Update ohne Fehler installieren konnten aber die Probleme auf den Clients bestehen nach wie vor. Ein Rollback des Scripts CVE-2023-21709.ps inkl. reboot hat die Probleme ebenfalls nicht beheben können. Große Hoffnungen hatten wir seit der Veröffentlichung des SUv2 aber leider hat dies ebenfalls nicht zur Besserung geführt. Wir haben eine weitere Exchange-Landschaft bei der die Installation der Updates inkl. Workaround soweit ohne Probleme liefe und auch der Betrieb der Outlook Clients keine Probleme darstellt.
Hat hier jemand noch eine Idee? Ich weiß, es gibt theoretisch so viele Fehlerquellen, allerdings decken sich die Probleme mit der Installation der Updates etc. Ich wäre über Tipps und Lösungsansätze total dankbar.
Hallo :), du musst bzw. sollst V1 deinstallieren, quasi den Workaround rückgängig machen und dann reicht es, wenn du V2 installierst.
https://techcommunity.microsoft.com/t5/exchange-team-blog/re-release-of-august-2023-exchange-server-security-update/ba-p/3900025
Danke für die Antwort! Das haben wir auch so gemacht. Haben uns an die Schritte gehalten. Dennoch keine Besserung.
SU Update auf Exchange 2019 auf Windows Server 2022 erfolgreich installiert über CMD
Was sind eigentlich RMS bzw. Purview Information Protection ?!
Hallo in die Runde,
Patch ist erfolgreich eingespielt. PS-Sript auch.
Ich habe mit dem HealthChecker vorher, dazwischen und danach geprüft. Ob das PS-Script nun drin ist oder nicht, stellt der HealthChecker aber auch nicht fest! Wie ist eure Erfahrung? Finde ich etwas schach.
Gruß
Deine Skript Version ist zu alt. Hier wird es korrekt erkannt.
Hier noch ne Warnung zum neuen SU vom 15.8.:
Ich habe auf unserem Server erst mal nur die verfügbaren Updates aktualisiert.
Dabei wurde das neue SU nicht nur gefunden, sondern auch gleich heruntergeladen und die Installation gestartet – ohne weiteres Zutun meinerseits. Jetzt ist natürlich erst mal Outlook down.
Also, wer nur mal eben nachsehen möchte, ob das neue SU unter Updates erscheint, sollte damit rechnen, dass es auch gleich installiert wird.
sorry, das habe ich oben etwas missverständlich formuliert:
mit „die verfügbaren Updates aktualisiert“ meine ich, dass ich unter „Windows Update“ auf [Nach Update suchen] geklickt habe, um die Liste der verfügbaren Updates zu aktualisieren.
… aber immerhin lief es ohne Fehler in 15 Minuten durch (ExchServer 2016).
Ja, und diese Erkenntnis sollte sich seit erscheinen von Windows 2016 doch schon durchgesetzt haben, dass das suchen auch gleich zur Installation führt. ;) und da ja offenbar genug Leute ihren exchange trotzdem über Windows Update aktualisieren, sollte das doch erst recht bekannt sein. Man könnte natürlich auch das Aktualisieren per Windows Update für exchange Abschalten und das einfach immer per Hand erledigen. ;)
Exchange 2019 Cu13 SU2V2 (KB5030524); Deutsches Installationspaket
lief soeben problemlos durch. Das Powershell Skript lief ebenfalls ohne Probleme durch!
Bisher läuft alles wie gewohnt und keiner der Kollegen hat sich bisher beschwert ;)
Das letzte SU2 Paket wurde von uns nicht installiert bzw. wir hatten zum Glück bisher abgewartet!
Muss man eben abwägen, ob man lieber den Workaround nehmen wollte, oder lieber die diverse Sicherheitslücken offen ließ. ;)
Muss das CVE PS Skript eigentlich nochmal neu ausgeführt werden?
keine Ahnung. Ich hatte das nur einmal ausgeführt nach der Installation des neuen SU2V2 Updates. Wenn du das SUV2 deinstalliert hast dann wäre es natürlich interessant ob man das Powershell Skript nochmals ausführen muss. Hoffe die Experten hier können weiterhelfen :)
Nein, steht in der FAQ des TechCommunity-Beitrags zu dem Re-release ganz unten:
If we need to uninstall Aug SUv1, will that have any impact on CVE-2023-21709 actions we already took?
No. (…)
Auf dem ersten Exchange 2016 CU23 Aug23SUv1 deinstalliert (Programme und Funktionen -> Updates deinstallieren -> Das zugehörige KB auswählen).
Danach hatte ich den Patchstand vom letzten Security Update (Mai).
Installation des neuen Updates Aug23SUv2 hat ohne Probleme geklappt. Build Version 15.01.2507.32, bei dem alten Update war es ….31
Der Network Service Workaround ist bereits zurückgebaut gewesen.
Wann wird der Beitrag hier aktualisiert ?
Gibt eine neue Version des Updates:
https://techcommunity.microsoft.com/t5/exchange-team-blog/re-release-of-august-2023-exchange-server-security-update/ba-p/3900025
Guten Morgen,
bin schon am installieren mal sehen was passiert. ;0)
Wenn ich das richtig deute, kann man jetzt nachdem man auf allen Server den Workaround angewendet hat, das SUv1 wieder deinstallieren und dann das SUv2 installieren, damit man in Zukunft den Dummyuser nicht mehr benötigt?
Nehmen die bei MS eigentlich etwas?
Genau die Frage Handbuch mir auch gestellt. :/
Schön die ganze DAG Downgraden, User löschen und dann wieder alles updaten.
Die haben doch den knall nicht gehört.
doch genauso sehe ich es auch… heftig…
und läuft alles?
Kurzes Update.
Läuft alles ohne Probleme. Update ist auch im Live System drin, Kollegen haben sich bisher nicht beschwert.
Installation wie immer über Eingabeaufforderung als Admin.
Gruß
tomtom
Jupp bisher läuft hier alles wie es soll.
Scheinbar wurde der August-Patch für Exchange 2016 wieder zurückgezogen. Dieser taucht nämlich nicht mehr in der Liste auf. Dann heißt es warten oder manueller Download und manuelle installation. Wir betreiben „Gott Lob“ einen englischen Exchange auf einem englischen Windows Server 2016 …
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.
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
Der für 2019 ebenfalls. Wieder mal super gelaufen bei ms.
Danke für die Bestätigung.
Was das ganze nun noch merkwürdiger erscheinen lässt. Konnte bisher auch im Netz nicht wirklich was dazu finden. Schreiben eigentlich alle das der Workaround funktioniert.
Welches Build ist auf deinem Exchange?
Bei uns: Version 15.1 (Build 2507.18)
Version 15.1 (Build 2507.17)
Was Zeigt dir diese Info:
Get-Command Exsetup.exe | ForEach {$_.FileVersionInfo}
ProductVersion FileVersion
15.01.2507.027 15.01.2507.027
Guten Morgen,
bei mir auf einem Exchange 2016 schlägt das Update auch nach dem Workaround von MS mit Fehler 1603 fehl.
Der User „Network Service“ ist im AD hinterlegt aber deaktiviert. Kann auch nicht manuell aktiviert werden. Ich vermute weil kein Kennwort hinterlegt ist.
Hat jemand eine Idee?
Gruß
tomtom
Der muss auch nicht aktiviert werden. Deaktiviert ist der, weil er kein Passwort hat, wie du schon vermutest.
Hast du wirklich 15 Min gewartet, nach dem Erstellen des User?
Ich habe es erst danach Probiert und ging ohne Probleme.
Gruss
Adi
Ja habe ich.
Um 06.45 Uhr User erstellt um 07.00 Uhr Installation gestartet.
Abbruch durch Installer. Exchange Server auf Snapshot zurückgesetzt.
Um 08.00 Uhr die Installation nochmals gestartet und wieder Abbruch mit Fehler 1603.
Im Update Log habe ich noch folgenden Satz gefunden.
„msgInterimIncorrectRollup = Installation cannot continue. The Setup Wizard has determined that this Interim Update is incompatible with the current Microsoft Exchange Server 2016 Cumulative Update 23 configuration.“
Hast du aus Versehen die falsche Version herunter geladen?
ist mir gestern auch passiert ;-)
https://www.microsoft.com/en-us/download/details.aspx?id=105526
Habe die Version für Exchange 2019 zuerst herunter geladen.
Nein, die Version stimmt auch.
Der Workaround hat auf dem DAG funktioniert. Leider kann ich den Update auf den EDGE Server nicht installieren.
Hat da jemand einen Tipp?
Der Update bricht immer wieder ab.
Reconfiguration success or error status: 1603.
Wir haben Windows Server 2016 und Exchange 2016.
Auf dem Edge müßtest du den User lokal anlegen, da der normalerweise ja nicht Mitglied eines AD is. WEnn du jetzt schon den Fehler 1603 hast, schau, ob du den erstmal wieder zum Fliegen bringst (notfalls restore aus einem aktuellen Backup).
Danke für den Tipp.
War genau das.
User lokal angelegt und Update Installiert.
Hätte ich ja selber drauf kommen müssen.
Danke
Hallo zusammen,
gibt es schon ein Update? (Neues) ohne Fehler.
Ich danke euch im Voraus
LG Martin Schmidt
Noch tote Hose..Ich schätze es wird noch genug Leute geben, die den Workaround nicht umgesetzt haben
gehe mal davon aus, dass heute Abend was kommt. Ist ja nun schon eine Woche her….
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.
Ich habe bisher nur das Skript angewendet, da man ja mit der Installation noch warten sollte. Nun hat im Blog jemand geschrieben, dass es nach dem Reboot zu Problemen bei AS und mobilen Geräten kam. Kann das einer bestätigen oder was das bei euch nicht der Fall? Danke für eure Antworten
Der hat aber auch noch geschrieben:
After investigating further I think my issue may be coincidental as I had made some other configuration changes along with the CVE script. I’ve rolled back the script and those changes and now receiving emails on devices now. I will reapply the CVE script, see that everything is working as expected and reply back.
Ich meinte eher den Kommentar von BastiMS
I had no Problem too, but after i reboot the Server tonight I got a lot of reports today that outlook does freeze random and when sending mails for up to 1 minute (outlook is trying to retrieve data… was the message in the taskbar).
Just using the script to revert the changes (enable TokenCacheModule) didnt change anything, I had to reboot the Exchangeserver aswell and so far it seems no more Outlook freezes.
I have not installed the Exchange SU as I m waiting for a fixed release.
Hallo Community.
Installation mit Workaround problemlos auf Server 2012R2 mit Ex2016 und Server 2016 mit Ex2016 soeben durchgeführt. Herzlichen DANK an Franky für diesen Blog und deine Zahlreichen Hilfestellungen und Anleitungen. :-)
Server 2012R2 ist in 2 Monaten end of life und dann gibt es keine Sicherheitsupdates mehr
Die große Frage ist sowieso, ob MS überhaupt nochmal ein anderes SU herausbringt oder es so lässt ?
Von wegen, es gibt ja den Workaround
Weiß das jemand?
Ich vermute, dass sie ein neues rausbringen, denn ansonsten wäre der Hinweis, dass nicht englische Systemnutzer warten sollen auf Dauer ziemlich kontraproduktiv. Ich persönlich hab jetzt bei allen begonnen mit dem Workaround zu installieren. Das funktioniert und ich muss nicht hoffen, dass MS schneller mit dem re-Release ist als irgendwelche Hacker. ;)
Lässt sich das denn mit den englischen Installationsdateien installieren ?
Der WSUS hat sie nicht mehr und auf der https://www.microsoft.com/en-us/download/details.aspx?id=105525 gibt es nur die englische EXE.
Ja, wie unten schon zweimal erwähnt ist Exchange Multilanguage und demzufolge passt jedes Update auf jede Sprache. Nur die Setup GUI ist dann halt in dem Fall auf englisch.
und wie löscht man den User wieder ? Einfach „rechtsklick“ löschen reicht?
Ja wie löschst du denn sonst Benutzer? ;) Kannst auch die „Entf“ Taste drücken.
Wir haben bei manchen Kunden das Konstrukt, dass die Domaincontroller auf Englisch sind und die Exchange Server Installation auf Deutsch.
Die Erstellung des AD-Benutzers funktioniert nicht auf englischen DCs:
Der Fehler lautet: „New-ADUser : The specified account already exists“.
Ich vermute das liegt daran, dass die OS Sprache englisch ist und vor Hinzufügen in die Domäne es einen „NT-Authority\Network Service“ Nutzer gibt.
Im AD ist kein „Network Service“ dann vorhanden.
Sollte ein deutscher DC vorhanden sein, kann der Nutzer dort erstellt werden und der Workaround ist platzier.
Wird trotz des „Fehlers“ ohne den Benutzer die Instalaltion gestartet, schlägt diese Fehl in unserem Falle (2016 CU23) waren viele dlls (ca. 40) verschwunden und wir mussten das Update erneut installieren. Ein Restore der Dlls hat den Server nur in Teilen funktionsfähig gebracht, der Mailtransport blieb gestört.
LÖSUNG für unser Sprachproblem:
Wir haben auf dem deutschen DC einen Lokalen Benutzer „Network Service“ erstellt. Die Installation lief im Anschluss ohne Probleme durch, die DLLs wurden mit der August-Version erstellt und der Server funktioniert – bisher – ohne Probleme.
Sorry, nicht deutschen DC, sondern deutschen Exchange…
Also korrigiert:
LÖSUNG für unser Sprachproblem:
Wir haben auf dem deutschen Exchange einen lokalen Benutzer „Network Service“ erstellt. Die Installation lief im Anschluss ohne Probleme durch, die DLLs wurden mit der August-Version erstellt und der Server funktioniert – bisher – ohne Probleme.
Gabs in dem Fall denn überhaupt ein Problem bei der Installation (also ohne den lokalen User)?
Klar, das war ja der Grund, weshalb ich diesen erstellen musste.
Wohlgemerkt, Deutscher Exchange, Englische DCs.
Install Log sagte Folgendes:
ExecSecureObjects: Error 0x80070534: failed to get sid for account: Network Service
Nach Erstellung des lokalen „Network Service“ Benutzer, hatte der Installer seine SID und die Installation lief zufrieden durch.
Exchange HealthChecker ist auch grün.
Merkwürdig, aber die Lösung ist auch für Edge Server erfolgreich gewesen. ich ging nur davon aus, dass er in dem Fall dann den schon im AD vorhandenen User nutzt.
Was ist mit dem ActiveSync? Ist es auch angreifbar? Soll man am Besten den Zugriff von Außen auschalten? Owa ist aus.
Wir würden auf ein DE-Update abwarten :)
Danke und beste grüße
Such mal bei Google nach CVE-2023-21709, da findest du ein CMDLET mit der die Sicherheitslücke auf ungepatchen Systemen geschlossen wird!
Gruß
Christoph
Oder einfach oben den Link zum Teamblog lesen? ;) Auch da steht mehr oder weniger alles drin.
Soweit ich das verstanden habe, kann ich das Powershell Script für die CVE, auch ohne das Exchange Update ausführen. Richtig?
Richtig.
Microsoft hat inzwischen eine Lösung veröffentlicht
Exchange Server 2019 and 2016 August 2023 security update installation fails on non-English operating systems
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
Ich habe versucht die Schritte durchzugehen.
Aber…
nachdem ich den User im AD angelegt habe, wollte ich das Update wiederholen lassen.
Im Windows Update auf „Wiederholen“ geklickt… zack, war das Update weg.
Microsoft hat also das ganze Update zurück gezogen.
Sehe gerade, dass hat ha Stefan schon gepostet
Zwei Server Exchange 2019 CU12 (DE-DE) auf Server 2022 (DE-DE) in DAG mit Workaround ohne Problem geupdatet.
Grade läuft noch Windows Update aber auch das schaut gut aus.
hab den User VOR dem Update erstellt, wie beschrieben.
hier ebenfalls ohne Probleme mit dem neuen Workaround durchgelaufen (2016-DAG auf Server 2016).
Das nachträgliche CVE-Skript nicht vergessen!
Bei mir hat es einen Exchange 2016 CU23 Server komplett gekillt. Der Activ Directory und Topologie Dienst verursacht beim starten einen AppCrash. Ergo starten alle Dienste nicht mehr. Restore des letzten Backup war erfolgreich. Trotzdem sehr ärgerlich.
Mit dem Workaround?
Er schrieb ja Restore von Backup. Mach ich auch gerade. So ein Mist.
Der Workaround hat bei mir nicht funktioniert und hab keine Lust noch mehr Zeit zu investieren……..
Also der Workarround von Microsoft mit dem AD User den man anlegen soll und nach der Installation noch ein paar Commandos in die PS tippen hat nicht funktioniert?
Das wäre schon wichtig, wenn man das eben genau kommunizieren könnte, dann werde ich das gar nicht erst testen.
mfg
MaGo
Mir wäre ein anderer Workaround nicht bekannt….
Mein Server wurde teilweise so langsam, dass ein Neustart ca. 10 Min. gedauert hat. Hab jetzt fast 2 Std. investiert und das Problem hat sich nicht gelöst. Klar kann ich nochmals alles durchlaufen lasse. Der Restore (von der Systemplatte) dauert bei mir ungefähr 30 Minuten, dann Nacharbeiten und Test, 1 Std. rum, erledigt.
Grüße
Rolf
KEIN anderer
Nein, es wurden alle Updates (.net, das CU für Windows Server und das Exchange Security Update eingespielt) alle erfolgreich bis auf das Exchange Security Update. Danach Reboot des deutschen Windows Servers (2016). Alle Dienste standen noch auf automatisch. Auf Grund der Abhängigkeit vom AD Topologie Dienstes welcher crashed. Ging kein Exchange mehr.
Der Workaround war noch nicht veröffentlicht. Es bestand keine Zeit darauf zu warten. Mittlerweile habe ich Kenntnis von einem zweiten Exchange 2016 Server den ich ziemlich gleich eingerichtet habe. Dieser hatte „nur“ das Problem mit den deaktivierten Diensten. Das habe ich manuell gelöst.
Es gibt jetzt wohl einen Workaround:
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
Der funktioniert – eingespielt am Server 2019, Exchange 2019 CU13…mit US Patch durchgeführt.
Da hat jemand bei Microsoft massiv gepennt, in dem er den lokalisierten Accountnamen anstatt der Well known SID genommen hat.
Der Dienst „Network Service“ heißt auf deutschen Servern aber „Netzwerkdienst“ und auf anderen nicht englischen Systemen eben auch entsprechend der Sprache anders.
Mit diesem Workaround wird nur dafür gesorgt, das der Patch den Account „Network Service“ findet und dann weitermacht.
Danach muß man noch die ACLs in der Registry glatt ziehen, damit die auf die richtige SID S-1-5-20 zeigen.
Danach kann man den neu angelegten Account auch wieder löschen.
Da fehlen einfach ein paar Zeilen Programmcode, mit dem man aus der SID S-1-5-20 den lokalisierten Accountnamen ausliest und dann den ermittelten Accountnamen verwendet.
Einfach Schlampigkeit, war wohl ein Praktikant am Werk.
FYI: Es gibt ein Workaround für die Installationsprobleme bei den Exchange August 2023 Sicherheitsupdates, die auf nicht englischen Installationen beim Setup scheitern.
https://www.borncity.com/blog/2023/08/10/workaround-fr-exchange-august-2023-sicherheits-update-installationsprobleme/
In dem Workaround von Microsoft (siehe https://support.microsoft.com/de-de/topic/exchange-server-2019-and-2016-august-2023-security-update-installation-fails-on-non-english-operating-systems-ef38d805-f645-4511-8cc5-cf967e5d5c75) fehlt bei Punkt 4 btw. nach „$rule = New-Object System.Security.AccessControl.RegistryAccessRule((New-Object System.Security.Principal.SecurityIdentifier(„S-1-5-20″)), 983103, 3, 0, 0“ eine abschließende Klammer „)“.
Und wenn man schon dabei ist, kann man den Dummy Account an der Stelle dann auch gleich wieder entfernen. ;)
.\ServiceControl.ps1 AfterPatch
after i run this command
add-PSSnapin : Der Typeninitialisierer für „Microsoft.Exchange.Management.PowerShell.CmdletConfigurationEntries“ hat
eine Ausnahme verursacht.
In C:\Program Files\Microsoft\Exchange Server\V15\Bin\ServiceControl.ps1:876 Zeichen:5
+ add-PSSnapin -Name Microsoft.Exchange.Management.PowerShell.Setup …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Add-PSSnapin], TypeInitializationException
+ FullyQualifiedErrorId : System.TypeInitializationException,Microsoft.PowerShell.Commands.AddPSSnapinCommand
Hallo Mitstreiter, Hallo Edres,
ich hatte diese Meldung auch. Dienste waren alle da, diese standen auf Auto und somit hat der Workaround keine Auswirkung.
Es gab aber Fehler beim ausführen des Scripts: „Zugriff verweigert“ bei Diensten die nicht starteten.
Nach vielen Stunden des Studieren der im Internet vorhanden Meldungen, wurde festgestellt, dass nicht nur die Exchange-Dienste sondern auch die Exchange-PowerShell nicht startet. In den Logfiles bzw. Ereignisanzeige steht das Files nicht gefunden werden.
Schlussfolgerung: Dateien im BIN Verzeichnis (*.dll ’s) fehlen!
Durch Prüfung und vergleiche mit dem Verzeichnis der ursprünglichen Installation des ….CU23.ISO fehlen tatsächlich dll’s.
Ich bin nun hergegangen und habe diese kopiert. Siehe da, der Exchange startet wieder die Dienste.
Aber er läuft nicht rund. Es werden jetzt noch die aktualisierte Dateien aus den danach installierten Sicherheit-Updates nach CU23.ISO fehlen. Das prüfe ich nun. puh was für ein Tag seit gestern…
Gruß
Thomas
Update:
Nachdem Der Exchange Server 2016 wieder lief und die Exchange-PowerShell, wurde der neue Workaround (s. Link von @Stefan) angewendet. Das Security Update heruntergeladen https://www.microsoft.com/en-us/download/details.aspx?id=105526 und installiert. Dann das Skript ausgeführt. (die Klammer im Skript hinter der „0)“ nicht vergessen! s. @ITJF )
Der Server Läuft nun wieder fehlerfrei und es ging keine Mail verloren. :-)
Gruß
Thomas
Moin Moin zusammen!
Jetzt muss ich mich auch einmal hier in die Diskussion einmischen. Aber zuerst einen Dank an Franky, dass es diesen Blog gibt und immer gute Beiträge liefert und ein Dank an Tim Kunschke, der ja wohl hier einigen den Tag/Abend gerettet hat. Im Übrigen auch bei mir mit knapp 30 Kunden Exchange Servern – herzlichen Dank euch beiden!
Was die ewigen Diskussionen der Updates angeht, möchte ich mich einmal hier äußern. Es ist meine Meinung und es ist nur ein Kommentar von mir mehr nicht.
Wir hatte hier auch schon immer und zum Teil heftige Diskussionen ob man die Updates von Hand machen soll, oder aussetzen soll oder erst gar nicht machen, wie es von einigen Kollegen praktiziert wird.
Ich als verantwortlicher in meinem Team habe beschlossen die Updates immer und so schnell wie möglich durchzuführen. Mittlerweile habe ich es sogar über ein Patchmanagement automatisiert, so dass alle verfügbaren Updates immer umgehend installiert werden.
Ja es ist ein Risiko, dass danach ein Server oder Dienste nicht mehr funktioniert, wie wir jetzt wieder gesehen haben. Aber wenn keine Updates installiert werden, obwohl bekannt ist, dass es Sicherheitslücken gibt, die durch diese Updates geschlossen werden ist es grob fahrlässig, wenn man die Updates nicht installiert.
Keiner kann einem einen Vorwurf machen, wenn man etwas macht, jedoch wenn man nichts macht und dafür auch noch Geld kassiert.
Es gibt immer einen, der ein Problem lösen kann und andere dann daran teilnehmen lässt, wie hier im Beispiel Tim Kunschke. Ohne diese Leute hätten viele schon lange verloren und und bestimmt auch ihren Job nicht mehr. Daher nochmals Danke!
Teilt euer Wissen und helft anderen, wenn es wieder, so wie in diesem Fall Probleme gibt. Nur so kommen wir alle weiter und werden auch in Zukunft mit den Problemen die uns täglich in den Weg geworfen werden fertig.
So genug der Worte zum Tema Updates installieren oder nicht. Ich mach jetzt wieder was, wofür ich bezahlt werden und installiere noch ein paar Updates ;-).
Happy EDV Gruß Eitel
Grundsätzlich teile ich deine Meinung, kann aber nicht verstehen wei man 30 Kunden den Exchange abschießen kann ohne das Update mal selber vorher getestet zu haben. Das ist schon sehr unprofessionell wenn man dafür auch Geld verlangt. Ich hätte als Kunde da eine andere Erwartungshaltung an meinen Dienstleister.
Na ja,
soweit richtig aber bei zero day ist hop oder top angesagt. Kaputte Systeme sind das kleinere Übel im Vergleich zu ungebetenem Besuch.
Tatsächlich ist wohl die hohe Kunst in der Lage zu sein in solchen Situationen die Systeme schnell wieder auf die Füße zu bekommen.
„Although we are not aware of any active exploits in the wild“
Also Grund zur Panik sehe ich nicht und eine Stunde das Update vorher zu testen hat man eigentlich immer. Bei deinem zweiten Satz stimme ich dir zu, aber das sollte man auch ohne fremde Scripts in den Kommentarspalten einer Webseite hinbekommen, die womöglich auch noch ungetestet übernommen wurden :( Von einem professionellen Dienstleister der Geld dafür verlangt würde ich erwarten dass er solche Probleme auch direkt an MS eskalieren kann und nicht wie @Edres Askariare verzweifelt Fehlermeldungen hier postet.
Hat hier denn jemand was von „nicht installieren“ gesprochen? Normalerweise testet man auf einem Test- oder unkritischem Server solche Installationen und hat dann meist schon ein Ergebnis. Und ja Hafnium haben viele schon wieder vergessen. Aber auch die Probleme mit der Installation per WU/WSUS sind seit Exchange 2013 bekannt. Insofern kann man sich fragen, ob man sich auf sowas verläßt und hinterher die Arbeit hat dem Kunden oder der GF zu erklären, warum wiederholt Probleme aufgetreten sind (im Zweifel liegts ja eh immer an MS), oder man installiert es manuell und hat dann eben in der Hand sofort reagieren zu können.
„Ohne diese Leute hätten viele schon lange verloren und und bestimmt auch ihren Job nicht mehr.“
Naja, wenn das die Voraussetzung für meinen Job wäre, dann wär ich sicher nicht für meinen Job qualifiziert. Aber vielleicht wolltest du ja sowas auch ausdrücken. ;)
Microsoft hat einen Workaround zur Installation des Patches veröffentlicht: 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
(wir haben das noch nicht getestet)
Haben gerade die Installation mit dem Workaround durchgeführt auf EX16/19. Lief einwandfrei!
Healtch Checker meldet alles OK!
Habe mir ehrlicherweise eine Überarbeitung des patch erhofft..Kommt hoffentlich wohl noch, weil ich installiere doch jetzt nicht den Patch..haue mir dabei die Dienste weg und mache dann den Workaround?! Ohne zu wissen ob da nicht mehr kaputt geht
Nein wenn du die Anleitung aufmerksam gelesen hättet, legst du ja erst den AD Account an und installierst dann das Update erneut. Schritt 1 ist ja nur „if you’ve already tried to install the SU“ also wenn du deine Umgebung davor bereits abgeschossen hast.
Wo liegt den das Verzeichnis „\Exchange Server\V15\Bin“? …anscheinend bin ich blind!
Das liegt im Exchange-Installationspfad z. B. C:\Program Files\Microsoft\Exchange Server\V15\Bin
Woher komme ich den jetzt an die Deutsche Version Update? Ist ja Offline genommen. Einfach die Englische Version nehmen? Nach dem hin und her bin ich da etwas zurückhalten.
Nimm die englische. Wie unten schon erwähnt ist Exchange an sich multilingual. Auf einem deutschsprachigem System sind dann halt die Setup Dialoge auf englisch, aber der Exchangeserver selbst ist natürlich weiterhin wie gewohnt.
Schön, dass in dem Workaround dann noch ein Tippfehler (fehlende schließende Klammer) steckt und dass man in dem Zuge den Dummy Account an der Stelle nicht auch gleich wieder entfernt.
Der erste von zwei Exchange Server (Windows 2022 Exchange 2019 CU12) ist Garde durch gelaufen
Funktioniert so perfekt auch mit dem US Patch (D wurde ja entfernt). HealthChecker ist auch glücklich. Na dann… Danke für den Workaround.
Microsoft hat inzwischen alle August 2023 CUs für Exchange zurückgezogen und empfiehlt Admins auf nicht englischsprachigen Umgebungen die Installation vorerst zurückzustellen, bis die Probleme geklärt sind.
Hab in meinem Blog-Beitrag auch nochmals separat auf die Diskussionen hier verlinkt.
https://www.borncity.com/blog/2023/08/09/desaster-exchange-august-2013-sicherheitsupdate-nicht-installieren/
Guten Abend,
ist eigentlich bekannt, ob es wirklich nur nicht-englische Systeme betrifft? Bei heise heißt es, „, dass vor allem deutsche, beziehungsweise deutschsprachige Server betroffen seien. Vereinzelt berichteten nun aber auch französische Admins von den Problemen, während US-Admins keine Fehlermeldungen beobachteten“.
Hat hier wer genauere Infos die Sie\er Teilen mag? :)
Ich habe englische Systeme, tue mich trotzdem gerade schwer, das Update zu installieren…
VG
Keinerlei Probleme gehabt auf 5 englischen 2019 CU 13 Systemen.
Aber wo ist das Problem, das Update erstmal in einer Testumgebung oder auf einem System das nicht aktiv am produktiven Workload teilnimmt zu installieren und dann zu schauen, ob was kaputt geht in deiner Umgebung?
Und wer hat soviel Zeit?
@Roman:
Ist die Frage als Scherz zu verstehen?
Falls nicht bekannt, man kann die Installation auch scripten (2-Zeiler) und muss bei der Installation auch nicht die ganze Zeit zuschauen…
Ist auch in Italien und Polen aufgetreten – also: nicht-englische Systeme im Allgemeinen ;)
Hallo zusammen,
ich kann bestätigen, dass heute nacht unser WSUS das Exchange Sicherheitsupdate verschwinden hat lassen. Das Update wurde auch über WSUS zurückgezogen.
Viele Grüße
Wolfgang
500
Unerwarteter Fehler
Aufgrund eines Fehlers konnte die Anforderung nicht abgeschlossen werden. Bitte versuchen Sie es noch mal.
After i run the update i restart all the services but unfortunetly i cant start the ECP
the users can use outlook wihtout any problem but the eECP is showing an unerwarter Fehler 500
can someonehelp me how to solve this problem
500
Unerwarteter Fehler
Aufgrund eines Fehlers konnte die Anforderung nicht abgeschlossen werden. Bitte versuchen Sie es noch mal.
Es sind nicht alle Dienste wieder gestartet worden, z. B. Vom IIS fehlen noch Dienste, deswegen die Fehlermeldung
ich habe alle dienste neuegestarten und die ISS dienste habe ich auch neue gestartet
Vor dem gleichen Fehler standen wir auch, bei uns lief der Dienst IIS-Verwaltungsdienst in dem Fall nicht.
Sobald der Dienst wieder lief war ECP/OWA auch wieder verfügbar.
MSExchange OWA Meldung im Ereignisprotokoll:
The Active Directory system configuration session couldn’t be retrieved.
Exception message: „Das Webobjekt ‚IIS://xxxxxxxxxxxx‘ kann nicht gefunden werden.“.
Bei uns das selbe
Exchange 2019 CU 13 auf Server 2019 0x80070643 bei Windows Update, alle Exchange-relevanten Dienste incl. Publishing- /Filterdienst bleiben auf deaktiviert. Nach manueller Reaktivierung und Start der Dienste läuft der Exchange
von MS nun
Due to reports that Exchange setup fails on servers running on several languages other than English, we have temporarily removed August SU from Microsoft / Windows update until we find the root cause of the problem. We recommend our customers running non-English servers to pause installation until we provide more information.
Danke für die Info. Da bin ich ja mal gespannt, was die Ursache ist. ;)
Update ist nach wie vor verfügbar zum Download
Manuell auf jeden Fall, oder meinst du per WU/WSUS?
Nein manuell. WU/WSUS kommt für Exchange nicht in Frage (aus gutem Grund wie man sieht).
Ja natürlich ist es manuell noch verfügbar. Es wurde wie angekündigt von WU und WSUS zurückgezogen. Manuell zurückziehen geht nicht, weils ja durchaus auf der Welt nicht nur NICHT englischsprachige Systeme gibt, auf denen es zu Problemen kommt, sondern auch noch den Rest der mit englischsprachigen Systemen keine Probleme hat und seine Lücken jetzt schon patchen „darf“. ;)
>>Ja natürlich ist es manuell noch verfügbar. Es wurde wie angekündigt von WU und WSUS zurückgezogen. Manuell zurückziehen geht nicht, weils ja durchaus auf der Welt nicht nur NICHT englischsprachige Systeme gibt, auf denen es zu Problemen kommt, sondern auch noch den Rest der mit englischsprachigen Systemen keine Probleme hat und seine Lücken jetzt schon patchen „darf“. ;)<<
Sagt ja Keiner. Aber man hätte die "Nicht-englisch-sprachigen" Updates zurückziehen können. Da die Updates nicht installierbar sind, bleiben die ohnehin ungepatcht. Aber dann würde man den Leuten zumindest die Probleme erparen. Nicht Jeder liest hier und erfährt von dem Problem. MS schreibt es nach wie vor nicht in die Known Issues.
Dir ist aber klar, dass Microsoft immer multilanguage ist. Also auch ein „englischer“ Patch funktioniert auf einem deutschsprachigen Windows.
Microsoft Exchange natürlich. :)
Ja doch. Wir könnten hier offenbar noch tagelang darüber diskutieren. Habe ich aber keine Lust zu. Es geht darum, dass MS auf den Download-Quellen zumindest den Hinweis gibt, dass auf Nicht-Englisch-sprachigen Systemen derzeit nicht installiert werden soll. MS forciert die User doch die vorgeschaltete Sprachauswahl vorzunehmen, bevor man herunterlädt. Genau da kann man die betroffenen Sprachen zurückziehen, bzw. zumindest einen Hinweis auf das Problem geben, wenn schon nicht in den Known Issues.
Mit geht es hier auch weniger darum, wie MS das umsetzt, sondern, dass sie die User entsprechend informieren, sobald so ein Problem bekannt wird.
Nachtrag: Genau so hat es MS jetzt auch gemacht. Hinweis auf der Downloadseite und anderssprachige Downloads rausgenommen. Vorbildlich, wenn auch etwas spät.
Ergänzung:
If your server has been already impacted by failed setup, please do not try uninstalling anything. Re-enable Exchange Services by running the following from the \Exchange Server\V15\Bin folder. Reboot the server after this and services should start:
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-august-2023-exchange-server-security-updates/ba-p/3892811
was ich da jetzt so herauslese betrifft es nicht englische Installationen, kann das sein?
Wenn man das Update installiert, hat man anscheinend einen defekten Exchange Server, installiert man es nicht, werden als „hoch“ eingestufte Lücken nicht geschlossen.
Bin gespannt ob das MS bis zum WE behebt, andernfalls ist es ja eine kleine Katastrophe…
Mahlzeit zusammen,
ich kann es auch so bestätigen, das auf meinem Exchange 2019 CU13 (deutsch) auf Windows Server 2019 Standard (deutsch) das Update KB5029388 bei 41% hängen bleibt und mit dem Fehlercode 0x80070643 abbricht. Alle anderen Updates laufen problemlos.
Da ich Daily Snapshots mache, konnte ich auf den Stand von heute Nacht um 5 Uhr zurück gehen und das Problem nachstellen.
Alle Exchange und auch IIS Dienste waren deaktiviert, dadurch starten wegen Abhängigkeiten andere Dienste nicht mit und quittieren den Start mit einem 1068 Fehler.
Nach einem Neustarte des Servers, habe ich die Dienste mit dem Script von hier https://www.alitajran.com/restart-exchange-services-powershell-script/ wieder lauffähig gemacht und nach einem weiteren Neustart sind auch alle anderen Dienste wie mitgestartet. Ich habe bei administrator.de gelsen, das danach auch der Dienst „AppIDSvc“ manuell zu aktivieren und starten ist, den habe ich aber gar nicht.
Aber der Dienst „Leistungsprotokolle und -warnungen“ (Dienstname pla) war von automatisch auf manuell gestellt (habe Screenshots der Dienste vor dem Update gemacht).
Außerdem war nach dem Powershell Scipt der Dienst „Microsoft Exchange IMAP4“ (Dienstname MSExchangeImap4), „Microsoft Exchange-IMAP4-Back-End“ (Dienstname MSExchangeIMAP4BE) und „Tracing Service for Search in Exchange“ (Dienstname SearchExchangeTracing) auf automatisch gestellt, was vorher auf Manuell stand und dies habe ich auch wieder so geändert.
Zudem war auch der Dienst „Microsoft Exchange Search Host Controller“ (Dienstname HostControllerService) bei mir nach dem Script auf automatisch gestellt und war vor dem Update deaktiviert, auch dies habe ich wieder zurück geändert.
Auch war der Dienst „Microsoft Exchange-Integritäts-Manager-Wiederherstellung“ (Dienstname MSExchangeHMRecovery) bei mir nach dem Script auf deaktiviert gestellt und vor dem Update auf automatisch, was ich auch angepasst habe.
Ich habe das KB5029388 dann hier https://www.microsoft.com/de-de/download/details.aspx?id=105524 manuell auf Deutsch geladen und versuche es aktuell händisch als Administrator zu installieren, leider steht es nun schon fast eine Stunde auf „Please wait while the Setup Wizard oreoares to guide you through the installation“.
Ich werde heute Abend schauen, ob es weiter geht und werde nochmals berichten.
warte doch einfach ab, bis es einen Fix gibt. Es ist doch kein Hafnium…
Ich persönlich hoffe es wird auch kein Hafnium :D
Hallo Oliver, hat die manuelle Installation geklappt?
Danke und Gruß aus Köln
Hallo Ralf, leideer wie zu erwarten war, brach das manuelle Patchen auch mit folgendem Fehler ab:
START: Installation process initiated.
SUCCESS: Extracted contents to C:\Users\Administrator.xyz\AppData\Local\Temp\
ERROR: While installing the Exchange Server Update, error 1603 occurred.
Press any key to exit …
Ich hatte das KB5029388 dann mit Wushowhide ausblenden lassen.
Gerade nochmal geschaut und wie Microsoft angekündigt hat, ist es auch nicht mehr verfügbar.
Ich habe es richtig verstanden, wenn man nun installiert wird das Setup abbrechen und hinterlässt einen „kaputten“ Exchange Server und die Lücken sind laut Health Checker dann weiterhin da?
Sprich die Installation ist halt nicht komplett durchgelaufen.
Ja, es wird auf deutschen Systeme abbrechen. Es werden „nur“ die Dienste deaktiviert. Dienste neu starten, Microsoft Updatedienst deaktivieren und auf ein überarbeiteten Hotfix warten.
Bringt ein englisches Sprachpaket was ?
Unglaublich, was Microsoft hier durch Schlamperei für einen Schaden verursacht und es bis jetzt nicht der Mühe Wert findet, die Kunden zu informieren und zu unterstützen. Eine Sammelklage wäre da angebracht!
Es steht leider bis heute nicht mal unter Known issues with this release
Nach der Installation meldet der HealthChecker dass AES256-CBC Decyryption noch nicht konfiguriert ist.
Hier ist eine Anleitung dazu:
https://support.microsoft.com/en-us/topic/enable-support-for-aes256-cbc-encrypted-content-in-exchange-server-august-2023-su-add63652-ee17-4428-8928-ddc45339f99e
Betrifft aber wenn ich es richtig verstehe nur Hybrid Umgebungen bzw. Office 365 Apps
Bitte beachten, dass dabei auch der Windows Update-Dienst deaktiviert wird. Ansonten die Zeilen bitte auskommentieren oder löschen.
Powershell Script: bitte 2x ausführen ; – )
Get-Service WSearch| Set-Service -StartupType Automatic
Get-Service WSearch | Start-Service
Get-Service UALSVC | Set-Service -StartupType Automatic
Get-Service UALSVC | Start-Service
Get-Service Winmgmt | Set-Service -StartupType Automatic
Get-Service Winmgmt | Start-Service
Get-Service IISADMIN | Set-Service -StartupType Automatic
Get-Service IISADMIN | Start-Service
get-service W3SVC | Set-Service -StartupType Automatic
Get-Service W3SVC | Start-Service
get-service FMS | Set-Service -StartupType Automatic
Get-Service FMS | Start-Service
Get-Service MSE* | Set-Service -StartupType Automatic
Get-Service MSE* | Start-Service
Get-Service WbioSrvc | Set-Service -StartupType Automatic
Get-Service WbioSrvc | Start-Service
Get-Service HostControllerService | Set-Service -StartupType Automatic
Get-Service HostControllerService | Start-Service
Get-Service MSComplianceAudit | Set-Service -StartupType Automatic
Get-Service MSComplianceAudit | Start-Service
Get-Service MSExchangeFastSearch | Set-Service -StartupType Automatic
Get-Service MSExchangeFastSearch | Start-Service
Get-Service iphlpsvc | Set-Service -StartupType Automatic
Get-Service iphlpsvc | Start-Service
Get-Service SearchExchangeTracing | Set-Service -StartupType Automatic
Get-Service SearchExchangeTracing | Start-Service
Get-Service wuauserv | Set-Service -StartupType disabled
Get-Service wuauserv | Stop-Service
Get-Service MSExchangeNotificationsBroker | Set-Service -StartupType Automatic
Get-Service MSExchangeNotificationsBroker | Start-Service
Vielen Dank, Retter des Tages!
: – ) Gerne
Ich danke vielmals hierfür.
Gerade den Fall gehabt und einfach kurzerhand nach dem Update gesucht.
Dein Post hat mir jetzt vor dem Mittag ma schnell den Hintern gerettet :)
Gerne. :)
Herzlichen Dank dafür!
Gern. : – )
Hallo Tim, you made my day. Vielen Dank. Vielleicht ist es auch interessant, dass dabei auch die Remote Registry deaktiviert wird und der DFS Name Space auch mit Fehler 1068 nicht startet. Remote Registry wieder auf automatisch setzen und danach den DFS Name Space starten und schon ist alles wieder in grün.
Hallo Rudolf,
gern geschehen. Den Remoteregistry-Dienst würde ich immer abschalten, außer er wird dringend benötigt. Ansonsten kannst du per „SC“ auch die Abhängigkeit für den DFS-Dienst ändern. Mich wundert gerade, dass auf dem Exchange ein DFS-Dienst läuft. Aber das soll hier gerade nicht zum Thema werden. : – )
Danke Tim!
Gerne. : – )
Super. Danke.
Du hast mir den Tag gerettet.
Daumen Hoch !!!!
Gern. =)
Hey Tim, ich danke Dir, hat bei mir geholfen.
Vielen lieben Dank. VG
Gern geschehen. =)
Bei mir hat das Script leider an einer Stelle nicht funktioniert:
Der Dienst „Microsoft Exchange IMAP4 (MSExchangeImap4)“ startet nicht mit dem Fehler:
Start-Service : Fehler beim Starten des Diensts „Microsoft Exchange IMAP4 (MSExchangeImap4)“.
In Zeile:1 Zeichen:20
+ Get-Service MSE* | Start-Service
+ ~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (System.ServiceProcess.ServiceController:ServiceController) [Start-Service],
ServiceCommandException
+ FullyQualifiedErrorId : StartServiceFailed,Microsoft.PowerShell.Commands.StartServiceCommand
Hat dafür irgendjemand nen Tipp?
Was passiert denn, wenn du den Dienst manuell startest?
Bei manuellem Start kommt leider nur die Fehlermeldung, dass der Dienst nicht gestartet werden kann. Server startet grade neu, daher kann ich nicht sagen, ob noch ein zusätzlicher Hinweis erscheint.
Vielleicht geht’s ja nach dem Neustart. Melde mich …
Klasse: Neustart hat dazu geführt, dass offenbar erneut versucht wird, das Update einzuspielen. Server steht seit 40 Minuten auf „Windows wird vorbereitet“. Ich kotze.
Also Neustart ist durch. Alle Dienste laufen, außer „Microsoft Exchange IMAP4“. Wenn ich versuche, diesen zu starten, kommt nur „Dienst wurde gestartet und dann angehalten“.
In der Ereignisanzeige steht für diesen Dienst der Fehler „The IMAP4 server can’t find the configuration. The process failed to read the Exchange topology in the allotted time.“
Hat jemand ne Idee?
Noch ne blöde Frage: Obwohl der IMAP-Dienst nicht läuft, kommen aber in Outlook neue Mails an. Wird für den Mailabruf von Outlook gar kein IMAP gebraucht? Dann wäre es ja normal, dass keine IMAP-Konfiguration gefunden wird und der IMAP-Dienst kann auch deaktiviert bleiben.
Sorry, bin hier nur Urlaubs-Vertretung.
Hallo Michael,
Outlook verwendet in der Regel kein IMAP (oder POP). Wenn du es also nicht für andere Clients benötigst, kannst du es deaktiviert lassen. In der Standardkonfiguration ist kein IMAP aktiv, daher kannst du es wahrscheinlich auch ignorieren.
Beste Grüße,
Frank
Danke Tim und Franky.
Als Zusammenfassung also nochmal: Tims Script ist Gold wert.
Da der Befehl „Get-Service MSE* | Start-Service“ aber auch die evtl. nicht benötigten IMAP- und POP-Dienste versucht zu starten, muss man bei Bedarf die folgenden Dienste abschalten und auf Starttyp „Manuell“ setzen:
– Microsoft Exchange IMAP4
– Microsoft Exchange POP3
– Microsoft Exchange-IMAP4-Back-End
– Microsoft Exchange-POP3-Back-End
Gerne : – )
Hallo Tim,
ich danke dir vielmals du hast mir die Nacht gerettet. Ich sitze seit Stunden und versuche dieses scheiß Update zu deinstallieren, die Dienste gingen immer wieder von selber aus. Jetzt klappt es wieder.
Vieeeelen Dank
Gern geschehen. =)
Vielen Dank!
Ich schließe mich an ==> Mein Held des Tages!
Jetzt ist meine Laune wieder etwas gestiegen.
Grüße ==> L.
Gerne. : – )
Wiedermal ein tolles Update von Microsoft. Wird mitten am Tag automatisch installiert und legt das komplette System lahm und sobald man alle Dienste wieder am laufen hat versucht es Windows Update automatisch erneut. Der Dienst wurde nun deaktiviert. Ich hoffe das als bald einen Fix gibt für alle nicht englischen Installationen.
Kommt doch NIE nie Nie überhaupt gar nicht jemals zu Problemen mit der Installation per Windows Update. ;)
Auch wenn es diesmal auch Probleme mit der manuellen Installation gibt, hat man dort zumindest noch den Zeitpunkt des Kaputtmachens in der Hand. Insofern: Keine Installation von Exchange Security Updates per Windows Update oder WSUS.
naja kann man so pauschal auch nicht sagen, einfach Automatische Updates generell ausschalten und nur am Update Tag anmachen?
Reicht doch vollkommen aus. Hatte gestern den richtigen Riecher, dass ich automatische Updates mal ausgesetzt habe :-D
Nein automatische Updates für Exchange einfach abschalten. Ja da kann man differenzieren (mit WSUS sowieso).
Sorry aber selber schuld wer Exchange Updates automatisch über Windows Update einspielt und dann auch noch den ganzen Kram auf deutsch betreibt….
Sorry, aber Du hast ne Realitätsverschiebung!
Microsoft verkackt regelmäßig die Upgrades auf ganzer Linie und dann ist der Benutzer Schuld, der genau das tut, was man Ihm von Microsoft sagt.
Wo sagt MS dass man die Exchange Updates automatisch per WSUS einspielen soll?
Das Gegenteil ist der Fall. Und wer schon einmal nach deutschen Fehlermeldungen gegooglet hat, sollte eigentlich auch von selbst auf die Idee kommen, dass es wenig sinnvoll ist Exchange auf deutsch zu betreiben.
Bei MS steht aktuell ein erster Eintrag, dass es auch französische Systeme betrifft und ein Hinweis das sich wohl auch andere SUs (ggf. nachdem diese vorher entfernt wurden) nicht wieder installieren lassen.
Sollten sich da jetzt generell keine SU mehr installieren ist vielleicht mehr kaputt als nur das aktuelle SU.
Ich bin glücklicherweise nicht betroffen da ich bewusst alles in englisch installiere um u.a. solche Sachen zu vermeiden. Es wundert mich immer wieder, dass ein Milliardenkonzern wie Microsoft es nicht auf die Reihe bekommt, Patches gründlich zu testen. Das war jetzt nun wirklich kein Edge Case. Jeweils eine virtuelle Exchange Installation in jeder verfügbaren Fremdsprache und wir hätten keine tausenden Kunden mit kaputten Exchange Installationen.
Hätte auch mit englisch passieren können, ist keine Garantie in meinen Augen.
Moin, hier hat es zwei deutschsprachige Exchange 2019 erwischt. Auf beiden konnten die Dienste erst auf „Automatisch“ gestellt werden, und dann die DIenste wieder gestartet werden. Für WSUS-Systeme empfehle ich, das Update zu blockieren. Für nicht-WSUS-Systeme habe ich die Automatischen Updates vorübergehend deaktiviert.
Moin Flo. Danke! So in der Art dachte ich auch schon. Habe das Update auf „nicht genehmigt“ gestellt, die Automatismen vorübergehend deaktiviert und markiere andere wichtige Updates dann eben manuell als freigegen.
Verschwindet das Exchange Update dann auf dem Exchange irgendwann „von selbst“ (aussitzen) oder evtl. erst nach einem Reboot (ohne irgendwelche Updates zu machen)..?
MaGGs
Ich habe den Windows Update Service kurz beendet und dann alles in SoftwareDistribution/Downloads gelöscht. Danach den Dienst wieder starten.
Es stand zwar dann immer noch „Update installieren“ da, aber wenn man den button klickt rennt WU sofort in einen Fehler, weil die Installationsdaten ja nicht mehr existieren. Danach war das ganze erledigt und WU hat wieder „Keine Updates verfügbar“ ausgegeben.
Gruß
Jupp. Nach einem recht kurzen Neustart (ohne jegliche Update-Installation) ist der Updatestatus nun bereinigt. Das Exchange Update ist „wech“. ;0)
Moin! Hat schon jemand das angesprochene CU Update für den Exchange in Verbindung mit WSUS ausgerollt? Also zusammen mit den aktuellen Rollups .NET und Cumulative Update 2023-08?
Oder taucht dieses Problem vielleicht nur auf, wenn das Exchange Update einzeln installiert wurde?
Danke im Voraus für Erfahrungsberichte. ;0)
Hi,
bei uns konnte ich die meisten Dienste wieder starten, allerdings lässt sich der Transportdienst nicht starten.
Meldung: Fehler 1608: Der Abhängigkeitsdienst oder die Abhängigkeitsgruppe konnte nicht gestartet werden.
Hat jmd eine Idee warum der Dienst nicht startet?
Auf Exchange 2019 … Update deinstallieren …
Dienste wieder starten ….
hat hier geholfen …
# Automatic services
$auto = „MSExchangeADTopology“,
„MSExchangeAntispamUpdate“,
„MSExchangeDagMgmt“,
„MSExchangeDiagnostics“,
„MSExchangeEdgeSync“,
„MSExchangeFrontEndTransport“,
„MSExchangeHM“,
„MSExchangeImap4“,
„MSExchangeIMAP4BE“,
„MSExchangeIS“,
„MSExchangeMailboxAssistants“,
„MSExchangeMailboxReplication“,
„MSExchangeDelivery“,
„MSExchangeSubmission“,
„MSExchangeRepl“,
„MSExchangeRPC“,
„MSExchangeFastSearch“,
„HostControllerService“,
„MSExchangeServiceHost“,
„MSExchangeThrottling“,
„MSExchangeTransport“,
„MSExchangeTransportLogSearch“,
„MSExchangeUM“,
„MSExchangeUMCR“,
„FMS“,
„IISADMIN“,
„RemoteRegistry“,
„SearchExchangeTracing“,
„Winmgmt“,
„W3SVC“
# Manual services
$man = „MSExchangePop3“,
„MSExchangePOP3BE“,
„wsbexchange“,
„AppIDSvc“,
„pla“
# Enable Services
foreach ($service in $auto) {
Set-Service -Name $service -StartupType Automatic
Write-Host „Enabling „$service
}
foreach ($service2 in $man) {
Set-Service -Name $service2 -StartupType Manual
Write-Host „Enabling „$service2
}
# Start Services
foreach ($service in $auto) {
Start-Service -Name $service
Write-Host „Starting „$service
}
Total unterschiedliches Verhalten:
auf 2 Servern (1x 2019/CU12 de und 1x CU2019/CU13 de) mit dem fehlgeschlagenen Update funktionierte dieses Skript zum Starten der Dienste.
bei anderen 4 Servern (4x 2019/CU12 de) schlug das Update ebenfalls fehl und das Skript brachte keinen Erfolg. Manche Dienste (z.B. Transportdienst) können nicht mehr gestartet werden trotz Checks der Abhängigkeiten. Nicht nachvollziehbares Verhalten. Auf manchen Servern funktionieren dann einige Dienste und einige nicht. Deinstallation oder Reinstallation des aktuellen SU schlagen ebenfalls fehl.
Wir mussten auf den Servern das Upgrade auf CU13 und nachfolgendes SU vom Juni KB5026261 installieren, danach funktionierte es wieder. Damit sind wir zumindest wieder auf den Stand vor dem Update.
Wir warten jetzt bis Microsoft eine Fehlerbehebung zu diesem Update bringt.
Danke für das Skript. Bei mir laufen die Dienste jetzt wieder alle.
Danach müssen folgende Services wieder auf Automatic gestellt werden,
danach müssen alle Services gestartet werden
Alle Microsoft Exchange ausser imap und Pop
WWW-Publishingdienst
IISAdmin Service
Windows-Verwaltungsinstrumentation (nur Server 2016)
Microsoft-Filterverwaltungsdienst
Get-Service | Where-Object { $_.DisplayName –like “IIS*” } | Set-Service –StartupType Automatic
Get-Service | Where-Object { $_.DisplayName –like “WWW*” } | Set-Service –StartupType Automatic
Get-Service | Where-Object { $_.DisplayName –like “*Filter*” } | Set-Service –StartupType Automatic
Get-Service | Where-Object { $_.DisplayName –like “Microsoft Exchange*” } | Set-Service –StartupType Automatic
Get-Service | Where-Object { $_.DisplayName –like “*POP*” } | Set-Service –StartupType Disabled
Get-Service | Where-Object { $_.DisplayName –like “*IMAP*” } | Set-Service –StartupType Disabled
Get-Service | Where-Object { $_.DisplayName –like “IIS*” } | Start-Service
Get-Service | Where-Object { $_.DisplayName –like “WWW*” } | Start-Service
Get-Service | Where-Object { $_.DisplayName –like “*Filter*” } | Start-Service
Get-Service | Where-Object { $_.DisplayName –like “Microsoft Exchange*” } | Start-Service
Moin,
es müssen ALLE Dienste aus dem Script (s.u. Thomas Swoboda) überprüft und ggf. modifiziert werden, nicht nur die MS Exchange-Dienste.
Wir hatten das Update auf zwei Systemen installiert (EX2016 auf WS2016), beide danach out-of-order.
Nach dem Nachfrisieren der Dienste (bzw. nach Ausführen des Scripts) haben wir beide Server komplett neu gestartet – mit Erfolg, läuft wieder.
Mal wieder viel Herzklopfen, auf das wir gerne verzichtet hätten :-/
I❤MS
Windows Search muss gestartet sein. Wird auch deaktiviert beim Update.
Ich verwende dieses Script: https://blog.heeb-online.ch/Archive/668
Hat einwandfrei funktioniert.
Hi,
das müsste der Dienst Microsoft Filerverwaltungsdienst sein (FMS).
Der wird ebenfalls deaktiviert…
VG
Hallo Zusammen,
hatte auch das Problem. Windows OS 2019; Exchange 2019 CU12 Deutsche Installation – die Dienste waren danach alle deaktiviert. Konnte die Dienste neu starten und es lief nach einem Neustart wieder alles.
Also ein Server hatte alle Dienste aktiviert, dann Neustart und dann waren alle deaktiviert. Mit dem Tipp von Tristan die Dienste wiederbelebt und neu gestartet, hat lange gedauert, klappte aber wieder (2016 CU23 auf 2016 Server). Einen zweiten Server musste ich komplett restoren, da muss ich dann schnell die Updates für andere MS-Produkte abschalten damit er das Update nicht wieder aufspielt. Ich hoffe es ist inzwischen von MS gesperrt?!
Kleiner Hinweis zu dem CVE-2023-21709-Script:
Zitat:
„This script must be run as Administrator in Exchange Management Shell (EMS). The user must be a member of the Organization Management role group.“
Wer also eine feinere Rechtezuteilung bei ggf. mehreren Admin-Konten hat, sollte unbedingt aufpassen, welches Konto das richtige ist, sonst könnte das Script wirkungslos sein oder auch wieder irgendwelchen undokumentierten Schaden anrichten.
Wo soll das noch hinführen…
Bei uns ist die Installation des Updates KB5029388 ebenfalls fehlgeschlagen und alle Exchange Dienste standen auf „deaktiviert“. Nach manuelle Aktivierung der Dienste läuft nun erstmal wieder alles.
idem pour moi
os et exchange francais
Hallo, bei mir standen 2 Server leider auf automatische Updates, bei einem sind alle Dienste gestartet aber trotzdem kein Zugriff. Mal schauen wie es bei nach dem Neustart aussieht. Beim 2. hatte er das Update noch nicht angefangen, vielleicht kann man das noch stoppen. Von MS scheint es noch keine Reaktion zu geben? Die Trefferquote mit versenkten deutschen Exchange-Server scheint ja doch sehr hoch zu sein…
„…alle Dienste gestartet aber trotzdem kein Zugriff“ lag bei uns am ebenfalls deaktivierten WWW-Publishingdienst.
Exchange 2019 CU13 mit SU1 KB502626 ist ebenso betroffen. Error 1603 bei manueller Installation. Dienste lassen sich händisch wieder starten. Läuft erst mal wieder (zum Glück). OS und Patchsprache ist deutsch.
Was macht MS eigentlich ?
… mit fehlerhaften Updates versuchen die Kunden in die Cloud zu zwingen….
Das war auch mein Gedanke … :-/
Bin gespannt, wie lange es dauert, bis sie es korrigieren.
Bildlich gesprochen vermutlich das, was wir bei uns in der Firma „zertifizieren“ nennen (Tip: Wir verwenden das Wort „zertifizieren“ als Euphemismus für „Absondern von Feststofffäkalmasse“.)
Hier ebenfalls mit Exchange 2019 CU13 fehlgeschlagen.
Darum vorher immer Prüfpunkt/Snapshot erstellen :)
Voll korrekt!
Naja, wenn man auf potentiellen Datenverlust steht, dann macht man vorher einen Snapshot. ;)
Nicht wenn man den Server vorher in den Wartungsmodus versetzt!
Zur Sicherheit kann man noch port 25 sperren und Dienste Stoppen.
Was spricht danach gegen ein Snapshot?
Keine Ahnung welche Server ihr habt und wann ihr Updates einspielt, aber so ein Exchange Update dauert bei unseren Servern keine 10 Minuten. Das Update wird i.d.R. nachts und offline eingespielt. Somit kommt keine Email rein oder raus. Ergo: kein Datenverlust.
Na ist doch schön, dass das bei euch alles nicht zutrifft. Gibt hier (wenn ich mir die Probleme mancher so durchlese), aber offenbar genug Leute die das dann einfach machen, auch wenn sie noch nie was vom Wartungsmodus oder Redundanz gehört haben. Insofern vorher lieber mal eine Warnung, wenn von Snapshots (ohne Randbedingungen) gesprochen wird.
Hier ebenso 2019 CU13 Fehler 1603 – nichts zu machen. Backup zurückgespielt.
Hier keine Probleme.
Exchange 2019 auf Server 2022 Core per Windows Update
Exchange 2016 auf Server 2016 GUI manuell mit Elevated Shell
Beide Server auf Englisch & ohne DAG, hab vorher wie üblich die aktuellen CUs von Windows installiert & neu gestartet.
Script ebenfalls auf beiden ohne Probleme.
Diejenigen, die Probleme mit der Installation haben. Ein deutscher Admin hat mich per PM auf seinen bei Microsoft unter dem Alias bloodking geposteten Workaround hingewiesen:
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-august-2023-exchange-server-security-updates/bc-p/3894481/highlight/true#M36648
Hilft der vielleicht, die Dienste wieder zu starten?
Bei mir leider nicht :-( … die Dienste beenden sich immer wieder.
Brauche dringend eine Lösung … könnte kotzen :-(
Habe das Script ausprobiert. Hat bei einem Sever funktioniert.
Bei zwei anderen wieder nicht – es starten einige Dienste und beenden mit einer Fehlermeldung.
Wir testen gerade ein CU Update auf 13 durchzuführen (danach das SU vom Juni) ob sich dadurch die Fehler beheben lassen.
Wird noch eine lange Nacht werden.
Gruß
Das script hat bei mir geholfen, bei den automatischen Diensten fehlt im script noch Wsearch,
PowerShell starten und Befehle ausführen (ist für 2016 und 2019, daher wird bei dem 2019 der UM Dienst als Fehler markiert, einfach ignorieren); wer POP und IMAP nutzt, muss diese manuell in den Diensten auf Automatisch setzen:
Get-Service -name MSExchangeDelivery, MSExchangeRepl,MSExchangeRPC,MSExchangeFastSearch, MSExchangeThrottling, wsbexchange,MSExchangeSubmission, MSExchangeMailboxReplication, MSExchangeMailboxAssistants, MSExchangeIS, MSExchangeDagMgmt, MSExchangeDiagnostics, MSExchangeFrontEndTransport, MSExchangeADTopology, MSExchangeAntispamUpdate, MSExchangeUM, MSExchangeEdgeSync, MSExchangeHM, MSExchangeHMRecovery, MSExchangeServiceHost, MSExchangeTransport, MSExchangeTransportLogSearch, FMS, HostControllerService, winmgmt, remoteregistry, w3svc, iisadmin | set-service -startuptype automatic
System neu starten, danach ist der Spuk wieder vorbei.
super hat auf allen systemen geklappt, DANKE !!
hat bei mir auch geklappt! Danke
Hatte auch Probleme auf dem Exchange 2019 CU12, hat nicht funktioniert. Alle Dienste waren anschliessend auf deaktiviert. Habe alle wieder auf Automatisch gestellt und gestartet, danach lief alles wieder. Anschliessend habe ich CU13 installiert, das Setup ist auch abgebrochen beim Transpotservice. CU13 Setup nochmals gestartet, eine fehlerhafte Installation wurde erkannt, danach lief das Setup durch, im Moment läuft der Exchange wieder, mit dem KB5029388 warte ich noch.
Konntest du die Dienste einfach so wieder starten? Bei uns lassen die sich nicht mehr starten …
Folgende Dienste wurden vom Security Update deaktiviert und müssen wieder auf Automatisch Starten gesetzt werden (Extract aus dem Setup Logfile) – gilt für Exchange 2016 CU23 auf Windows Server 2016:
[20:38:24] Disabling services for ‚AdminTools ClientAccess FrontendTransport Bridgehead Mailbox UnifiedMessaging’…
[20:38:24] Disabling service ‚FMS‘.
[20:38:24] Disabling service ‚HealthService‘.
[20:38:24] Disabling service ‚hostcontrollerservice‘.
[20:38:24] Disabling service ‚IISAdmin‘.
[20:38:24] Disabling service ‚MSExchangeADTopology‘.
[20:38:24] Disabling service ‚MSExchangeAntispamUpdate‘.
[20:38:24] Disabling service ‚MSExchangeDagMgmt‘.
[20:38:24] Disabling service ‚MSExchangeDelivery‘.
[20:38:24] Disabling service ‚MSExchangeDiagnostics‘.
[20:38:24] Disabling service ‚MSExchangeEdgeSync‘.
[20:38:24] Disabling service ‚MSExchangeFastSearch‘.
[20:38:24] Disabling service ‚MSExchangeFrontendTransport‘.
[20:38:24] Disabling service ‚MSExchangeHM‘.
[20:38:24] Disabling service ‚MSExchangeHMRecovery‘.
[20:38:24] Disabling service ‚MSExchangeIMAP4‘.
[20:38:24] Disabling service ‚MSExchangeIMAP4BE‘.
[20:38:24] Disabling service ‚MSExchangeIS‘.
[20:38:24] Disabling service ‚MSExchangeMailboxAssistants‘.
[20:38:24] Disabling service ‚MSExchangeMailboxReplication‘.
[20:38:24] Disabling service ‚MSExchangePOP3‘.
[20:38:24] Disabling service ‚MSExchangePOP3BE‘.
[20:38:24] Disabling service ‚MSExchangeRepl‘.
[20:38:24] Disabling service ‚MSExchangeRPC‘.
[20:38:24] Disabling service ‚MSExchangeServiceHost‘.
[20:38:24] Disabling service ‚MSExchangeSubmission‘.
[20:38:24] Disabling service ‚MSExchangeThrottling‘.
[20:38:24] Disabling service ‚MSExchangeTransport‘.
[20:38:24] Disabling service ‚MSExchangeTransportLogSearch‘.
[20:38:24] Disabling service ‚MSExchangeUM‘.
[20:38:24] Disabling service ‚pla‘.
[20:38:24] Disabling service ‚RemoteRegistry‘.
[20:38:24] Disabling service ‚SearchExchangeTracing‘.
[20:38:24] Disabling service ‚W3Svc‘.
[20:38:24] Disabling service ‚WinMgmt‘.
[20:38:24] Disabling service ‚wsbexchange‘.
Die Default Einstellungen für die Dienste sind hier zu finden: https://learn.microsoft.com/en-us/exchange/plan-and-deploy/deployment-ref/services-overview?view=exchserver-2016
Problem ebenfalls bestätigt (EX2016, Error 1603):
Dienste auf „automatisch“ gestellt (nicht manuell gestartet) und Exchange Server durchgestartet. Hat etwas gedauert, aber langsam kommt alles wieder.
Datenbanken standen teilweise auf „DisconnectedAndResynchronizing“. Sind nun aber wieder „Healthy“.
Keine Chance.. musste Veeam restoren lassen. Zum Glück laufen die Backups jeweils um 18 Uhr.
Kein Exchange-Update mehr ohne Snapshot in vSphere.
Ich habe die Probleme auf voll gepatchten Exchange 2016 CU23 auf Windows Server 2016 mit DE OS.
Im Update Log steht:
msgInterimIncorrectRollup = Installation cannot continue. The Setup Wizard has determined that this Interim Update is incompatible with the current Microsoft Exchange Server 2016 Cumulative Update 23 configuration.
Es steht bei mehrfachem Ausführen immer mal ein anderer KB Artikel drin. Mal ist es ein Exchange SU vom letzten Jahr, mal ist es ein vorhergehendes aus diesem Jahr.
Auf Servern mit Betriebssystemsprache Englisch ist das Update fehlerfrei durchgelaufen.
Hallo,
der Fehlercode 1603 tritt mit großer Wahrscheinlichkeit auf deutschen Exchange Servern (oder Betriebssystem) auf. Daher die Empfehlung das Update zunächst nicht auf deutschen Servern zu installieren.
Beste Grüße,
Frank
Hallo,
Gibt es eventuell schon hinweise wie der Fehler zu lösen wäre das der Exchange 2019 mit CU12 wieder funktioniert?
Wir haben leider gleich mit der Update Installation begonnen. In den Foren steht noch sehr wenig.
Gruß
Lupo
Danke! dann warte ich noch damit.
Hat zufällig jemand von euch Eset im Einsatz?, weil diese gemeinsamkeit hätte ich auf allen
Bei uns läuft nur Defender. Dachte auch schon an korrupter Signatur mal wieder, aber daran scheint es dann wohl nicht zu liegen, denke ich.
Cisco AMP
Bei den fehlgeschlagenen Exchange Server ist CU12 aktiv.
Wir haben einen mit CU13 dort ist Update auch fehlgeschlagen jedoch funktioniert der eine Exchange nach dem Neustart wieder.
Jedoch fehlt uns die Vorgangsweise was wir mit den Cu12 machen sollen die jetzt nicht funktionieren.
Gruß
Sind eventuell Exchange- und andere Windows-Dienste deaktiviert? War bei mir auf zwei Systemen der Fall, da das Setup nicht alle Änderungen zurück rollt. VG
Die Dienste stehen auf Automatisch werden gestartet und beenden sich wieder oder stürzen ab.
Gibt es einen Exchange 2019 mit cu12 der nach dem Update wieder funktioniert?
Sieht momentan so aus als müssten wir die Exchange restoren.
Gruß
Hallo zusammen,
von den Betroffenen einer mit Exchange 2019 CU 13 dabei?
Liest sich auf den ersten Blick ein Problem beim 2016er und 2019 cu 12
Ja 2019 CU 13 betroffen. Verschiedene Systeme immer Fehler 1603
Kann ich auch bestätigen, egal ob 2016 CU23 oder 2019CU12. Bei allen kommt Error 1603
Bei uns funktionieren alle Exchange Server nach dem fehlgeschlagenen Update nicht mehr.
Bekomme ebenfalls Error 1603
Gibt es schon jemand der den Exchange nach dem Fehler wieder zu laufen gebracht hat?
Ich musste alle Dienste wieder auf automatisch stellen und anschließend starten. Achtung: Auch die Abhängigkeiten beachten! Anschließend das HealChecker Script durchlaufen lassen und schauen, ob man alle Dienste erwischt hat. Anschließend mal neu starten.
Bei mir hat das geholfen und läuft zum Glück noch alles.
Gruß
Danke für den Tip.
Hat bei uns leider nicht geholfen die Dienste starten nicht mehr.
Gibt es vielleicht noch andere Tips?
Gruß
Hier auch keine Probleme mit Exchange 2019 CU13
Beste Grüße,
Frank
Also vermutlich keine deutschsprachige Installation, oder?
Vorsicht vor dem Update!!! Update funktioniert nicht!
Verschiedene EX 16/19 brechen die Installation ab und machen einen Rollback. Ausgeführt als Administrator.
Kann ich derzeit nicht bestätigen.
Eben den ersten von drei Exchange 2019 Cu13 erfolgreich gepatcht inkl. PS-Script, Läuft soweit alles normal.
Eben den zweiten Exchange 2019 CU13 erfolgreiche gepatcht, der erste läuft auf Windows Server 2019 Core, der zweite auf Windows Server 2022 Desktop Experience.
Ich habe jetzt mal das mit den Diensten beobachtet, bei beiden Exchange Servern wurde während der Installation des SU nur der Dienst „Microsoft Exchange Search Host Controller“ (HostControllerService) beendet und deaktiviert, alle andere Dienste wurden weder beendet noch deaktiviert.
Sorry, hatte ich vergessen zu erwähnen, beide erfolgreich gepatchten Exchange auf englischem OS und englischem Exchange.
Uff, und ich dachte schon ich bin der einzigste…
Update will absolut nicht. Schon mehrfach per elevated prompt probiert. Schlägt entweder fehl oder meckert, wegen „files in use“. Sowas hatte ich noch bei keinem Update…
Ich doktor da jetzt mal nicht weiter rum und versuch den Exchange wieder zum laufen zu bringen.
Gruß
Habe es schon per Windows Update, Elevated Prompt und die EXE-Datei als Administrator probiert, ohne Erfolg.
Egal ob EX16 oder EX19 das Update will nicht.
Bekomme den Fehler:
error 1603 occurred
Das Problem kann ich bei Ex16 auf Server 2012R2 bestätigen, Update schlägt mit Error 1603 fehl, konnte die Dienste wieder starten, lief danach wieder, habe trotzdem das Backup zurückgespielt.