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 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)
Anzeige
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.
Anzeige
Effektiv wird die 20H2 ausgeliefert, es wird nur anders angezeigt in der SCCM Konsole. Wir haben bereits Tests gemacht in unserer Umgebung.
War mit 1903 und 1909 genauso
Das weiß ich nicht, hatten wir nicht im Einsatz und es gab auch keinen Grund dazu.
Wenn ich auf die Bilder klicke, kommt nix größeres, es bleibt klein und unleserlich.
Übrigens:
– https://www.bleepingcomputer.com/news/microsoft/windows-10-20h2-update-fixes-broken-in-place-upgrade-feature/
– https://www.bleepingcomputer.com/news/microsoft/windows-10-cumulative-update-preview-kb4586853-released/
Original war nicht besser … leider.
Ansonsten:
Windows 10 2004/20H2: Update KB4586853 – korrigiert Inplace-Bug
Aber Lawrence Abrams hat es bei Bleeping Computer sehr schön bebildert beschrieben.
Dasa mit dem Inplace-Bug auf Ihrer Seite hab ich jetzt auch gesehen, abere das Zweite ist auch interessant.
Schön wäre bei Ihnen im Blog eine Newsticker-Übersicht, ähnlich wie bei Heise, Golem, Winfuture usw. wo man auf einen Blick alle Überschriten des Tages/der Woche sieht, ohne runterscrollen zu müssen.
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?
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.
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.
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.
Warum das mit der Build Nummer so ist, wird dort von Microsoft erklärt:
https://support.microsoft.com/en-us/help/4591163/version-and-build-number-are-reported-incorrectly
Erst wenn man Windows 1909 oder 20h2 mit der ISO installiert, wird es zu Build Nummer 18363 oder 19042 weil bei der Installation das jeweilige Enablement Package angewendet wird.
Ich glaube genau danach habe ich gesucht.
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.
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.
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
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 :)