[English]Kleine Rundfrage an die Leserschaft, die Inplace-Upgrades von Windows 10 (22H2) auf die aktuelle Windows 11-Version 22H2 durchführen. Ist euch aufgefallen, dass dieser Vorgang seit dem 8. August 2023 irgendwie Probleme macht? Es war ja August 2023-Patchday, wo weniges an Windows gepatcht wurde. Gut möglich, dass da was schief gegangen ist. Hier die Beobachtung, die mir ein Leser per Mail mitgeteilt hat und fragt, ob noch jemand so etwas beobachtet. Ergänzung: Das Problem wurde von mehreren Administratoren bestätigt, und der Leser hat inzwischen in einem Nachtragskommentar seine funktionierende Lösung hier gepostet.
Anzeige
Lesermeldung über Probleme
Blog-Leser Johannes K. muss immer mal wieder Maschinen von Windows 10 22H2 auf das aktuelle Windows 11 22H2 aktualisieren. Dazu verwendete er bisher ein Inplace-Upgrade, steht jetzt aber vor Problemen. Hierzu schrieb er mir:
Hallo Günter!
Wir verwenden für das Upgrade von Windows 10 22H2 auf Windows 11 22H2 das inplace Upgrade mit folg. Befehl:
setup.exe /auto upgrade /eula accept /noreboot /migratedrivers all /ReflectDrivers "%ProgramFiles%\McAfee\Endpoint Encryption\OSUpgrade"Diese Methode hat bis inkl. Montag 7.8.2023 einwandfrei funktioniert.
Heute Mi 9.8. hängt das Upgrade bei "Updates werden abgerufen 46%" sehr sehr lange, dann bei "Installationsbereitschaft wird überprüft" eine kleine Ewigkeit, bis nach einem Reboot noch immer Windows 10 drauf ist.
Gestern Di 8.8. war der berüchtigte 2. Dienstag im Monat, Update Day bei Microsoft. Hat MS etwas verbockt?
Hat jemand von euch die selbe Beobachtung gemacht?
Lg
Johannes K.
Mir ist da diesbezüglich bisher nichts untergekommen. Hat jemand da ähnliche Erfahrungen gemacht? Ergänzung: Auf Facebook kam in einer geschlossenen Administratorengruppe ebenfalls die Rückmeldung, dass das Verhalten jemand aufgefallen ist.
Was man probieren könnte
Ad-hoc würde ich auf ein Treiberproblem beim Upgrade tippen. Beim Upgrade sollten eigentlich Protokolldateien mit den durchgeführten Schritten angelegt werden. Die Log-Dateien finden sich in den versteckten Ordnern:
$Windows.~BT\sources\Panther $Windows.~BT\sources\Rollback
und könnten eventuell Aufschluss geben, was schief gelaufen ist. Im Artikel Windows 10 Upgrade-Troubleshooting FAQ – Teil 1 finden sich dazu einige Hinweise. Ich hatte zudem im Blog-Beitrag Windows 11 22H2: Probleme und Upgrade-Stopper einige Hinweise gegeben, Dateien mit _HumanReadable.XML im Namen im Panther-Ordner suchen und im Editor öffnen. Anschließend nach <Inventory>-XML-Knoten schauen. In den <Property>-Knoten ist angegeben, was den Show-Stopper verursacht (siehe auch hier).
Anzeige
Ergänzung 2: Das Problem wurde von mehreren Administratoren bestätigt, und der Leser hat inzwischen in einem Nachtragskommentar seine funktionierende Lösung hier gepostet.
Inplace Upgrade: Was ist das?
Ein Inplace-Upgrade ist ein Ansatz, bei dem aus einem laufenden Windows ein Windows erneut vom Installationsmedium per setup.exe installiert wird. Dann lässt man eine Neuinstallation von Windows durchführen, wobei die Option zum Behalten von Dateien und ggf. Anwendungen verwendet werden kann. Letzterer Ansatz erspart meist das mühsame Einrichten des Betriebssystems nach der Neuinstallation, verhindert einen Datenverlust und kann mitunter hartnäckige Fehler, die aus einem beschädigten Windows resultieren, beseitigen. Den Ansatz kann man zur Reparatur eines Windows 10 oder 11 verwenden, oder eben auch für das Upgrade von Windows 10 auf WIndows 11.
Ähnliche Artikel:
Windows 11 22H2: Probleme und Upgrade-Stopper
Windows 10 Upgrade-Troubleshooting FAQ – Teil 1
Windows 10 Upgrade-Troubleshooting FAQ – Teil 2
Anzeige
Nein, aber adhock würde ich sagen, mal händisch testen und den mcaffee rausnehmen.
im August Patchday kamen ja einige Treiber auf die Sperrliste, die aktualisierte Liste wurde ja so viel ich weiß nie wirklich auf die Clients ausgerollt, vielleicht eine Nachwirkung dessen? Tritt das Problem reproduzierbar bei unterschiedlichen Gerätemodellen auf oder nur bei Spezifischen?
Ich verwende bisher das Inplace-Upgrade zu Windows 11 (und "zu" Windows 10, wenn die Installation unrettbar beschädigt ist, z.B. im SxS-Zweig) immer ohne Einbeziehung der aktuellen Updates ausgehend von einer .wim von Anfang des Jahres. Spart nicht nur Zeit und Datenvolumen (die Installation holt danach das aktuelle Update direkt vom WSUS). sondern scheint davon auch nicht betroffen zu sein.
Gestern problemlos durchgeführt
die Probleme kann ich bestätigen. Musste dann über die Windows Updates gehen..
So was in der Form, hatte ich auch schon ab und an bei Win10 auf Win11 Umstellung per Inplace Upgrade gehabt. Auch schon bei Win7 / Win8.x auf Win10 gab es bei machen Systemen Probleme mit der Migration.
Wenn das nicht per Update schon systemintern angeboten wurde, dann hatte ich immer das MCT Tool genutzt, bzw. gleich die iso.
Sollte der Migrationsprozess nicht geglückt sein, gibts da eine log Datei. Ich weiß jetzt nur nicht mehr ganz genau, wo die abgelegt wurde.
Meine Erfahrung dazu ist, das man bei der Abfrage, ob während der Umstellung, Updates und Patches gleich mit installiert werden soll, das erst mal nicht machen sollte. Soweit wie ich das per Recherche herausfinden konnte, würde das mit daran liegen, das in der iso veraltete Patches sind, welche dann mit anderen Patches, welche per Update während der Migration hereinkommen, kollidieren.
Ob dem so ist, keine Ahnung, dazu fehlen mir tiefere Kenntnisse der Materie. Evtl. weiß hier jemand mehr darüber. Würde mich freuen.
Moin,
Ich hatte in der Vergangenheit auch öfter solche Probleme. (Auch 7 zu 8 / 8.1)
Ohne Update Installation klappte es..
Auch damals war der Punkt das die Versionen mit Updates nicht ganz übereinstimmend sind.
Auch wenn es ein frisches ISO war.
Wie auch immer, Ohne Update-Inst klappte das Upgrade immer wenn Ich es mal gemacht habe.
Und ein sehr nahes Problem hat man auch, wenn man .NET 3.5 installieren will.
Ich hatte vieles ausprobiert da einige Software leider immer noch das uralte .NET 3.5 haben wollen oder manches nicht sauber läuft wenn es nicht vorhanden ist..
Theoretisch ist dies einfach über Feature Upgrade zu machen.
Hatte Ich das letzte mal vor Corona getestet. Klappte nicht / nicht sauber / dauerte ewig.
Deswegen habe Ich mir direkt nach der Win Inst angewöhnt eine CMD zu starten wenn die ISO noch gemountet ist.
In einer elevierten CMD einfach:
Dism /online /enable-feature /featurename:NetFX3 /All /Source:%setupdrv%:sourcessxs /LimitAccess
%setupdrv% Durch den Buchstaben der Win CD ersetzen.
Oder folgende Zeielen in eine .cmd Datei hineinkopieren:
@echo off
setlocal enableextensions ENABLEDELAYEDEXPANSION
@prompt -$G
CLS
net session >nul 2>&1 || (powershell -EP Bypass -NoP -C echo & echo '"—- Bitte die CMD eleviert starten —-'" -verb runas & pause & Exit /b)
for %%I in (D E F G H I J K L M N O P Q R S T U V W X Y Z) do if exist "%%I:\sourcesinstall.*" set setupdrv=%%I
Dism /online /enable-feature /featurename:NetFX3 /All /Source:%setupdrv%:sourcessxs /LimitAccess
Exit
Ich habe es heute auch versucht und es funktioniert so wie oben beschrieben nicht.
Laden von Updates bis 46% und dann beim Überprüfen der Installierbarkeit wird mit Fehler 0xc000000f abgebrochen.
geht immer noch nicht. Die Aktualisierung stürzt ab mit:
Name der fehlerhaften Anwendung: SetupHost.exe, Version: 10.0.22621.1, Zeitstempel: 0xdac8cfb7
Name des fehlerhaften Moduls: acmigration.dll, Version: 10.0.22621.2070, Zeitstempel: 0xee898314
Ausnahmecode: 0xc0000005
Fehleroffset: 0x0000000000058d7a
ID des fehlerhaften Prozesses: 0x2a84
Startzeit der fehlerhaften Anwendung: 0x01d9ce8acf709f8d
Pfad der fehlerhaften Anwendung: C:\$WINDOWS.~BT\Sources\SetupHost.exe
Pfad des fehlerhaften Moduls: C:\$WINDOWS.~BT\Sources\acmigration.dll
Berichtskennung: 6af3d9d9-a06c-46bb-baa0-bb7e589f44a8
Hallo zusammen,
habe ebenfalls dieses Problem gehabt…
Workaround, der funktioniert hat:
PC / Notebook vom Internet trennen, dann findet keine "Online-Prüfung" statt und das Setup / Update läuft durch…
Viele Grüße
Liebe Community!
Die Lösung für mich ist, dass ich während des Inplace Upgrades von Windows 10 auf Windows 11 die Installation von Updates nicht mache. Das geschieht mit dem Parameter /dynamicupdate disable
Damit schaut der Aufruf so aus: setup.exe /auto upgrade /eula accept /dynamicupdate disable /noreboot /migratedrivers all /ReflectDrivers "%ProgramFiles%\McAfee\Endpoint Encryption\OSUpgrade"
@Fritz und Sven Fischer: Danke, ihr habt mich auf den richtigen Weg geführt, die Updates während des Inplace Upgrades wegzulassen
@T Sommer: Der McAfee ist nicht das Problem
@Michael: Das Problem tritt auf allen Hardware Gerätetypen auf, auch auf VMware
@TomTom: Die .net 3.5 Installation mit Dism… hat bei mir nur bei älteren Windows 10 Versionen so funktioniert, ab Win10-20H2 funktioniert die .net 3.5 Installation nur, wenn ich es als Feature im MDT einbinde
@Jörg H.: Das Trennen vom Internet hat bei mir nur bei Win11-21H2 funktioniert, ab Win11-22H2 kommt sinngemäß die Meldung "Online-Prüfung kann nicht durchgeführt werden" und bleibt stehen.
Meine Conclusio ist, dass MS am Patchday 8.8.2023 irgendetwas mit den Securityupdates verbockt hat.
Danke an alle!
Johannes K
Wir haben in unserer Firma genau das gleiche Problem.
Was sich Microsoft hier mal wieder geleistet hat, spottet jeder Beschreibung.
SetupHost.exe stürzt mit Exception code: 0xc00000f0 ab, egal ob wir das Windows 11 22H2 In-Place Upgrade über den "Windows 11 Installationsassistenten" oder über die setup.exe der Windows 11 ISO starten.
Wir haben auch ein Ticket bei MS eröffnet, aber der First-Level-Support ist damit im Moment natürlich überfordert und es ist schwierig, die richtigen Leute bei MS zu erreichen, die das Problem vielleicht schneller lösen können.
In der Zwischenzeit habe ich jedoch weiter getestet und konnte das Problem weiter eingrenzen.
Wenn ich die setup.exe der Win11-ISO über die Befehlszeile ausführe:
setup.exe /eula accept /auto upgrade /migratedrivers all /Compat IgnoreWarning /showoobe none
stürzt die SetupHost.exe zuverlässig ab und der gesamte In-Place-Upgrade-Prozess schlägt fehl.
Wenn ich jedoch stattdessen die folgende Befehlszeile verwende:
start /wait setup.exe /eula accept /auto upgrade /migratedrivers all /Compat IgnoreWarning /dynamicupdate disable /showoobe none
das In-Place-Upgrade läuft erfolgreich!!! Der entscheidende Unterschied scheint also der Schalter zu sein:
/dynamicupdate enable (=default => AppCrash aus SetupHost.exe)
bzw.
/dynamicupdate disable (=> kein AppCrash von SetupHost.exe)
Leider akzeptiert die aktuelle Windows11InstallationAssistant.exe (die nur ein Wrapper für das Windows 11 Setup via setup.exe ist) diesen Parameter nicht und kann ihn daher auch nicht an setup.exe weitergeben, so dass dieser Parameter standardmäßig immer auf
/dynamicupdate enable
gesetzt ist, was bedeutet, dass das Windows 11 In-Place-Upgrade über den "Windows 11 Installationsassistenten" immer fehlschlägt.
Der Schalter /dynamicupdate akzeptiert laut MS-Dokumentation:
https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-setup-command-line-options?view=windows-11
nicht nur die Werte "enable" und "disable", sondern auch:
NoDrivers
NoDriversNoLCU
NoLCU
Nach weiteren Tests weiss ich aber, dass diese Optionen auch nicht funktionieren und nur das vollständige Deaktivieren des DynamicUpdate den AppCrash zuverlässig vermeidet.
Der Nachteil des Schalters
/dynamicupdate disable
ist, dass die letzte CU (LCU) nicht automatisch heruntergeladen und installiert wird, d.h. nach dem OS-Upgrade hat man zunächst ein Windows 11 22H2 OS auf dem Patch-Level des ISOs.
Wenn der Windows Update Client nach dem OS-Upgrade startet, findet und installiert er in der Regel sofort die letzte LCU und nervt den Benutzer wieder mit einem erforderlichen Neustart, was natürlich nicht die beste Benutzererfahrung direkt nach dem zeitaufwändigen In-Place OS-Upgrade ist.
Grundsätzlich würden wir den Windows 11 Installationsassistenten für das In-Place-Upgrade von Win10 22H2 auf Win11 22H2 bevorzugen, da er eine schönere GUI hat und dem Endbenutzer wertvolle Informationen über den ESD-Download-Status und den Fortschritt des OS-Upgrades liefert und es dem Benutzer auch erlaubt, während der Online-Phase des Upgrades weiterzuarbeiten. Die Oberfläche der Windows 11 ISO Setup.exe hingegen ist ein hässlicher blauer Vollbildschirm, der es dem Benutzer im nicht leisen Modus schwer macht, bis zum für die Offline-Phase erforderlichen Neustart weiterzuarbeiten.
Unsere derzeitige Hypothese ist, dass MS in den letzten 8 Monaten einen Fehler in einem ihrer Betriebssystem-Updates für Windows 10/Windows 11 22H2 eingeführt haben muss, der den Absturz von SetupHost.exe auslöst, da ich mich daran erinnere, dass das Windows 11 In-Place-Upgrade über den "Installationsassistenten" auch in der Vergangenheit zuverlässig funktioniert hat (irgendwann Anfang 2023).
Ich werde MS derzeit über meine aktuellen Testergebnisse informieren. Sobald es diesbezüglich neue Erkenntnisse gibt, werde ich sie hier posten.
Update:
Nach weiteren Tests, kann ich sagen, dass auch diese Komamndozeile auf meinem Testrechner funktioniert:
setup.exe /auto upgrade /eula accept /dynamicupdate disable /quiet (=> kein SetupHost.exe AppCrash)
aber wenn ich /skipfinalize hinzufüge, um das OS Upgrade lautlos für den User vorzubereiten und dann eigentlich mit /finalize abzuschliessen, crashed this SetupHost.exe auch!!!!
start /wait setup.exe /auto upgrade /eula accept /dynamicupdate disable /skipfinalize /quiet (=> SetupHost.exe AppCrash!!!!!, trotz Schalter /dynamicupdate disable)
Das Ganze ist wirklich ein Alptraum!!!!
Ich konnte das Problem noch weiter eingrenzen. Das Debugging des Crash Dumps der SetupHost.exe weist auf ein Problem in der Datei acmigration.dll in
C:\$WINDOWS.~BT\Sources
hin:
PROCESS_NAME: SetupHost.exe
ERROR_CODE: (NTSTATUS) 0xc00000f0 – An invalid parameter was passed to a service or function as the second argument.
STACK_COMMAND: dt ntdll!LdrpLastDllInitializer BaseDllName ; dt ntdll!LdrpFailureData ; ~21s; .ecxr ; kb
FAILURE_BUCKET_ID: APPLICATION_FAULT_c00000f0_acmigration.dll!SdbpGetStringTableItemFromStringRef
Diese wird in der Tat zur Laufzeit des Inplace Upgrades aktualisiert, wenn man "DynamicUpdate" nicht ausschaltet.
Die Versionsnummer nach der Aktualisierung der DLL lautet 22621.2070 und ist im DynamicUpdate kb5028554 enthalten:
https://support.microsoft.com/de-de/topic/kb5028554-dynamisches-update-f%C3%BCr-windows-11-version-22h2-26-juli-2023-317f3613-626d-47ed-a961-eb3a7dc4da64
Ich habe diese Info an Microsoft weitergegeben, aber natürlich bis jetzt weder eine Bestätigung noch einen Fix bzw. Lösung des Problems erhalten.
Ich habe mir jetzt dadurch geholfen, dass ich die Dateiversion der DLL
C:\$WINDOWS.~BT\Sources\acmigration.dll
zur Laufzeit des Windows 11 Setups permanent über ein Powershell script einmal pro Skunde kontrolliere und sobald sich diese von 22621.1 auf 22621.2070 ändert, die erneuerte Datei wieder durch die alte Version der DLL aus dem ISO mit der Versionsnummer 22621.1 ersetze. Dann stürzt die SetupHost.exe nicht mehr ab und das In-Place Upgrade läuft durch.
c:\test>err 0xc00000f0
# for hex 0xc00000f0 / decimal -1073741584
STATUS_INVALID_PARAMETER_2 ntstatus.h
# An invalid parameter was passed to a service or function as
# the second argument.
Dein 2. "ausgelesener" Paramter ist daher DynamicUpdate. Aufgrund dessen bin ich weggekommen von dem Anstückeln der Parameter zur setup.exe, was den Pfad echt lang werden lassen kann. (Logpfad, Treiberpfad,
suche im Log nach CMDLine, da steht der Aufruf drin
Bei uns läuft mit dem Patchstand August kein Inplace mehr durch. Gerade mit setup.exe /auto upgrade /eula accept /dynamicupdate disable /quiet versucht.
Verwende 22H2.8 für dein Unternehmen und anschließend via Patchamanagement das CU hinterher (mehr unter meinem Kommentar "Cleo")
https://support.microsoft.com/en-us/topic/kb5030327-setup-dynamic-update-for-windows-11-version-22h2-september-12-2023-e397f4dc-a341-4991-8df6-0a6681d1c19e *scheint* das Probem zu beheben!
Leider nein, 22H2.10 / 11 / 12 / 13 beinhaltet immer noch das Problem (enthält auch Moments4)
Ich habe den Windows 11 Installation Assistant aufgrund dieser Information gerade noch einmal ausprobiert, und bei mir stürzt die SetupHost.exe leider immer noch ab.
Wenn ich mir danach die Fileversion von
C:\\$WINDOWS.~BT\\Sources\\acmigration.dll
ansehe, hat diese zwar nun eine höhere Versionsnummer, nämlich 22621.2275, bringt aber wie gesagt die SetupHost.exe, die durch das Dynamic Update KB5030327 auch auf Version 22621.2275 aktualisiert wurde, immer noch zum Absturz! MS hat also das Problem bei mir auch mit KB5030327 nicht behoben!!!
Allerdings hilft mir auch weiterhin mein Workaround per Powershell Script, bei dem ich die Dateiversion der DLL
C:\\$WINDOWS.~BT\\Sources\\acmigration.dll
zur Laufzeit des Windows 11 Setups permanent über ein Powershell script einmal pro Skunde kontrolliere und sobald sich diese von 22621.1 auf 22621.2070 bzw. nun 22621.2275 ändert, die erneuerte Datei wieder durch die alte Version der DLL aus dem ISO mit der Versionsnummer 22621.1 ersetze. Dann stürzt die SetupHost.exe nicht mehr ab und das In-Place Upgrade läuft durch.
Von 9000 Clients (EN/DE) haben wir das gleiche Problem zum 8.8.2023 feststellen müssen. Hier verantwortlich wird der Parameter DynamicUpdate sein.
"enable" läuft zu 50% in Fehler.
"disable" funktioniert, da kein Download der CUs und Treiber stattfinden.
"NoDriversNoLCU" funktioniert, minimale Anpassung von RollupFix
Wenn in der GPO ein "Treiber online update" nicht erlaubt ist, kann also folglich nur noch DynamicUpdate=NoDrivers verwendet werden.
Verwendet am besten "NoDriversNoLCU", damit werden minimale Daten übermittelt, was genau wird im Log nicht angezeigt (Auch der 3rd. Level von MS konnte uns hier keine Antwort geben). Wahrscheinlich ein SSU oder Rollupfix welche mit "Resolved" hängen geblieben sind.
NoLCU solltet ihr verwenden, wenn das Windows 11 nicht einfach 23H2 werden soll!
Ein angegebener WSUS ist ebenfalls ein Problem in der GPO, wenn CU Updates integriert werden sollen.
Die angeblich kommende GPO "optionale Updates" ist im ADMX Template bis heute nicht verfügbar. Auch hier kann nichts festgestellt werden was da passiert.
Weiter konnte ich beobachten, dass es hauptsächlich nicht EN Systeme betrifft. Also deutsche ISO.
Was geht: Windows 11 22H2.8, 22H2.9; alles danach 22H2.13 wurde getestet hat keine Funktion mehr.
Mein Tipp dazu: Migration mit 22H2.8 mit Parameter DynamicUpdate=disable /oder =NoDriversNoLCU anschließend ein CU update
Setupconfig.ini für einfache Verteilung:
[SetupConfig]
DynamicUpdate=NoDriversNoLCU
Compat=IgnoreWarning
auto=upgrade
ImageIndex=3
Telemetry=disable
eula=accept
showoobe=full
Priority=High
noreboot
Laut Microsoft wurde das Problem mit dem neuen dynamischen Update KB5031656 für Windows 11, Version 22H2, das am 26. Oktober 2023 veröffentlicht wurde, behoben:
https://support.microsoft.com/en-us/topic/kb5031656-setup-dynamic-update-for-windows-11-version-22h2-october-26-2023-7703ad02-0a03-4dae-96f8-a687b056da05
Derzeit kann ich nicht bestätigen, dass es bereits für den Windows 11 Installationsassistenten / Windows 11 22H2 Setup veröffentlicht wurde, da ich gerade ein In-Place-Upgrade auf Windows 11 22H2 über den Assistenten ausprobiert habe und immer noch die vorherige Version von acmigration.dll heruntergeladen wurde, nämlich 10.0.22621.2275 und nicht Version 10.0.22621.2499, wie im neuen KB angegeben.
Ich gehe aber davon aus, dass MS dies in den nächsten Tagen ändern wird.
Heute habe ich das Upgrade mit Windows 11 23H2 probiert und ich bekomme exakt dieses Problem. Entweder wieder eingebaut oder nicht behoben.
Gleiches hier auch auf Notebooks, die bisher noch nicht auf Win11 22H2 installiert wurden und nach wie vor den aktuellen Win10 22H2 Stand haben.
Werde das nächste Woche mal mit
setup.exe /auto upgrade /eula accept /dynamicupdate disable /quiet
ausprobieren, ob sich Win11 23H2 damit ohne SetupHost Crash installieren lässt.
Habe ich gerade auch. Updates suchen bleibt ewig bei 46% hängen, danach "Installationsbereitschaft wird geprüft". Beim ersten Mal wurde tatsächlich bis 90% installiert, dann Abbruch mit der Meldung: " Die Installation war nicht erfolgreich. In der Phase FIRST_BOOT ist während des Vorgangs SYSPREP ein Fehler aufgetreten."
exakt die Problematik
Win 11 pro
Taskleiste: Suchen ohne Funktion
Startmenue bringt schwerwiegenden Fehler
Store updates unmöglich
MS updates führen zu Zwangsneustart da ist was schief gelaufen
In Summe: Mist Mist Mist und Microsoft schweigt sich aus.
Ursache def. ein MS update das fehl schlug.
Alles Systemrep. Versuche bislang ohne Fehlermeldung alles super und es läuft nicht.
Bordersteller sagt no problemo, intel: no problemo
Mal wieder ein Update von meiner Seite – mitterweile verwenden wir den "Windows 11 Installation Assistant" für Windows 11 23H2 und der hat mit dem Trick, die acmigration.dll während der Laufzeit wieder auf die Ursprungsversion 10.0.22621.1 zurückzusetzen, sobald sie vom Assistant aktualisisert wurde, auch einigermaßen stabil funtioniert. Nun hat MS in den letzten Tagen ein neues Dynamic Update KB5033243:
https://support.microsoft.com/en-us/topic/kb5033243-setup-dynamic-update-for-windows-11-version-22h2-and-23h2-november-14-2023-9a11bc10-d87c-453e-8791-a3c348b99823
veröffentlicht, welches viele der Setup-Dateien im Ordner
C:\$WINDOWS.~BT\Sources
auf Version 10.0.22621.2712
aktualisiert. Damit geht bei uns nun gar nichts mehr!!!
Entweder die SetupHost.exe stürzt ab (wenn wir acmigration.dll nicht mehr zurücksetzen) oder aber das Setup bleibt einfach stehen (setup.exe, SetupHost.exe und setupprep.exe für Stunden mit 0% CPU Auslastung) oder beendet das "Windows 11 Installation Assistant" Fenster und startet setup.exe im Non-silent mode (blauer Setup Fullscreen) nochmals neu, was ja bei Verwendung des "Windows 11 Installation Assistant" niemals passieren sollte und für den Enduser eine absolute schlechte Erfahrung darstellt, da es das parallele Arbeiten erschwert und die ohnehin schon sehr lange Upgradedauer verdoppelt, wenn es denn durchläuft.
Insgesamt ist der "Windows 11 Installation Assistant" mit dem Dynamic Update KB5033243 für uns nun komplett unbrauchbar geworden.
Immer wenn man denkt, es geht nicht mehr schlechter, setzt MS noch einen drauf.
Wir haben übrigens zu dem Thema einen Supportcall mit MS offen, aber seit 2 Monaten kommt von denen nur heisse Luft. Deren Versprechen war,
das KB5033243 das Problem beheben würde. Tatsächlich hat es dieses Update aber noch schlimmer gemacht!!!!
servus Sebastian, gleiches bei uns, 2 MS Support Tickets aufgemacht. Nur heisst Luft. Meist konnte ich den Abbruch von setuphost damit einholen, dass ich ein Windows update Repair Skript nutze (Bereinigung) und danach die Problembehebung von Windows laufen lasse. Pending.xml wird dabei auch behandelt. Neustart machen und migrieren mit nodrversnolcu. Das ganze muss ich aber mit 22h2.8 machen. Neuere Versionen funktionieren bei mir nur zu 40%
Was vorweg auch noch unterstützte:
Datentragerbereinigung und darin alle Updates löschen
C:\$WINDOWS.~BT löschen
Windows\temp löschen und neustart und asap migrieren, nicht warten
Moin zusammen,
man kann dem hier Gesagtem nur zustimmen!
Während ein Herr Gates über seine KI philosophiert möge er mal in Redmond anfragen ob da noch alles im Lot ist – so wie es aussieht NICHT!
Haben bei uns die gleichen Lösungsansätze wie o. g. durchgeführt welche mit dem aktuellem ISO aber fehlschlugen. Ich habe nun selber zwei Lenovo-Systeme erfolgreich mit einem "älteren" WIN-11 ISO und "setup.exe /auto upgrade /eula accept /dynamicupdate disable" aktualisieren können. 23H2 folgt dann via Update-Suche ohne Probleme …
Alles ohne Worte!
Irgendwann kommt nichts mehr von denen und die Welt hat eine Sorge weniger.
Gruß an all die welche helfende Hände haben !
KB5033205 ist nun für den Installationsprozess aktiviert, was bedeutet, dass es während des normalen In-Place-Upgrade-Prozesses über die setup.exe der Windows 11 23H2-Iso heruntergeladen wird, sofern man nicht die Kommandozeilenoption
/dynamicupdate disable
verwendet oder über den "Windows 11-Installationsassistenten", bei dem die Dynamic Update Option überhaupt nicht deaktiviert werden kann.
Damit hat Microsoft die In-Place Upgrade Probleme von Windows 11 nach über 4 Monaten!!!! des Nichtfunktionierens nun scheinbar endlich gelöst.