Spring-Update 1709 -> 1803 läuft auf 3 Rechnern nicht
- Ersteller AlexG1990
- Erstellt am
SO ERSTE ERGEBNISSE MEINES TESTS:
Ich habe wie geplant zunächst VirtualBox geladen (Neueste Version + Extension Pack), und dort Windows 10 Version 1709 64-Bit installiert - VM mit:
- virtueller 200GB-Festplatte
- virtuellen 4GB RAM
- UEFI-Mode-Emulation (kann VBox ja auch schon länger)
...auf meinem Lenovo Yoga 2-13 (unter Windows 8.1 64-Bit) mit i5/8GB RAM. Der hat da natürlich etwas "geschwitzt", aber das packt er...
1. Windows 10-ISO 1709 "eingelegt"
2. Direkt per Windows-Setup 2 Partitionen (jeweils 100GB...plus natürlich die autimatisch generierten kleinen EFI/Boot-Partitionen) auf der virtuellen 200GB-"Platte" erstellt
3. Dann Windows auf "C" installiert - sonst nichts besonderes gemacht. (Die D-Partition blieb erstmal unberührt)
4. Im Setup erstmal einen ersten User "User" erstellt.
5. Nach dem Hochfahren noch die VBox-Guest-Additions installiert (schadet ja nix), Windows 10 aktiviert, und alle Windows-Updates installieren lassen.
...sonst erstmal nix.
Diesen Status (virtuelle VHD-Datei) habe ich dann erstmal gesichert.
Beim nächsten Hochfahren wurde mir dann auch tatsächlich direkt das "Funktionsupdate für Windows 10 - 1803" ganz normal über Windows-Update angeboten!
Die 4 GB habe ich dann natürlich nicht nochmal heruntergeladen, sondern das vorher schon geladene ISO von Version 1803 "eingelegt", und im laufenden System das Update über die Setup.exe laufen lassen.
Ergebnis: Klappt einwandfrei.
Dann habe ich als 2. Testlauf erstmal wieder die Sicherung des installierten 1709 zurückgesichert, und dann als erstes die Sache mit den User-Konten auf "D" versucht - also in der Registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\ProfilesDirectory) auf "D:" gesetzt.
Und einen neuen User "Test" angelegt, der dann auch auf D angelegt wurde. Neugestartet, angemeldet, und dann unter dem neuen User "Test" auf D den alten User "User" am Ursprungsort gelöscht.
Soweit so klar.
Dann direkt den nächsten Update-Versuch auf 1803 per ISO...und HIER CRASHT ES!
Ich habe nicht mitbekommen, dass ein "Bluescreen" aufgetaucht wäre, aber es kam wie mir bereits bekannt nach dem Neustart die Meldung "Vorherige Version wird wiederhergestellt..."
Und dann wurde mir, nachdem das alte System wieder hochgefahren war diese Meldung angezeigt:
Unter diesem Code finde ich einen ´Thread in der Microsoft-Community, dass dieser Fehler klar am Userkonten-Pfad liegt!
Als 3. Test habe ich dann, nachdem das einzige Userkonto nun auf D: liegt, nun einfach den Pfad in der Registry von "D:" wieder auf "%SystemDrive%\Users" zurück-geändert!
Einmal erstellte User-Konten bleiben dann ja an dem Ort, an dem sie angelegt wurden - nur ein neues Konto würde dann wieder auf C:\Users angelegt...
Dann wieder das Update laufen lassen - und DANN FUNZT ES EBENFALLS! Benutzerkonto nach dem Update nach wie vor auf D.
Als 4. Test, wieder auf 1709 zurückgesetzt, und alle anderen "Tweaks" durchgeführt, die ich üblicherweise mache und mir eingefallen sind:
- (wie gehabt) Userkonto auf D: - und den Pfad danach wieder zurückgestellt
- Temp-Dateien TMP/TEMP (Global & User) auf "C:\Temp" geändert (Umgebungsvariablen)
- ClassicShell installiert
- Automatisch anmelden, Lockscreen abschalten
- Cortana deaktiviert! (HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Windows Search\AllowCortana = "0")
Und JETZT NOCHMAL geupdatet...KLAPPT!
Das heißt als Fazit:
"Windows 10" hat (genausowenig wie Win7/8) ein Problem mit dem geänderten User-Pfad!
Lediglich die Update-Überinstallation "beißt" sich daran...
Keine Ahnung, ob das in diesem Fall auch schon aufgetreten ist, wenn man z.B. Win7->Win8, Win7->Win10 oder Win8->Win10 geupdatet hatte. Das werde ich aber jetzt nicht auch noch testen, weil ich sowas nie gemacht habe oder machen werde (immer Clean-Install).
Ich werde also künftig die zu erstellenden User-Konten weiterhin auf "D:" legen, indem ich nach der Installation den Registry-Pfad ändere, dann alle Konten auf D anlege (oft ist's nur eins), und dann den Pfad nachher wieder zurücksetze!
Habe am Freitag die Gelegenheit, bei einem der 3 Problem-PCs zu versuchen, ob das Updaten dort dann klappt, wenn ich den Pfad zurück ändere. (Oder ob noch mehr im Argen liegt.)
Falls es nicht klappt, ziehe ich mal das Log-File runter...
Gruß...
.
Ich habe wie geplant zunächst VirtualBox geladen (Neueste Version + Extension Pack), und dort Windows 10 Version 1709 64-Bit installiert - VM mit:
- virtueller 200GB-Festplatte
- virtuellen 4GB RAM
- UEFI-Mode-Emulation (kann VBox ja auch schon länger)
...auf meinem Lenovo Yoga 2-13 (unter Windows 8.1 64-Bit) mit i5/8GB RAM. Der hat da natürlich etwas "geschwitzt", aber das packt er...
1. Windows 10-ISO 1709 "eingelegt"
2. Direkt per Windows-Setup 2 Partitionen (jeweils 100GB...plus natürlich die autimatisch generierten kleinen EFI/Boot-Partitionen) auf der virtuellen 200GB-"Platte" erstellt
3. Dann Windows auf "C" installiert - sonst nichts besonderes gemacht. (Die D-Partition blieb erstmal unberührt)
4. Im Setup erstmal einen ersten User "User" erstellt.
5. Nach dem Hochfahren noch die VBox-Guest-Additions installiert (schadet ja nix), Windows 10 aktiviert, und alle Windows-Updates installieren lassen.
...sonst erstmal nix.
Diesen Status (virtuelle VHD-Datei) habe ich dann erstmal gesichert.
Beim nächsten Hochfahren wurde mir dann auch tatsächlich direkt das "Funktionsupdate für Windows 10 - 1803" ganz normal über Windows-Update angeboten!
Die 4 GB habe ich dann natürlich nicht nochmal heruntergeladen, sondern das vorher schon geladene ISO von Version 1803 "eingelegt", und im laufenden System das Update über die Setup.exe laufen lassen.
Ergebnis: Klappt einwandfrei.
Dann habe ich als 2. Testlauf erstmal wieder die Sicherung des installierten 1709 zurückgesichert, und dann als erstes die Sache mit den User-Konten auf "D" versucht - also in der Registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\ProfilesDirectory) auf "D:" gesetzt.
Und einen neuen User "Test" angelegt, der dann auch auf D angelegt wurde. Neugestartet, angemeldet, und dann unter dem neuen User "Test" auf D den alten User "User" am Ursprungsort gelöscht.
Soweit so klar.
Dann direkt den nächsten Update-Versuch auf 1803 per ISO...und HIER CRASHT ES!
Ich habe nicht mitbekommen, dass ein "Bluescreen" aufgetaucht wäre, aber es kam wie mir bereits bekannt nach dem Neustart die Meldung "Vorherige Version wird wiederhergestellt..."
Und dann wurde mir, nachdem das alte System wieder hochgefahren war diese Meldung angezeigt:
Unter diesem Code finde ich einen ´Thread in der Microsoft-Community, dass dieser Fehler klar am Userkonten-Pfad liegt!
Als 3. Test habe ich dann, nachdem das einzige Userkonto nun auf D: liegt, nun einfach den Pfad in der Registry von "D:" wieder auf "%SystemDrive%\Users" zurück-geändert!
Einmal erstellte User-Konten bleiben dann ja an dem Ort, an dem sie angelegt wurden - nur ein neues Konto würde dann wieder auf C:\Users angelegt...
Dann wieder das Update laufen lassen - und DANN FUNZT ES EBENFALLS! Benutzerkonto nach dem Update nach wie vor auf D.
Als 4. Test, wieder auf 1709 zurückgesetzt, und alle anderen "Tweaks" durchgeführt, die ich üblicherweise mache und mir eingefallen sind:
- (wie gehabt) Userkonto auf D: - und den Pfad danach wieder zurückgestellt
- Temp-Dateien TMP/TEMP (Global & User) auf "C:\Temp" geändert (Umgebungsvariablen)
- ClassicShell installiert
- Automatisch anmelden, Lockscreen abschalten
- Cortana deaktiviert! (HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Windows Search\AllowCortana = "0")
Und JETZT NOCHMAL geupdatet...KLAPPT!
Das heißt als Fazit:
"Windows 10" hat (genausowenig wie Win7/8) ein Problem mit dem geänderten User-Pfad!
Lediglich die Update-Überinstallation "beißt" sich daran...
Keine Ahnung, ob das in diesem Fall auch schon aufgetreten ist, wenn man z.B. Win7->Win8, Win7->Win10 oder Win8->Win10 geupdatet hatte. Das werde ich aber jetzt nicht auch noch testen, weil ich sowas nie gemacht habe oder machen werde (immer Clean-Install).
Ich werde also künftig die zu erstellenden User-Konten weiterhin auf "D:" legen, indem ich nach der Installation den Registry-Pfad ändere, dann alle Konten auf D anlege (oft ist's nur eins), und dann den Pfad nachher wieder zurücksetze!
Habe am Freitag die Gelegenheit, bei einem der 3 Problem-PCs zu versuchen, ob das Updaten dort dann klappt, wenn ich den Pfad zurück ändere. (Oder ob noch mehr im Argen liegt.)
Falls es nicht klappt, ziehe ich mal das Log-File runter...
Gruß...
.
Zuletzt bearbeitet:
Keine Ahnung warum du dir so viel Mühe und Arbeit machst.
Wie schon gesagt wurde hat Windows 10 es nicht so gerne wenn man irgendwo was verstellt.
Jetzt zu sagen: "Windows 10 macht das alles nichts, nur das Upgrade ist das Problem", ist doch Wortklauberei.
Ein Upgrade auf einen neue Version kommt nun mal jedes halbe Jahr und ist fast wie eine Neuinstallation und hat mit dem alten Win7 Überinstallieren eigentlich gar nichts mehr zu tun.
Egal ob nun von Windows 7 auf Windows 10 geupdatet wird oder von 1709 auf 1803.
Es kann immer Probleme geben wenn man zu viel verstellt, verschiebt, auslagert oder irgendwas Installiert was tief in das Windows System eingreift.
Wenn also das Update nicht klappt weil die User irgendwas gemacht haben wie zu XP oder Win7 Zeiten ist das kein Bug der Repariert werden muss, sondern die User haben was falsch gemacht.
Im Prinzip gilt immer noch diese Anleitung
https://www.win-10-forum.de/windows-10-faq/2605-windows-10-update-vorbereitung.html
auch wenn bei einem Upgrade von 1709 auf 1803 eigentlich nichts schiefgehen kann.
Für alle User die das fummel nicht lassen können gilt halt jedes halbe Jahr Windows neu clean installieren.
Wie schon gesagt wurde hat Windows 10 es nicht so gerne wenn man irgendwo was verstellt.
Jetzt zu sagen: "Windows 10 macht das alles nichts, nur das Upgrade ist das Problem", ist doch Wortklauberei.
Ein Upgrade auf einen neue Version kommt nun mal jedes halbe Jahr und ist fast wie eine Neuinstallation und hat mit dem alten Win7 Überinstallieren eigentlich gar nichts mehr zu tun.
Egal ob nun von Windows 7 auf Windows 10 geupdatet wird oder von 1709 auf 1803.
Es kann immer Probleme geben wenn man zu viel verstellt, verschiebt, auslagert oder irgendwas Installiert was tief in das Windows System eingreift.
Wenn also das Update nicht klappt weil die User irgendwas gemacht haben wie zu XP oder Win7 Zeiten ist das kein Bug der Repariert werden muss, sondern die User haben was falsch gemacht.
Im Prinzip gilt immer noch diese Anleitung
https://www.win-10-forum.de/windows-10-faq/2605-windows-10-update-vorbereitung.html
auch wenn bei einem Upgrade von 1709 auf 1803 eigentlich nichts schiefgehen kann.
Für alle User die das fummel nicht lassen können gilt halt jedes halbe Jahr Windows neu clean installieren.
Klar, ist im Prinzip das gleiche.Terrier schrieb:
Nur dass man das "früher" praktisch nie gemacht hat! Selbst wenn man niemals neu installiert hatte, wurde der Rechner eben 5, 6, 7 Jahre mit Windows 7 oder so verwendet.
Die "normalen" Windows-Updates klappen ja, auch wenn man ein paar Dinge verändert.
"Kaum" jemand hat vor Windows 10 ein laufendes/eingerichtetes Windows 7 z.B. auf Windows 8 "geupdatet", ohne neu zu installieren. Entweder gar nicht, oder Clean-Install.
Der Unterschied JETZT zu Früher ist doch, dann man nun - sofern man nicht alle 1/2 Jahr Lust auf Clean-Install hat, eben nun alle 1/2 Jahre "quasi" eine Update-Überinstallation macht. (was an eben früher praktisch nie machte/machen musste!)
An sonsten ist "Windows 10" immernoch zu 90% "Windows Vista"...nicht zu 100%, aber zu gefühlten 90%...
Oder eben herausfinden, *WO* es klemmt, eine Lösung finden (in meinem Fall Konten anlegen und Pfad wieder zurückstellen!) - und dann klappt doch alles! Sollte es dann eigentlich auch bei der nächsten Version wieder!Terrier schrieb:
------------------------------------------------------
Ergänzung zu obigem:
Wie gesagt, es bleibt nach dem Update eigentlich alles, was ich verändert hatte so, wie es war.
Lediglich die Globalen (!) TMP/TEMP, die ich auf "C:\Temp" geändert hatte, werden nach dem Update wieder auf den Ursprungs-Ort "C:\Windows\Temp" zurückgesetzt.
Na gut, ist eigentlich egal. Dann lasse ich das in Zukunft auf Windows\Temp (bzw. stelle es bei den 3 Rechnern auch wieder zurück)
Die User-Temp bleiben, die werde ich weiter auf C umändern, wenn es eine SSD+HDD-Konfiguration ist - das hat denke ich schon Speed-Vorteile. An sonsten sehe ich jetzt nicht so das Problem, wenn die AppData weiter im Profil auf D (HDD) liegen - das ist ja normal keine Masse.
Bilder/Musik/Video/Desktop/usw. SOLLEN ja auf die HDD.
Weil jemand gemeint hatte, meine 100GB für C wären "knapp". Naja wenn das ein Office/Internet/Multimedia PC ist, dann reicht das, wenn da Windows+Programme insgesammt vielleicht 30GB belegen. Nach dem Update entsteht dann ein "Windows.old", der dann aber automatisch irgendwann wieder gelöscht wird.
Falls ich einen Spiele- oder Videoschnitt-Rechner einrichten sollte, wo dutzende Gigabyte-schwere Programme drauf sollen, dann würde ich die C natürlich entsprechend vergrößern...klar!
Falls ich SSD+HDD habe (einer der 3 Rechner hatte eine 256GB SSD + 3TB HDD), dann reserviere ich trotzdem immer die komplette SSD-Größe für Laufwerk C...
Etwas "Sorge" macht mir bloß, dass beim Update wenn dort ein User vorhanden ist, auch auf Laufwerk D ein "Windows.old" entsteht, in den das komplette Konto nochmal kopiert wird!
Das wäre aber das selbe, wie wenn alle Benutzer-Daten auf einem großen Laufwerk ganz normal auf einer einzigen C liegen würden.
Werden dann bei jedem Update die KOMPLETTEN Benutzer-Dateien in "Windows.old" verdoppelt? Auch wenn da 2 TB Filme und Bilder drin sind?
Das wäre mies...da platzt dann die Platte...
BFF
¯\_(ツ)_/¯
- Registriert
- Okt. 2017
- Beiträge
- 26.639
Das Umlegen von Windows\TEMP nach Sonstwo kannst Du Dir sparen. Es gibt nur noch wenige Programm die dorthin schreiben und demzufolge ist das "Datenvolumen" dort sehr klein.
Ich finde in dem Ordner bei mir nur Logfiles von VMWare, Adobe und Microsoft Defender. Alles in allem 2 MByte. Ok, ich lasse automatisch die Systembereinigung woechentlich laufen.
Hat sich mittlerweile rumgesprochen bei den Programmierern, dass es einfacher ist %APPDATA% voll zu muellen.
BFF
Ich finde in dem Ordner bei mir nur Logfiles von VMWare, Adobe und Microsoft Defender. Alles in allem 2 MByte. Ok, ich lasse automatisch die Systembereinigung woechentlich laufen.
Hat sich mittlerweile rumgesprochen bei den Programmierern, dass es einfacher ist %APPDATA% voll zu muellen.
BFF
...erkläre DAS "Tante Trude", die sich vor 2 Jahren nen Laptop im Supermarkt gekauft hat, und sonntags E-Mails mit Tante Emma schreibt...Terrier schrieb:
Stimmt, das habe ich auch schon zu XP-Zeiten gemerkt...BFF schrieb:Das Umlegen von Windows\TEMP nach Sonstwo kannst Du Dir sparen. Es gibt nur noch wenige Programm die dorthin schreiben und demzufolge ist das "Datenvolumen" dort sehr klein.
Ich finde in dem Ordner bei mir nur Logfiles von VMWare, Adobe und Microsoft Defender. Alles in allem 2 MByte. Ok, ich lasse automatisch die Systembereinigung woechentlich laufen.
Hat sich mittlerweile rumgesprochen bei den Programmierern, dass es einfacher ist %APPDATA% voll zu muellen.
In der globalen "Windows\Temp" ist DOS-(Win95/98/ME)-Zeit wo es noch keine wirklich eigenständigen Userkonten gab ziemlich Essig.
Die User-Temp sollten finde ich - wenn C-System eine SSD ist, "ausreichend" Platz hat, und ich das Userkonto schon auf "D" packe - zumindest auf C/SSD bleiben.
Ich kann dann ja einfach die User-Temp auch in C:\Windows packen, statt nochmal nen separaten C:\Temp anzulegen...
----------------------------------------------------------------
An sonsten werde ich das (hoffentlich) hinkriegen mit den 3 Rechnern, dass die Updates laufen, und dann werde ich mich auch klar davon zurückziehen...
Das kommt noch aus "früheren Zeiten", als ich hier und immer wieder Leuten "den PC gemacht" habe.
Am Ende schneidet man sich damit nur selbst ins Fleisch habe ich gemerkt - weil man wie gesagt dann quasi automatisch der "Ansprechpartner" für jedes verschobene Desktop-Icon ist...und dass macht auf Dauer einfach nur KAPUTT!
Eskaliert ist mir das mal 2013/14, als ein Verwandter (selbstständiger Steuerberater, Klein-Büro, 4 Angestellte, 5 PCs+Server) mich gebeten hatte: "Ei, kannst du mal komme und mir das alles neu machen, du kennst dich ja aus". Er hatte mich sogar für 1 Monat als 400€-Kraft "angestellt"...
EINMAL UND NIEEE WIEDER !!
War alles HOFFNUNGSLOS veraltet. Hatte dann erstmal losgelegt, nen 15 Jahre alten, tosenden 100MBit-Switch durch nen kleinen GBit ersetzt, den Server gegen einen kleinen, sparsamen, schnellen neuen 1HE-Gerät mit Intel Xeon ausgetauscht, die alten Mini-PCs (á la "Pentium 4") durch Intel NUCs ersetzt, Bildschirme getauscht...ACH HERJE!!
Und alles von Windows XP + Server 2007 auf Win7 + Server 2012 umgestellt (bis auf das ActiveDirectory...das hatte ein anderer gemacht...)
NEIN...damit macht man sich kaputt! Nach dem Motto "das ist neu jetzt...warum klappt dies oder jenes in dem Steuer-Programm jetzt nicht". "Keine Ahnung - kenne ich mich nicht mit aus! Ruf den Support an! Am System liegt's nicht (lag's auch nicht)!"
...aus der "Nummer" bin ich dann auch GANZ SCHNELL wieder geflüchtet!!
Ich weiß, dass ich mich HEUTE (sogar hier!) mit meiner "Modderei" überall nur noch unbeliebt mache - egal ob bei Android, Windows/PC, sonstwas...
Ich mache das künftig nur noch FÜR MICH und rühre den Kram von Anderen nicht mehr an - auch wenn ich mich vielleicht bedingt auskenne...
Ja, auch mein Handy (Samsung A3/17) ist immernoch gerootet - einfach weil es immernoch Apps gibt die man nicht "normal" Sichern/Übertragen kann (ohne Titanium) - oder ohne mich bei 1000 Cloud-Diensten anzumelden..., und weil ich per Xposed-Mod den internen Speicher auf die SD auslagere, und weil ich "ganz altmodisch" den vollen Audio-Pegel am Klinkenausgang für große Kopfhörer und Aux-Anschlüsse haben will (wozu man Werte in eine Mixer-Config-File verändern muss - und auch das nur mit Root geht...)
Klar..."einfacher" wär's, ich trenne mich 1. einfach von Apps und Sachen, die nicht über die Cloud/Google laufen, lösche 2. halt einfach den ganzen Kram, wenn der interne Speicher von Whatsapp zugestopft ist, 3. kaufe mir ausreichend laute BT-Kopfhörer, und tausche das Aux-Autoradio gegen eins mit Bluetooth, oder trenne mich gleich von der ganzen Karre...
(Die "moderne" Variante...)
Hatte ich auch schon: "Ey du kennst dich aus...kannst mir mal das Handy rooten, der Sound ist zu leise am Radio oder am Kopfhörer und ich will dieses Menü da verändern..."
NIE WIEDER!
Nachher ist "man" nur dafür verantwortlich, dass die OTA-Updates nicht mehr gehen (obwohl vorher erwähnt!), und dies...und das...
Einem ist das ganze Galaxy Note 4 "gestorben" - da musste ich ihm erstmal klar machen, dass das vorher schon "leicht gezickt" hatte, jetzt GAR NICHTS mehr geht, und an dem Ding einfach der Flash-Speicher gestorben ist ("Sudden-Death").
Aber man gerät schnell "in Gefahr", der Dumme für Alles zu sein - auch wenn man es nachweislich NICHT ist...
Ich werde MEINEN Kram weiterhin modifizieren...von anderem lasse ich künftig die Finger!
Außerdem wird es scheinbar tatsächlich immer mehr so, dass alles eben zu einer "Blackbox" wird, woran man nichts mehr verändert, und es so "akzeptiert", wie der Hersteller (Software/Hardware) das eben "vorgibt"...ISSO!
(...auch wenn mir das so gar nicht gefällt!)
...sei's drum - nur so!
Zuletzt bearbeitet:
andy_m4
Vice Admiral
- Registriert
- Aug. 2015
- Beiträge
- 7.024
Ich finde es ja bemerkenswert, dass Windows schon über solch triviale Einstellungen wie den Nutzerordner zu verschieben stolpert und das bei solchen Kleinigkeiten von Einigen angemerkt wird, dass das ja auch Gefrickel und tiefer Eingriff ins System sei.
Ich mach das auch so, dass ich Nutzerverzeichnisse oder temporäre Verzeichnisse dahin packe, wo ich es für richtig halte. Ich kann mich aber nicht erinnern, das das mal zu Problemen mit Updates geführt hat. Selbst unter dem frickeligen Linux nicht.
Ich mach das auch so, dass ich Nutzerverzeichnisse oder temporäre Verzeichnisse dahin packe, wo ich es für richtig halte. Ich kann mich aber nicht erinnern, das das mal zu Problemen mit Updates geführt hat. Selbst unter dem frickeligen Linux nicht.
BlubbsDE
Fleet Admiral
- Registriert
- Juni 2011
- Beiträge
- 50.853
Windows stolpert darüber, weil der TE so gemacht hat, wie er es gemacht hat. Mann kann die Ordner woanders hin zeigen lassen. Aber eben nicht so. Was vor 20 Jahren unter Win 98 funktioniert hat, das muss heute nicht auch funktionieren
Zuletzt bearbeitet:
Weiß was du meinst, müsste ich aber erstmal schauen wie das genau funktioniert...firexs schrieb:
Wird bei den "Home"-Versionen von Win wohl auch nicht gehen...firexs schrieb:
Ist ja nach meinem Test auch "zufällig" genau DIE EINE Kleinigkeit, an der sich das Update stört...alles andere schulckt es!andy_m4 schrieb:
Ja, hatte ich auch ja schon erwähnt - aber dann betrachte mal was das IN DER PRAXIS genau heißt:firexs schrieb:
An Windows als System an sich ändert das genau gar nichts - lediglich an der Update-Politik die Microsoft nun "fährt"...
Wie gesagt, "früher":
Windows XP/Vista/7/8.1 , 10 Jahre Support, für ein und die selbe Grundversion, "normale" Windows-/Sicherheits-Updates für 10 Jahre, ohne Über-/Neuinstallation.
"Heute" Windows 10:
Neuinstallation/Rechnerkauf mit neuestem Windows 10-Release. Normale Windows-/Sicherheits-Updates für 1,5 Jahre. Dazu alle 1/2 Jahre eine neue Grundversion (Sub-Release).
Früher habe ich NUR Clean-Installs gemacht. Entweder um ein "zugemülltes" System neu aufzusetzen, oder bei einem komplett neuen Rechner.
Dann lief da XP/Vista/7/8, und das blieb über die komplette Nutzungsdauer so, und wurde nur mit "normalen" Windows-Updates versorgt.
Das geht mit Windows 10 immernoch so, aber nur noch für max. 1,5 Jahre - dann muss man zumindest jede 3. Grundversion irgendwann "mitmachen", weil es sonst keine Updates mehr gibt.
Und da man normal nicht alle halbe Jahre eine komplette Neu-Installation macht, wird das eben per Über-Installation gelöst - was ja früher auch schon ging! (Nur kaum einer gemacht hat)
Und DIESE ÜBER-INSTALLATION "beißt" sich eben an so Sachen wie dem User-Pfad - NICHT die "normalen" KB-Updates.
Höchst wahrscheinlich würde sogar der gleiche Fehler auftreten, wenn ich versuchern würde ein Windows 7 (mit angepasstem User-Pfad) per Über-Installation z.B. auf Windows 8.1 zu "updaten"...(habe ich nur nie so gemacht).
"Größere Updates" gab es früher ja auch schon, in Form von "Service Packs" für XP/Vista/7. Das war aber keine komplette Update-/Neu-/Überinstallation, wenn auch etwas "mehr" als ein "normales" KB-Update.
Bei Windows 8 gab es aber auch bereits eine "Über-Installation" in Form eines Updates - nämlich 2013 von Windows 8(.0) auf Windows 8.1...
-----------------------------------------------------------------------------
Ich war wie gesagt gestern abend beiläufig bei dem Bekannten mit dem einen "klemmenden" Rechner:
Ich habe das Update auf 1803 erstmal noch einmal "failen" lassen, um den Fehlercode zu bekommen. Es war exakt der gleiche, wie oben bei meinem Test über VirtualBox!
Also was habe ich gemacht? Das selbe wie bei meinem Test...
Das User-Konto auf D gelassen, und in der Registry den Pfad von "D:" auf "%SystemDrive%\Users" zurück-geändert!
...und siehe da - UPDATE LÄUFT!
Und genauso mache ich das jetzt auch noch bei den verbleibenden beiden Rechnern.
Ich werde es also in Zukunft einfach so machen, dass ich nach der Neu-Installation erst den Registy-User-Pfad ändere, DANN das Konto auf "D" anlege, und den Pfad direkt danach wieder zurücksetze - FERTIG.
.
