Die Installation der November Updates v2 kann nicht erfolgen.
Error:
Product: Microsoft Exchange Server -- Error 1935. An error occurred during the installation of assembly 'Microsoft.Exchange.Data.Common,version="15.1.2503.00",fileVersion="15.1.2507.44",culture="neutral",publicKeyToken="31BF3856AD364E35",processorArchitecture="MSIL"'. For more information, refer to Microsoft Help and Support. HRESULT: 0x800700B7.
Die November v1 Updates wurden bisher nicht installiert. Windows Server Updates 2025-1 sind bereits installiert.
Das Problem wird vermutlich in Verbindung mit den Server 2025-1 Updates verursacht.
Kann jemand die Situation bestätigen oder hat eine Lösung?
Nachdem die Installation nicht möglich ist, wird die Installation vollständig zurück gesetzt. Die Exchange Version bleibt auf dem alten bisherigen Stand.
Source:
Trotz intensiver Recherche konnte ich bisher keine Lösung finden.
Kann man die 01-2025 Updates von Windows nicht erstmal deinstallieren?
Die Deinstallation 01-2025 ist bisher auf dem Live System nicht erfolgt. Kann jemand die Situation mit dem Exchange November Update v2 bestätigen?
Ich habe auch die Fehlermeldung 0x800700B7 bei der Installation des Exchange November SUv2 mit Windows Server 2019 CU 01-2025 und Exchange Server 2019 CU14 erhalten.
Jedoch unterscheiden sich die angegebenen Versionen: Microsoft.Exchange.Data.Common,version="15.2.1540.00",fileVersion="15.2.1544.14"
@vtobi: Ich hatte eben das selbe Problem wie @andre-wiedemann und bin über eine Googlesuche auf diesen Beitrag gestoßen.
Bei mir war es auch Win 2019 mit installiertem 01-2025 Update und Exch. CU14.
Der Vorschlag von @norbertfe das 01-2025 Update wieder zu deinstallieren, war bei der Konstellation dann erfolgreich.
Hallo in die Runde,
ich hatte gerade in einer Testumgebung keine Probleme mit dem Update. Hier war auch bereits das Januar Update für Windows Server 2025 installiert. Danach dann das Exchange Novemver v2 Update. Betriebssystem ist hier in englischer Sprache.
Die Probleme riechen wieder ein bisschen nach Probleme mit "nicht-englischem" Betriebssystem. Ist dies bei euch der Fall?
Beste Grüße,
Frank
Du hattest aber kein Exchange 2016 auf dem Windows 2025 vermute ich. ;)
@norbertfe Ne, Exchange 2019. @andre.wiedemann schrieb von Exchange 2019. Ältere Versionen hab ich gerade nicht zur Hand.
Die Situation konnte noch nicht nachgestellt werden, mit der Deinstallation des Updates 01-2025. Es ist ein deutscher Exchange Server 2016 im Einsatz unter Windows Server 2016 Datacenter.
@franky ahja das hatte ich übersehen. Du hast schon Zugriff auf cu15? 😊 berichte doch mal, oder musstest du nda unterschreiben?
Habe hier bei einem Kunden ein deutschen Windows Server 2016 Standard mit deutschem Exchange 2016 (auch noch kein NovSUv1 eingespielt, AdminVersion ist 15.1.2507.18), selbe Fehlermeldung.
Nach Deinstallation von 01-2025 CU für Windows Server (KB5049993) bricht der Versuch des Exchange-Updates NovSUv2 direkt ab, bevor das Setup noch irgendwas macht (Ladebalken). (Man landet relativ schnell auf der letzten Seite, nachdem die Installation gestartet wurde (nach Klick auf Weiter und Akzeptieren der Bestimmungen), wo man "Fertig stellen" anklicken kann und im Text steht, dass die Installation nicht geklappt hat.
Hallo ich kann das Problem bestätigen. Auf einem Deutschen Server 2016 mit installierten KB5049993 wurde die Installation des Exchange 2016 SU mit dem Assembly Fehler abgebrochen. Auf einen anderen deutschen Server 2016 der das KB noch nicht installiert hatte lief die Installation durch.
Ich konnte auf dem betroffenen Exchange das Windows Update auch nicht deinstallieren. Ich erhalte dabei folgende Fehlermeldung: "Ein Fehler ist aufgetreten. Es konnten nicht alle deinstalliert entfernt werden."
Good morning,
nachdem ich heute Nacht auch Spaß mit dem Fehler hatte, möchte ich Euch hier meine Lösung mitteilen.
Umgebung:
Windows Server 2016 mit Exchange Server 2016 CU23 Apr24HU (15.1.2507.39)
Auf dem Server waren ebenfalls die 01-2025 Updates installiert
KB5050109
KB5049614
KB5049993
Vorgehen:
Snapshot erstellt
Update Datei Exchange2016-KB5049233-x64-de.exe zu Nov24SUv2 (15.1.2507.44) ausgeführt.
Setup stieg mit folgendem Fehler aus:
Siehe auch Anhang "Versuch01_185040_01.png"
Product: Microsoft Exchange Server - Update 'Security Update for Exchange Server 2016 Cumulative Update 23 (KB5049233) 15.1.2507.44' could not be installed. Error code 1603. Additional information is available in the log file D:\Program Files\Microsoft\Exchange Server\V15\Logging\Update\msi\ExchangeUpdate_2025-01-21-185040.log.
Zu diesem Zeitpunkt liefen noch alle Exchange Diente und der Server war noch funktionsfähig.
Nach einem Reboot kamen die Dienste nicht mehr hoch, obwohl diese noch auf Starttyp Automatisch standen.
Die Dienste konnten auch nicht manuell gestartet werden.
Nächter Schritt:
Die Deinstallation der drei o.g. 01-2025 Updates
Reboot nach jeder Deinstallation
-> ohne Erfolg.
Die Dienste konnten immer noch nicht gestartet werden.
Nächster Schritt:
Erneute Ausführung der Update Datei Exchange2016-KB5049233-x64-de.exe zu Nov24SUv2 (15.1.2507.44)
Fehlgeschlagen mit selbem Fehler error 1603 in der Shell.
Erneute Log Analyse:
Dabei sind folgende Zeilen aufgefallen:
MSI (s) (68!94) [22:30:41:911]: PROPERTY CHANGE: Deleting QtExecCmdLine property. Its current value is '"D:\Program Files\Microsoft\Exchange Server\V15\\bin\QuietExe.exe" "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" " -command . 'D:\Program Files\Microsoft\Exchange Server\V15\\bin\servicecontrol.ps1' BeforePatch"'.
CAQuietExec: Error 0x80070001: Command line returned an error.
CAQuietExec: Error 0x80070001: CAQuietExec Failed
CustomAction CA_SAVEDATA_STOP_SERVICES returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Vermutung:
Wohl ein Fehler im Script D:\Program Files\Microsoft\Exchange Server\V15\\bin\servicecontrol.ps1
(Bei einer Default-Installation befindet sich das Script auf C:\)
Es hat sich herausgestellt, dass in dem Script des Öfteren die CMDlets "Stop-SetupService" und "Start-SetupService" verwendet werden sollen.
Diese gibt es aber nicht.
Korrekt heißen diese CMDlets "Stop-Service" und "Start-Service".
Also entweder überall in dem Script ersetzen oder Aliase hinzufügen
Ich habe Aliase nach Zeile 878 hinzugefügt (# add-PSSnapin -Name Microsoft.Exchange.Management.PowerShell.Setup -ea SilentlyContinue):
New-Alias Stop-SetupService Stop-Service
New-Alias Start-SetupService Start-Service
Hier zu sehen Zeile 872 - 881 (angepasst):
# AddSnapins # Adds the required snapins to access start-setupservice and stop-setupservice # Returns: # void function AddSnapins { # add-PSSnapin -Name Microsoft.Exchange.Management.PowerShell.Setup -ea SilentlyContinue New-Alias Stop-SetupService Stop-Service New-Alias Start-SetupService Start-Service }
Test des Scripts manuell als einer administrativen Powershell, bevor das Setup des Updates erneut aufgeführt wird.
Es sollte min. ein Exchange oder IIS Dienst laufen und auf Starttyp "Automatisch" stehen, damit das Script einen Dienst beenden und auf Starttyp "Deaktiviert" setzen kann.
Ansonsten schlägt das Script ebenfalls fehl.
Ich habe den IIS-Verwaltungsdienst (IISADMIN) dafür verwendet.
& "D:\Program Files\Microsoft\Exchange Server\V15\bin\ServiceControl.ps1" BeforePatch
Nachdem das Script erfolgreich manuell ausgeführt wurde, und keine Fehler zurückgegeben hat, den IIS-Verwaltungsdienst wieder auf Starttyp "Automatisch" stellen und starten.
Sodass beim nachfolgenden Ausführen des Update-Setups das Script ebenfalls erfolgreich ausgeführt werden kann.
Bei mir wurde im Script dann noch Zeile 343 bemängelt:
Stop-SetupService -ServiceName $serviceName -ev script:serviceControlError
Worauf ich Zeile 343 bis 348 auskommentiert habe, da es sich hier nur um Logs dreht.
Hier zu sehen Zeile 341 - 348 (angepasst):
Log "Stopping service '$serviceName'." Stop-Service -ServiceName $serviceName #Stop-SetupService -ServiceName $serviceName -ev script:serviceControlError #if( $script:serviceControlError[0] -ne $null ) #{ # Log ($script:serviceControlError[0].ToString()) # return $false #}
Nächster Schritt:
Erneute Ausführung der Update Datei Exchange2016-KB5049233-x64-de.exe zu Nov24SUv2 (15.1.2507.44)
Diesmal lief die Installation sauber durch.
Anschließend ein Reboot.
Nächster Schritt:
Die Exchange und IIS Dienste müssen manuell wieder auf Starttyp "Automatisch" gestellt werden, da das Setup am Ende der Ausführung nur die Dienste wieder auf Starttyp "Automatisch" stellt, die zuvor von dem Setup auch auf "Starttype" deaktiviert gestellt wurden.
Erneuter Reboot des Exchange
-> OK
Meine Vermutung zu dem Ganzen ist, dass mit einem der 01-2025 Updates die CMDlets geändert wurden und deshalb das Exchange Script servicecontrol.ps1 nicht mehr funktioniert.
Ich hoffe damit konnte ich jemandem weiterhelfen.
Viel Erfolg!
LG Daniel
Ich habe es eben auf einem anderen System mit deutschen Server 2019 mit Exchange 2019 noch einmal ausprobiert, mit installierten Januar Updates lief die Exchange SU Installation nicht durch. Nach der Deinstallation der Januar Updates konnte ich das Exchange SU aber ohne weitere Anpassung installieren.
Lässt sich bei euch das Win Update KB5050109 einfach deinstallieren? Leider ist das bei mir unter Server 2016 mit Ex 2016 nicht möglich. Die anderen beiden Updates vom Januar (KB5049614 + KB5049993) konnte ich einfach deinstallieren. Das reicht aber nicht um das Exchange November Update installiert zu bekommen...
Hi, @mst,
ich vermute stark, dass meine Lösung auch funktioniert, wenn die Updates installiert sind.
Kontrolliere doch auch mal im Installations-Log (%ExchangeInstallPath%\Logging\Update\msi), ob du folgende Zeilen findest:
MSI (s) (68!94) [22:30:41:911]: PROPERTY CHANGE: Deleting QtExecCmdLine property. Its current value is '"D:\Program Files\Microsoft\Exchange Server\V15\\bin\QuietExe.exe" "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" " -command . 'D:\Program Files\Microsoft\Exchange Server\V15\\bin\servicecontrol.ps1' BeforePatch"'.
CAQuietExec: Error 0x80070001: Command line returned an error.
CAQuietExec: Error 0x80070001: CAQuietExec Failed
CustomAction CA_SAVEDATA_STOP_SERVICES returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Siehe auch den Anhang "Fehler_Log.png"
LG Daniel