[English]Microsoft hat bei Windows 11 24H2 sowie bei Windows Server 2025 die sogenannten Checkpoint Cumulative Updates eingeführt. Im September 2024 gab es wohl erste Meldungen über Probleme, Nutzer scheiterten mit dem Fehler "Operation is not supported". Nun hat Microsoft einen Supportbeitrag aktualisiert, der die Vorgehensweise beschreibt, um bei Systemen mit diesem Fehler die manuelle Installation von .msu-Updates erfolgreich durchzuführen.
Anzeige
Die Checkpoint Cumulative Updates
Ich hatte es im Juli 2024 im Beitrag Windows 11 23H2 ist nun allgemein verfügbar – neue "Checkpoint"-Updates angekündigt kurz erwähnt. Microsoft hatte die Einführung der sogenannten "Checkpoint Cumulative Updates" für Ende 2024 in Windows 11 24H2 und Windows Server 2025 angekündigt.
Microsoft erhofft sich von der Neuerung kleinere kumulative Updates, weil die neuen Update Pakete inkrementell sind und nur Änderungen enthalten, die seit dem letzten kumulativen Checkpoint-Update hinzugefügt wurden. Das Ganze wird im Support-Beitrag Introducing Windows 11 checkpoint cumulative updates vom 15. Juli 2024 im Windows 11 Health Status-Dashboard erklärt.
"Operation is not supported" Error im Sept. 2024
Im September 2024 scheint es erstmals solche Updates gegeben zu haben und Nutzer wurden bei der Update-Installation über .msu-Dateien mit dem Fehler "Operation is not supported" konfrontiert. Ich hatte das hier im Blog nicht thematisiert, aber neowin.net hat es hier angesprochen.
Von Microsoft gibt es den Supportbeitrag "Operation is not supported" error installing a post-checkpoint update by double-clicking the .msu package vom 9. September 2024, der das Ganze erklärt. Die Randbedingung, bei der der Fehler auftritt:
Anzeige
- Auf dem System wurde das neueste kumulative Checkpoint-Update (z. B. KB5043080 vom September 2024 oder späterer) installiert.
- Außerdem wurde ein Feature on Demand (FoD) oder Language Pack (LP) von einer lokalen Ressource installiert, weil keine Verbindung zu Windows Update (WU) oder Windows Server Update Services (WSUS) bestand.
Versucht ein Nutzer dann ein kumulatives Post-Checkpoint-Update zu installieren, indem das .msu-Update-Paket per Doppelklick gestartet wird, schlägt die Installation möglicherweise fehl. Windows meldet, dass der Vorgang nicht unterstützt wird.
Problem fehlende Internetverbindung
Den Kollegen von neowin.net meinen nun hier, dass Microsoft den Supportbeitrag "Operation is not supported" error installing a post-checkpoint update by double-clicking the .msu package vom 9. September 2024 inzwischen aktualisiert hat (scheint nicht zuzutreffen, aber die grundsätzliche Problematik bleibt und ich greife sie mal kurz auf).
Das obige Installationsproblem tritt auf, weil das FoD oder LP, das von einer lokalen Quelle über das letzte kumulative Checkpoint-Update hinzugefügt wurde, ohne Verbindung zu Windows Update (WU) oder WSUS nicht auf das neueste Update aktualisiert werden kann.
Was bei .msu-Installation zu beachten ist
Um dieses Problem zu beheben, sind alle kumulativen Checkpoint-Updates und das neueste Update herunter zu laden und erneut zu installieren. Microsoft gibt folgende Vorgehensweise zur Installation eines MSU-Pakets mit dem Update an:
- Zuerst sind die kumulative Checkpoint-Updates (.msu-Pakete) herunter zu laden. Dazu ist im im Microsoft Update Catalog nach dem neuesten Update (KB-Nummer) zu suchen (z.B. Update 5043080 für das Update vom September 2024 im Suchfeld eingeben und dann suchen lassen).
- Im Anschluss ist auf die Schaltfläche Download für die gewünschte Gerätearchitektur, z. B. für x64-basierte Systeme oder arm64-basierte Systeme) zu klicken. Das Dialogfeld Download, in dem alle erforderlichen .msu-Pakete aufgelistet sind, wird angezeigt.
- Diese Pakete, die jeweils eine .msu-Datei für das neueste Update und .msu-Dateien für alle kumulativen Checkpoint-Updates, die vor diesem Update veröffentlicht wurden, enthalten, sind nun in einen lokalen Ordner wie "C:\Packages" herunterzuladen.
Dieser lokale Ordner darf keine anderen .msu-Dateien enthalten. Dann ist das DISM-Tool (Deployment Image Servicing and Management) zu verwenden, um ein oder mehrere kumulative Checkpoint-Update-Pakete (MSU) zu installieren. Weitere Informationen finden Sie unter DISM Operating System Package (.cab or .msu) Servicing Command-Line Options.
Um eine einzelne .msu-Datei zu einem Windows-Image hinzuzufügen, verwenden Sie den Befehl Add-WindowsPackage (siehe Add-WindowsPackage).
Ähnliche Artikel:
Windows 11 23H2 ist nun allgemein verfügbar – neue "Checkpoint"-Updates angekündigt
Windows 10 erzeugt Datenmüll (.checkpoint-Dateien) in Windows/System32
Anzeige
das erinnert an die Zeiten von Windows NT wo bei hinzufügen von Neuen Services oder Rollen das komplette Service Pack neu installiert werden musste. Toll hat das Microsoft wieder hinbekommen.
Microsoft – genauer gesagt, Windows Update – scheint immer noch gröbere Probleme bei der Auflösung von Abhängigkeiten zwischen einzelnen Komponenten zu haben, obwohl das eigentlich ein ziemlich gelöstes Problem zu sein scheint, zB unter Linux.
Darum dauerten Updates nach Neuinstallation vom Originaldatenträger unter Vista oft halbe oder ganze Tage, da immer gefühlt *alle* Updates der Reihe nach installiert werden mussten, mit all den Neustarts, die es benötigte. Der Verzicht auf Service Packs (außer einem) verschlimmerte die Situation weiter, von Monat zu Monat.
Der Wechsel zu halbjährlichen "Feature Updates" (eigentlich Neuinstallationen mit Reset aller von Windows Update aufzulösenden Abhängigkeiten) unter W10 war wahrscheinlich dazu gedacht, die Situation zu verbessern, zumal durch die kumulativen monatlichen Updates (ohne Möglichkeit der Auswahl was man wollte) der zu Updatende (Upzudatende?) "Maschinenpark" deutlich homogener war.
Durch den Umstieg auf jährliche Feature Updates hat die Anzahl der aufzulösenden Abhängigkeiten wieder zugenommen, daher die neuerlichen Versuche, die Situation zu verbessern, durch die Checkpoint Updates (die eigentlich so etwas wie "kleine" Service Packs sind, mit weniger Vorteilen.
Es wäre echt an der Zeit, dass MS die Update-Problematik und die Auflösung von Abhängigkeiten besser inden Griff bekommt.
Die Windows-Update-Rotinen sind by Design seit jeher Kernschrott:
Nimm ein Windows7 x64 mit installiertem SP1 – und installier dann das Offline-Updatepack von WinFuture welches selbstständig bei Bedarf neustartet, und so in einem Rutsch alle wichtigen Updates nachinstalliert:
3-4h trotz 16GB Ram, trotz SSD, trotz i7 CPU.
Nimm gleiche Hardware mit Redhat-Enterprise-Linux v6.0 (Release ca. 2010) inkl. Gnome-Desktop-Umgebung, und installiere alle Updates bis v6.10 (Patchzeitraum etwa 10Jahre):
5-10min inkl. Downloads.
Heute mit Windows10/11 heulen die Lüfter an den 3Jahre alten Laptops auf, und die Geräte sind 15-20min voll ausgelastet – Monat für Monat für Monat …
Unfassbar.
Win 10/11 geschätzt 75% nur für Tracking/Telemetrie/Framework für Frameworks/ungenutzte Featureitis… ein total aufgeblasener und überladener und verhunzter NT Kernel.
Naja, MS arbeitet seit Vista an diesem "Problem". Der zuständige Component Store wurde seither laufend verbessert, Funktionalitäten des OS nach und nach in eigene, voneinander unabhängige Bausteine gepackt. Bis 8/2012 war nur schon ein cleanen des Stores quasi nicht möglich, sprich sämtliche Versionen von Systemdateien blieben mit jedem Update auf dem System. Deshalb hat es die Platten in riesigem Ausmass aufgebläht. Heute geschieht das (leider) noch temporär. Sprich jedes Update wird entpackt und überprüft ob die Systemdateien neuer oder älter sind. Dadurch sind rund ca. 7 GB an freiem Platz notwendig bei einem Server 2022 LTSC Build und darum dauert das auch so lange. Aber das Syste an sich bleibt einiergmassen schlank. Ist eine gewisse Sicherheit die dadurch eingebaut ist.
Auch die API-Funktionalität bleibt quasi 30 Jahre erhalten. Sprich alte Software kriegt man eigentlich immer irgendwie auf aktuellen OS zum laufen.
Meiner Meinung nach ein Meisterstück was MS hier technisch abliefert. Nur für meinen Geschmack ist der Prozess zu langsam. Mit Hotpatch und Checkpoints scheint aber wieder ein grosser Schritt in Angriff genommen worden zu sein. Am Ende dieses Umbauprozesses wird nichtmehr ein ganzes OS gepatcht sondern nur noch Komponenten (Streng genommen tut es das schon heute, nur "muss" man teilweise viele Kompnententen zusammen updaten). ;)
Ich habe die Updates wie angegeben per DISM installiert. Windows sagt, es hat Stand Dez. 2024. Trotzdem will der WSUS oder WindowsUpdate das Dezember Update erneut installieren. Kann das jemand bestätigen? Funktioniert ja echt prima die Erkennung.