[wolf22]

Ein paar Erfahrungen aus Update-Aktionen von 9879 über 9926 bis 10041

Grundsätzlich kann keine Installation übersprungen werden und es müssen auch alle bisher bereitgestellten Updates der jeweiligen Version aufgespielt sein.
Sonst wird die nächste TP-Version nicht angeboten.
Dabei kann schon mal mehrfach der Updatevorgang gestartet werden, bis es auch richtig durchgeführt wird.
Aus unerklärlichen Gründen werden auch Updates beim Neustart wieder "zurückgerollt" und es wird eine neue Installation versucht.
Das kann man 2-3 Mal machen und wenn es immer noch nicht will muss es dann manuell installiert werden.
Dazu in den Updateverlauf gehen und sich die "failed"-KB-Nummern raus schreiben.
Hier waren es die KB3032359 , KB3040021 , KB3036140 und KB3039066 ( die dauert relativ lange bis es fertig ist) und diese sofort nach dem Neustart, wenn sie zurück gesetzt wurden, starten.
Sonst gibt es das nächste Problem, weil Das System selbst feststellt, dass da noch Updates fehlen oder nicht korrekt installiert und lädt sie neu.
Das hat dann zur Folge, dass beim manuellen Aufruf/Start dann die Meldung kommt - ist bereits auf dem System vorhanden - , auch wenn sie "fehlerhaft" ist.

Die Updates für die manuelle Installation bekommt man von - http://ms-vnext.net/UpdateArchive/ -
Da dann die richtige Version nehmen, denn es liegen dort beide Versionen von x86 und x64
Falls man doch eine falsche erwischt hat, dann kommt beim Aufruf einfach die Meldung - ist nicht für das System - und es passiert nichts weiter.

Wenn nun alle Updates richtig installiert wurden bekommt man auch die nächste TP-Version angeboten und kann weiter "testen".

Nach dem die "failed-Updates" durch die manuellen ersetzt wurde dann noch vom System die KB3038930 geholt und nun kam auch gleich automatisch - fbl_impressive-10041 Enterprise -

Warum nun auf dem Pro und EP-System diese Problem aufgetreten sind, denn es war auf diesen beiden Testinstallationen gleich, da muss ich die Antwort erst mal schuldig bleiben, während andere gar keine Probleme bereitet haben.

Ein weiteres Problem kann eine zu kleine Partition bereiten.
Bei den Updateaktionen werden ein
RecoveryImage mit 11.6 GB
und eine
Windows.old mit 24.2 GB
eingerichtet, wobei die Größen von den bereits installierten Programmen usw. abhängig sind.
Diese ca. 35 GB sollte man also mit einplanen, denn es kommt keine Meldung, dass der Speicherplatz nicht ausreicht.
Es gibt einfach nur Probleme mit dem Update, dass irgend etwas nicht eingerichtet wird.
Ist wohl in den Log-Dateien vermerkt, da habe ich jedoch nicht rein gesehen.

[RalphS]

Warum der Streß? Über WU kann man genau EINmal versuchen, entweder es klappt - oder es klappt halt nicht.

Klappt es, ist sowieso alles gut.

Klappt es aber NICHT: Installationsmedium beschaffen, entweder direkt von Microsoft oder aber das von WU heruntergeladene (ESD-Datei, findet sich irgendwo unter \Windows\SoftwareDistribution\Download).

Das dann mit dem esd decryptor in eine ISO umbauen. Auf DVD oder USB-Stick tun - oder, falls eh nur ein Upgrade gemacht werden soll, einfach per Explorer mounten - reicht schon.

Installation anstoßen, warten, fertig.

Ganz ohne jeden "Zwichenschritt".

[wolf22]

Es geht um mehr als einfach mal nur so installieren sondern sammeln von Erfahrungen was passiert wenn usw.
Natürlich kann ich es auch einfach machen, aber ich will auch das neue Konzept von MS hinterfragen.
So ist z.B raus gekommen, dass Zwischenrevisionen nicht übersprungen werden, alle Updates da sein müssen und was passiert bei/mit der Finalen wenn eine Version nicht installiert wurde.
Bei Programmen Zwischenversionen überspringen ist kein Problem und hier werden wir sehen wie dann nach der Finalen weiter geht.
Ich mache es also nicht aus "Jux und Dallerei"

[wolf22]

Ist das ein "Wunschkonzert", denn ich erkenne da kein System.
Ausgangslage zum testen - eine 128 GB Sandisk ULtra SSD partitioniert, um da jeweils Windows 10 Pro bzw. EP 9926 x64 in je einer vorformatierten primären Partition zu installieren.
Es wird also kein Bootpartitionen mit 350 MB erstellt.
Dann das Internetupdate der Pro auf die 10041 und es werden zwischen den beiden Systeminstallationen zwei zusätzliche primäre Partitionen mit 450 bzw. 449 MB angelegt.
In der 450 liegen die bekannten Bootdateien während die 449 (Zusatzpartition_2_449MB_01.jpg) "noch" leer" ist.
Beide Partitionen gelöscht und beide nun installierten Systeme 10041 Pro sowie 9926 EP starten problemlos.
Die EP-Partition gewandelt von primär in logisch, um nicht irgend welche Probleme zu bekommen, denn es gehen eben nur 4 primäre Partitionen auch wenn die Bootpartitionen gemeinsam genutzt werden.
Dann das Internetupdate der EP auf die 10041 gemacht und nun wurde keine Zusatzpartitionen erstellt.

Zitat (RalphS: 22. März 2015 - 20:14)

Über WU kann man genau EINmal versuchen

Das stimmt z.B. schon mal nicht, denn es ist mir schon mehrfach passiert, dass nach einem ersten nicht erfolgreichen Update es dann im zweiten oder dritten Anlauf doch installiert wurde.

edit:
Als kleines "Schmankerl" von MS - das System steht bereits auf 10041 und ich habe nur gerade auf DE-Language umgestellt und als ich nun die Updates noch mal aufgerufen habe wird mir noch mal fbl-impressive 10041 Enterprise - sofort auf das System gespielt.

Angehängte Miniaturbilder

• 
• 
• 
• 

Dieser Beitrag wurde von wolf22 bearbeitet: 23. März 2015 - 10:59

[RalphS]

Ich seh das Problem nach wie vor nicht. Das sind Previews, die für "ordentliche" Tests eh zu schnell rausgeschmissen werden; da kann man nicht im Detail verlangen, daß alles "sauber" ist. Nicht, daß das überhaupt so angedacht war mit einer Preview.

Ansonsten ist es doch nur recht und billig, daß Windows, so freier (nicht zugeordneter) Speicherplatz vorhanden ist, diesen auch für "kritische" Dinge verwendet - wenn es ihm möglich ist.

Das sind nunmal a) die Startumgebung und b) die Wiederherstellungsumgebung - wobei letzere eine angepaßte Form der ersteren ist und diese aber aus Integritätsgründen redundant vorhanden ist, sodaß die *Wiederherstellung* selber nicht auf eine funktionierende *Startkonfiguration* des installierten Betriebssystems angewiesen ist.

Deren Integrität wird dann damit sichergestellt, daß davon möglichst WENIG gelesen (und geschrieben!) wird. Daher werden sie isoliert und bekommen auch keinen logischen Zugriffspfad zugeordnet (LW-Buchstabe, Mountpoint).


DAS ist nun wirklich kein Bug, sondern ein Feature.


Ansonsten muß ich irgendwie was falsch machen, denn während bei mir natürlich auch das eine oder andere Upgrade schiefgegangen ist (ESET und VirtualBox waren da die Verursacher) mußte ich nie und nirgends irgendein Update (KBxxxx) oder sonstwas reinstallieren, geschweige denn eine "Zwischenbuild" übernehmen. Windows war zwar nicht immer willens, das Upgrade sauber durchzuführen; aber jeder installierte "alte" Build (bei mir) hat bisher zu jeder Zeit die derzeit aktuellst verfügbare Build heruntergeladen und diese installiert, egal was da für ein KB* installiert oder eben nicht installiert war (es sei denn natürlich, diese(s) wurden im selben Rutsch nochmal mit installiert, in die Logfiles hab ich da nicht nochmal geschaut).


Aber selbst so. Noch ein paar Monate und dann war's das mit der "Preview" und wir kriegen RTM (wenn man das dann überhaupt noch so nennen kann).

Dieser Beitrag wurde von RalphS bearbeitet: 23. März 2015 - 14:45

[wolf22]

Ich habe nicht behauptet, dass das ein Bug ist sondern eben bei eigentlich gleichen Systemen unterschiedliche Auswirkungen/Einstellungen gehabt, ohne das da selbst manuell eingegriffen wurde sondern einfach machen lassen.

Nur mal als Randbemerkung.
Ich schreibe das nicht, dass es überall auftritt, sondern, dass es passieren kann, so dass dann Betroffene eine Lösung sehen.
Ich habe hier auch Testsysteme, die vollkommen klaglos über alle Updates usw. gekommen sind.
Ein PC ist eben nicht wie jeder andere und das solltest du eigentlich wissen.
Es ist nun müßig so tief da ein zu steigen, wo nun genau die Ursache liegt.
Dafür ist es eben noch eine TP und erst in der Finalen lohnt es sich, da hier noch mit mehr als einer Änderung zu rechnen ist.
Keiner weiß wie die Finale dann wirklich aussehen wird, was wieder gestrichen oder dazu gefügt wird.

Nur mal als Beispiel:
Ein PC-System mit 5 identischen Images als Multiboot und 5 Grundprogrammen.
Dann dort auf jedem System die gleichen weiteren 5 Programme aufgespielt aber in unterschiedlicher Reihenfolge und schon hatte ich 5 unterschiedlich reagierende Systeme, wenn weitere Aktionen durchgeführt wurden.

Das hatte ich mal vor Jahren durchgeführt um zu wissen was passiert wenn und schon lösen kleine Unterschiede ganz andere Reaktionen aus.
So hatte ich es nicht direkt vermutet oder erwartet.

Das dazu zu deiner Meinung, was bei mir passiert sollte auch bei anderen so sein.

Zitat

Ansonsten ist es doch nur recht und billig, daß Windows, so freier (nicht zugeordneter) Speicherplatz vorhanden ist, diesen auch für "kritische" Dinge verwendet - wenn es ihm möglich ist.

Da war kein freier ungenutzter Speicherplatz, der irgendwie hätte genutzt werden können, sondern es wurde eine Partition reduziert, um die beiden 450 MB-Partitionen an legen zu können.

Dieser Beitrag wurde von wolf22 bearbeitet: 23. März 2015 - 20:30

[Nemo_G]

Hallo Jungs und Mädels!
Könntet Ihr mal bei Euch testen (und auch berichten), ob die Registry-Patches, mit denen man "Systemsteuerung | Windows Update" wieder sichtbar machen kann, bei Euch funktionieren?
Wie im selben Thread schon berichtet, wird WU wieder angezeigt; die Suche nach neuen Patches läuft allerdings auf Fehler.
Danke!
Gruß, Nemo_G

[wolf22]

Meine angelegte Verknüpfung auf dem Desktop zu - C:\Windows\System32\wuapp.exe - wurde von der 9926 auf die 10041 übernommen.
Habe sie dann mal gelöscht und anschließend neue Verknüpfung hergstellt - startet erst mal nicht und unter
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explore
geht es nur bis Polices - dann kommt nichts mehr.
Dann die

Zitat

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate\UX]
"IsConvergedUpdateStackEnabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings]
"UxOption"=dword:00000000

Das als .reg abgespeichert und wieder ausgeführt.
Anschließend öffnete die Desktopverknüpfung wieder - Einstellungen - Windowsupdate.

Der reg-Eintrag endet trotzdem weiterhin bei Polices
Die eigentlichen Einträge :
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ Policies\Explore "NoWindowsUpdate" mit dem Wert 1 und den Wert auf "0" sind nicht vorhanden.

Dieser Beitrag wurde von wolf22 bearbeitet: 24. März 2015 - 20:52

[Nemo_G]

Hallo Wolf22,

Und was passiert bei Dir, wenn Du die nötgen Einträge nach HKLM statt nach HKCU schießt?

Dieser Beitrag wurde von Nemo_G bearbeitet: 24. März 2015 - 23:58

[wolf22]

Update eines Enterprise ToGo-Sticks

Mit der Freigabe der 10041-Slow-Version wird auch auf dem ToGo-System das Update automatisch ausgelöst.
Dadadurch, dass die Updatefunktion bzw. deren Einstellmöglichkeit noch durch MS fest eingestellt ist hat man auch keine Möglichkeit da ein zu greifen.
Selbiges ist nun gestern Abend passiert und das System hat sich die gesamten ca. 3 GB herunter geladen und mit der Installation bzw. der Vorbereitung begonnen.
Nach ca. 10 Minuten kam dann die Meldung, dass Windows 10 nicht auf einem USB-Stick installiert werden kann und wurde beendet.
Als anschließende Fehlermeldung kam - 0xc1900200 -
Die - fbl-impressive 10041 Enterprise - startet nach einem Neustat nicht automatisch wieder mit dem Download und auch auf dem System liegen keine Daten.
Ich habe jedenfalls keine mehr gefunden, und die Ordner - RecoveryImage- und - Windows.old - wurden noch nicht erstellt.

Als Fehlermeldung kam - 0xc1900200 -Windows 10 Technical Preview Build 9860 fails, 0xC1900200, 0x8024200D, 0x80246007,
die aber eine nebensächliche Bedeutung hat, da eben die Ursache eine andere ist.
Da wird aber noch mal beschrieben, dass das fbl-Update erst durchgeführt wird, wenn auch alle Vorupdates vorhanden sind.
Weitere Info zu Fehler 0x8024200D, 0xc1900200 bei Update von Windows 10 Tech Preview nur der Vollständigkeit halber.

Wenn das Update durch diesen Ablauf automatisch abgebrochen wurde startet der Download nach einem Neustart auch nicht wieder.
Man kann ihn dann aber durch Aufruf über Windowsupdate erneut starten was aber keinen Sinn macht, nur ich habe es probiert um heraus zu bekommen, ob man dann durch ein runterfahren und Neustart das unterbinden kann.
Nein - der Download des Updates wird anschließend fortgesetzt und öffnet man Windows Update, so steht da - Installation.
Noch mal laufen lassen und bei 9 % kommt dann die Meldung, dass es nicht installiert werden kann.
Mir fehlten noch ein paar Angaben, die ich beim ersten Mal nicht gleich gespeichert hatte, da ich mir solch ein Problem wohl schon gedacht hatte, aber dann doch nicht so richtig erwartet.

Fazit und mögliche Erkenntnis.
Es lohnt also im Moment noch nicht sich einen ToGo-Stick zu erstellen, wenn man nicht bereit ist, bei jedem TP-Versionswechsel diesen neu zu erstellen.
Das geht nur über die Installation von der Vollinstallationsversion der Enterprise auf einem System und von da dann den Stick erstellen lassen.
Es muss nun nicht unbedingt einer dieser Sondersticks für die ToGo-Version sein, die als FP erkannt werden sondern es geht natürlich auch eine kleine externe 2.5" HDD oder eine kleine SSD per Adapter am USB-Port.
Das ist sogar noch kostengünstiger und hat mehr Speicherplatz.

Eine weitere Frage ergibt sich daraus, wenn MS seine neue Updatepolitik mit dem gesamten Systemaustausch fortsetzt.
Bei dann erscheinenden neuen Versionen wird wohl wieder die Meldung kommen, dass das nicht auf einem Stick erstellt werden kann und man erst den Umweg über ein laufendes Enterprisesystem machen muss mit dann einer kompletten Neuinstallation auf dem Stick mit allen neu ein zu richtenden Programmen.

Angehängte Miniaturbilder

• 
• 
• 

[wolf22]

Update 9926_10049

Ich hatte die Installation direkt von der 9926 über 10041 auf die 10049 laufen lassen.
Ein direktes Überspringen geht nicht.
Die RecoveryImage und Windows.old wurden zwischendurch eigenständig ausgetauscht bzw. gelöscht und neu erstellt.

Update 9926_10049 x64-System
Recovery-ESD
10041 - 2.539.331.672 byte
10049 - 2.548.766.904 byte

Windows old
9926 - 25.879.015.532 byte
10041 übersprungen und wurde automatisch gelöscht
10049 - 13.199.457.222 byte

Bei der 10049_fast wurde hier der CardReader-Slot vom NB nicht eingebunden.
Online-Aktualisierung via Eigenschaften meldete - der aktuellste Treiber ist installiert.
Behoben mit Download von:
realtek pcie cardreader (pci device)
http://www.realtek.c...3&GetDown=false
Card reader driver for XP,Vista,Win7,Win8,Win8.1 V6.3.370.71 2015/2/9 10078k

0002-RtsXStor_6.3.370.71.zip

Dieser Beitrag wurde von wolf22 bearbeitet: 31. März 2015 - 22:11