Windows 10 20H2: Gesammeltes Chaos mit dem Install-Abbild

Heute noch ein kleiner Beitrag zu einem leidigen Thema, welches mir von Blog-Leser Andreas P. per E-Mail zuging. Der Punkt: Kann ich mich darauf verlassen, dass in per Microsoft Endpoint Configuration Manager ausgelieferten Windows 10-Installationsabbildern auch das drin ist, was drauf steht? Seine Antwort lautet Nein.


Anzeige

Weil es gerade so schön passt, starte ich mit einem Joke. Mir ist gerade die Einladung zum Azure Developer Community Day 2020 am 8. Dezember 2020 in München in die Finger gefallen. Ist eine Online-Veranstaltung und ich hätte die Mail sofort gelöscht. Aber dann sprang mir in der Agenda der Punkt ‚A Hitchhiker’s Guide to Chaos Engineering‘ von Maik Figura ins Auge – weckte Assoziationen …

denn da war die Mail von Andreas P., die mit dem Betreff Das gesamte MS Chaos und dem Aufmacher ‚mal wieder eine Story für deinen Blog‘, die seit dem Wochenende in meinem Postfach steckt (danke für den Hinweise). Möchte euch nicht vorenthalten, was Andreas schreibt:

Für mich ist klar, dass Windows 2009 ..sorry 20H2.. die neue Basis in meiner Windows Umgebung werden wird. Aktuell laufen die Maschinen dank Windows 10 Enterprise noch auf Windows 10 1809 und es gab keine Notwendigkeit das zu ändern. Mit dem Supportende im April 2021 bedarf es jedoch eines Refresh der Betriebssystem Abbilder.

Normalerweise verteile ich die neuen Abbilder über meinen Microsoft Endpoint Configuration Manager (Configuration Manager oder ConfigMgr or SCCM) im Rahmen eines Upgrades. Zur Vorbereitung lade ich die neueste Version als ESD von MS runter, die mir über den SCCM/WSUS zur Verfügung gestellt. Aktuell ist dies ein Packet mit dem Namen „Funktionsupdate für Windows 10 (Business-Edition), Version 20H2, de-de x64“ und enthält die Datei „19042.572.201009-1947.20h2_release_svc_refresh_CLIENTBUSINESS_VOL_x64FRE_de-de.esd“. Sieht auf den ersten Blick genau nach dem aus, was ich benötige. Das aktuelle Herbst Update mit dann 30 Monaten Support (Ruhe bis April 2023).

Doch ein Blick in die ESD Datei (via dism /Get-WimInfo /WimFile:install.esd) fördert komisches zu Tage: Version: 10.0.19041(.572). Siehe dazu den Auszug aus der Powershell:

PowerShell-Ergebnisse install.esd-Inspektion
PowerShell-Ergebnisse der install.esd-Inspektion

Ein Import in SCCM bestätigt den Verdacht (zu erkennen an der Betriebssystemversion, die Nummer bei Version trägt man selbst ein)


Zum Vergrößern klicken

Microsoft liefert die Build 10.0.19041(.572) in der install.esd aus, und nicht wie ‚auf der Packung angegeben‘ die 19042.572.201009-1947.20h2. Dazu schreibt Andreas: Jetzt gilt es erstmal wieder herauszufinden, ob wirklich zuerst 20H1..ach ne 2004 installiert wird, oder ob es hier um ein irgendwie geartetes Problem bei der Anzeige handelt.

Nun ja, es kann sein, dass Microsoft da beschlossen hat, immer die install.esd der Frühjahrs-Build für verwaltete Umgebungen auszuliefern. Dann könnte das Enablement Package-Update beim Setup oder direkt in der OOBE-Phase nachgeschoben werden. Das muss man testen, denn man hat ja sonst nicht zu tun. Ergänzung: Sehe gerade den Kommentar, dass das getestet wurde – es kommt die 20H2. Falls sich jemand nun noch immer nicht ausgelastet fühlt, hätte ich halt die Fortbildung ‚A Hitchhiker’s Guide to Chaos Engineering‘ von Maik Figura im Angebot.


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Anzeige


Dieser Beitrag wurde unter Windows 10 abgelegt und mit ISO, Windows 10 20H2 verschlagwortet. Setze ein Lesezeichen auf den Permalink.

16 Antworten zu Windows 10 20H2: Gesammeltes Chaos mit dem Install-Abbild

  1. Fahiko sagt:

    Effektiv wird die 20H2 ausgeliefert, es wird nur anders angezeigt in der SCCM Konsole. Wir haben bereits Tests gemacht in unserer Umgebung.

  2. Cl sagt:

    War mit 1903 und 1909 genauso

  3. Oliver L sagt:

    Und was soll uns das jetzt sagen? Wer fummelt und bastelt und in interne Dateien schaut und nicht einfach nur der Anleitung folgt und das Update wie üblich auf einem Testsystem erst einmal durchlaufen lässt, hat (bzw. macht sich) Probleme, die er sonst nicht hätte?

    • JohnRipper sagt:

      Falsch.

      Alle halbwegs professionell verwalteten Umgebungen passen entweder das Installtionsabbild (boot/install.wim) an oder ziehen in der OOBE-Phase noch etwas nach. Teilweise geht das auch gar nicht anders, gerade wenn mit PXE oder Windows Autopilot Geräte bereitstelle.
      Je nachdem auf was sich die Anpassungen beziehen, macht das eine oder das andere mehr Sinn.
      Boot/Install.wim anzupassen macht insofern Sinn, dass man es einmal macht und nicht jeder Computer den identischen Vorgang erneut durchführt.

  4. Lutz S sagt:

    Das mit den „falschen“ Build-Version-Darstellungen ist doch eigentlich kalter Kaffee – zumindest für mich.
    Meine privaten Clients sind alle 20H2 (Build 19042.630).
    Schaue ich im WSUS von meinem Server 2019 wird mir dort suggeriert, ich hätte die Build 19041.610 – also Win 10 2004.

    Und, wie Oliver L so passend schrieb: Immer erst mal ne Testmaschine betanken, bevor man an produktive Clients geht. und dann einfach mit winver schauen. was wirklich Sache ist.

    Wir haben Mitte letzten Monats unser Deployment-Tool von Empirum zu MECM gewechselt, Empirum kommt bei 30.000 Clients an seine Grenze.
    Ich schaue die Tage mal, ob ich ansatzweise die Aussage von Andreas P nachvollziehen kann, was die angebotenen Abbilder betrifft.
    Was mich an MECM ein wenig stört – es zeigt ein Deployment nicht Realtime an.
    Das hat Matrix mit seinem Empirum bedeutend besser gelöst.
    Auch ist das Tool etwas behäbig im Ganzen in seiner Usability, beim Deployment ist es aber richtig schnell (wenn man einmal seine ganzen Collections konfiguriert hat).
    Gut, daran werde ich mich gewöhnen.

    • Andreas P. sagt:

      Tatsächlich haben wir erste Test gemacht, bei der wir Testmaschinen mit einer Versionen aus dem Media Creation Tool befüllt haben.

      Dass das es letztlich kuddelmuddel bei Versionsnummer gibt, damit hab ich nicht gerechnet. Aktuell handelt es sich aber ein frühes Teststadium.
      Defacto gilt es aber jetzt den gesamten Workflow zu testen, da wir die Adressierung via Collections vornehmen, siw auf Build Nummern zurückgreifen. Keine Ahnung, ob das jetzt unmittelbar funktioniert.

      Ich findes nur nervig. Bisher war das relativ einfach:
      Build einladen, Task Sequenz erstellen, testen, anpassen, testen, fertig.

  5. Janami25 sagt:

    Das ganze durcheinander hätte überhaupt nicht sein müssen, wenn es definitiv nur ein Major Realease pro Jahr geben würde. Oder wenn sich zur Herbst Version eben nicht die Major Version ändern würde, sondern eben nur die Zahlen hinterm Punkt.

    Vor allem, wenn man bedenkt, das bereits sowieso alle Funktionen im H1 Release ebenso enthalten sind, und nur noch in H2 freigeschaltet werden. Ich finde nicht, das das eine höheres Major Release rechtfertigt.

    Man sieht ja, was auch noch so nebenbei für Schwierigkeiten auftreten. Siehe die Probleme beim Inplace Upgrade, das beim wechsel auf die 1909 und erst recht auf die 20H2 gar nicht ging, eben wegen dem Versionsdurcheinander bzw. der Erkennung der tatsächlich installierten Version.

    Hier ist Microsoft gefragt, diese Verwirrung wieder aufzulösen. Selbst im privaten Bereich ist man nicht sicher, was man sich als Installationsabbild erstellt, wenn man anstatt 19042.xxx dann 19041.xxx herunterlädt.

    Das ist nun mal mehr als verwirrend. Ich verstehe nicht, wie man das gutheissen kann.

    • Lutz S sagt:

      Da kann ich Dir nur zustimmen!
      Der ganze Update-Wahnsinn seitens MS sorgt mehr für Verwirrung als für Klarheit!
      Von daher sollte sich das Unternehmen mal überlegen, ob es nicht klüger wäre, ein mal pro Jahr ein „Major“ herauszubringen. Das gab es zuletzt zu Win7-Zeiten – und diese Strategie hat doch bestens funktioniert! zumal die Admins damals weniger Arbeit damit hatten.
      Lieber weniger und Qualität, als halbjährlich und jede Menge Arbeit für Admins der Umgebungen.
      Manchmal ist weniger halt einfach mehr.
      Zumal der normale User in einer Arbeitsumgebung wenig Nutzen von angeblich neuen Features von MS hat.

  6. fre4kyC0de sagt:

    Unter Umständen ist das ein DISM/CBS-Bug. Da hilft unter Umstaänden nur, ob in der install.esd unter „\Windows\servicing\Packages“ namens „Microsoft-Windows-20H2Enablement-Payload-Package*“ oder „Package_1_for_KB4562830*“ existieren. DAnn ist das Enablement Package integriert.

    Der „Fehler“ kommt dadurch zustande, dass die 19042 effektiv ja eine 19041 ist (vgl. Dateiversionen), bei der lediglich ein Feature-Bit (in diesem Fall 2093230218) aktiviert wurde, um die neuen Funktionen zu aktivieren und den angezeigten Build um 1 zu erhöhen. Eventuell hat MS in irgendeiner API da die Build-Erhöhung bei gesetzem Bit vergessen.

    Viele Grüße

  7. Markus K sagt:

    Am WSUS melden sich 20H2 clients auch mit 19041 und die Revision (sprich Patchlevel) stimmt auch nur sehr selten.
    Lässt man sich auch einem client in der powershell die Version anzeigen wirds auch gleich spannend:
    [System.Environment]::OSVersion.Version
    liefert
    Major Minor Build Revision
    —– —– —– ——–
    10 0 19042 0

    Wie Revision 0… alles halbfertig würde ich sagen :)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.