[English]Seit einigen Tagen hat Microsoft ja das Windows 10 Mai 2021 Update (Version 21H1) als Funktionsupdate freigegeben. Wer über PowerShell oder andere Tools die Windows 10-Version ermitteln möchte, läuft aber in gewisse Schwierigkeiten. Die ReleaseID von Windows 10 21H1 liefert den Wert 2009 zurück. Ich bin zufällig auf die entsprechende Diskussion gestoßen und stelle das mal hier im Blog zur Information ein.
Anzeige
Das Ganze wurde auf Twitter durch Trevor Jones in diesem Tweet angestoßen. Dazu schreibt Jones: Hmm, what's this? The ReleaseId for W10 21H1 after enablement package install is 2009… und hat im Tweet nachfolgenden Screenshot gepostet (ich habe die PS-Ausgabe auf zwei Zeilen aufgeteilt, um die Lesbarkeit zu verbessern.
Die DisplayVersion wird zwar korrekt mit 21H1 angezeigt, aber die ReleaseID 2009 ließ ihn stutzen. Relevant könnte dies für Tools wie WSUS, WAC oder alle (PowerShell-)Scripte werden, die von der ReleaseID abhängen, um die Betriebssystemvariante zu ermitteln.
Gabe Frost von Microsoft lieferte dann in Folgetweets die Anworten. Das Ganze sei by-design, und die ReleaseID zur Auswahl der Betriebssystemversion ist veraltet.
Anzeige
Frost schreibt, dass die ReleaseID weder dokumentiert ist, noch von keiner API (nur Registrierung) offengelegt wurde und nur für die Kompatibilität vorhanden sei. Um Windows 10 Version 21H1 zu unterstützen (Umstellung auf gemischte Ganzzahl+Zeichenfolgen), haben die Microsoft-Entwickler einen neuen Schlüssel erstellt und den alten Schlüssel in Ruhe gelassen. So wurde die Information DisplayVersion geboren. Alles, was sich auf die ReleaseID zur Ermittlung der Betriebssystem-Build verlässt, wird also mit Windows 10 Version 21H1 nicht mehr funktionieren. Frost gibt aber auch in seinen Tweets an, dass man den Wert DisplayVersion ebenfalls nicht zur Auswertung verwenden soll, da dies ebenfalls nicht dokumentiert sei. Der von Frost gepostete Artikel hier hilft bei der Auswertung per PowerShell nicht weiter, da es im Artikel um eine AnalyticsInfo Class für die Programmiersprache C# geht.
David Segura, der die OSD-Tools pflegt, greift das Problem in obigem Tweet auf und schreibt, dass es mit Get-WindowsImage (DISM) nicht möglich sei, zu bestimmen, ob die Windows 10 Vesion 2004 oder 20H2 oder 21H1 sei. Gibt einigen Mecker im Tweet-Thread von Administratoren, die ihre Scripte umstellen müssen. Beklagt wird, dass die Community keine Tools und Scripte erstellen könne, wenn Microsoft die Betriebssystemerkennung jedes Jahr über einen Haufen wirft. Ist das aus eurer Sicht alles ein Problem und wie löst ihr als Administratoren das Ganze, um die Windows 10-Version festzustellen?
Anzeige
"Die ReleaseID von Windows 10 21H1 liefert den Wert 2009 zurück."
Im Microsoft Konto bleibt es auch nach dem Update bei 2009.
PC mit 20H2: Betriebssystembuild 10.0.19042.985, Version 2009
PC mit 21H1: Betriebssystembuild 10.0.19043.985, Version 2009
Dass die Version gleich bleibt, schadet der Übersicht.
Es ist ein total schlechtes Management,
PaintDesktopVersion funktioniert ja auch nicht mehr richtig!
Was funktioniert nicht mehr? Hab schon was in 2oH1 Paint gekritzelt und hat funktioniert.
die Versionsanzeige auf dem Desktop
https://www.windowspage.de/tipps/021122.html
Windows 10 Pro 21 H1 war bei mir ein einziges Desaster. Update über https://www.microsoft.com/de-de/software-download/windows10
– Firefox konnte nicht mehr ins Internet, Edge letzlich schon (s. u.).
– Windows Update gelang kein Zugriff auf die Microsoftserver
– Edge Chromium startete nur noch mit Fehlermeldungen. Erst nach Neuinstallation arbeitete das Profil wieder klaglos.
Bin wieder auf 20H2 zurück, alles top. Werde bis 21H2 warten.
Bei mir tritt keiner deiner 3 Fehler auf, bisher alles gut.
Für uns ist das jetzt echt mieß. Ich muss alle potentiell betroffenen Skripte prüfen und anpassen. – Dachte eigentlich die 21H1 wird ne kurze und unkomplizierte Sache. :-/
Auf jeden Fall ist das ein Problem, wenn ich keine Möglichkeit habe sinnvoll zu prüfen auf welcher Win10-Version ich bin (bzw. MS da dauernd dran rum bastelt). Es gibt fälle wo man das unterscheiden können muss, um die richtigen Befehle auszuführenden.
Angedeutet hatte sich das ja aber schon früher. Wer die Blogs verfolgt hat, sollte gemerkt haben, dass niergends wo die Zahlenfolge 2105 oder ähnlich genannt wurde. Auch in den RC builds war sie noch auf 2009 stehen geblieben. – Dachte halt bloß das ändern die bestimmt noch.
Dass das Problem besteht weiß ich allerdings seit mitte letzter Woche, wo ich es dann nach dem Upgrade meines privaten PCs verifiziert hatte.
Man könnte von Powershell aus zwar grundsätzlich auch auf Windows-Runtime-Klassen wie AnalyticsInfo zugreifen (vgl. als Beispiel https://devblogs.microsoft.com/oldnewthing/20180110-00/?p=97755 , auch wenn es dort um eine andere Klasse geht); allerdings wird es ziemlich kniffelig, wenn dann nicht mehr nur ein Zugriff auf einfache statische Felder oder synchrone Methoden erfolgt, sondern asynchrone Methoden aufgerufen werden sollen: Beim einfachen Aufruf ohne Await gibt Powershell deren Ergebnisse nur als System.__ComObject zurück, wo die eigentlich interessanten Member fehlen; auch ein Cast in den eigentlich gewollten Rückgabedatentyp ist offenbar nicht möglich: Powershell ist also offenbar ziemlich mies darin, solche COM-Objekte vernünftig so aufzubereiten, dass man hinterher auch was damit anfangen kann. Leider basiert die Windows Runtime ziemlich heftig auf COM…
Es gibt zwar die Möglichkeit, auch in Powershell das aus C# bekannte "Await" zu emulieren, um damit asynchrone Methoden so aufrufen zu können, dass man mit der Rückgabe auch was anfangen kann (vgl. z.B. ); allerdings klappt das offenbar nur, wenn der Rückgabewert der Methode ein Powershell bekannter Typ ist.
Handelt es sich wie bei Windows.System.Profile.AnalyticsInfo.GetSystemPropertiesAsync um eine Methode, bei der der Rückgabetyp gar kein richtiger Typ ist, sondern aus einem Interface besteht (im Beispiel IReadOnlyDictionary), dann beschwert sich Powershell, dass es mit diesem Typ nichts anfangen kann.
Wenn man der Powershell diese Interface-Rückgabetypen nicht doch noch irgendwie beibringen kann (Google liefert da aktuell keine passenden Beispiele), dann dürfte es wohl darauf hinauslaufen, dass man sich mit C# kleine Hilfstools basteln muss, die den jeweiligen API-Aufruf der asynchronen Windows-Runtime-Methode kapseln und als Kommandozeilen-EXE von Powershell-Skripten aus aufgerufen werden.
Was das Deployment natürlich zu einem Alptraum werden lässt: Solange man als einzelner Nerd auf seinem eigenen System vor sich herum werkelt, ist es sicher kein Problem, zu seinem Skript dann auch noch die eine oder andere Hilfs-EXE zu packen. Aber wenn man als Admin seine Skripte auf eine Vielzahl an Rechnern verteilen muss, wo dann gerne mal übereifrige AV-Software lieber zu viel als zu wenig in Quarantäne schickt, dann will man natürlich jede zusätzliche Abhängigkeit möglichst vermeiden: Die Gefahr, dass das Skript ansonsten nicht mehr vernünftig läuft, wird halt zu groß.
Aber selbst wenn man das Deployment irgendwie hinbekommt und ein in C# geschriebenes und als Kommandozeilen-EXE kompiliertes Hilfstool nutzen könnte, würde einem das in diesem Fall längerfristig vermutlich auch nicht wirklich viel nützen: Schließlich heißt es in der im Artikel verlinkten Doku zu GetSystemPropertiesAsync: "Remarks: […] The intention of this method is to use this information only for analytics and not rely on a particular value on the client. Support for these values will change over time." Liest sich, als sei das alles andere als eine stabile API, auf die man sich langfristig verlassen sollte…
Zumal auch nirgendwo richtig beschrieben steht, welche Attribute mit dieser Methode überhaupt abgefragt werden können sollen: "Supported values for the attributeNames parameter are potentially endless. There are many providers that hook in and can expose arbitrary values. There a handful of known attributes that are likely to be supported. In most cases, these are case sensitive: App, AppVer, DeviceFamily, FlightRing, OSVersionFull". Also noch mehr Glücksspiel, was langfristig geht und was nicht.
Aufgefallen ist das nicht erst kürzlich, sondern ein entsprechendes Issue gammelt schon seit 2018 herum, ohne, dass sich seitdem etwas getan hätte (https://github.com/MicrosoftDocs/winrt-api/issues/334 ).
Microsoft hat hier schlicht gepennt und lässt Powershell-Nutzer sprichtwörtlich im Regen stehen. Windows ist halt nach wie vor größtenteils COM und damit C++; alles, was moderner ist, egal ob .NET oder auch Powershell, spielt weiterhin nur die zweite Geige. Ob Project Reunion da spürbare Besserung bringt, ist zwar eine vage Hoffnung, aber alles andere als sicher. Bis dahin käme ich mir als Admin und Powershell-Skriptentwickler jedenfalls ziemlich verarscht vor, um es mal freundlich zu formulieren.
Hallo Philipp.
Ich verstehe das Problem nicht ganz. Die erforderlichen Werte stehen auch in der Registry und können dort problemlos ausgelesen werden. Egal ob per C++, .Net-Sprache (C#, …) oder PowerShell.
– Heiko
Hallo Heiko,
das Problem ist, dass man sich auf das, was in der Registry steht, nicht dauerhaft verlassen kann (vgl. dazu z.B. auch https://devblogs.microsoft.com/oldnewthing/20160308-00/?p=93123 ).
Wenn es im Artikel heißt: "Frost gibt aber auch in seinen Tweets an, dass man den Wert DisplayVersion ebenfalls nicht zur Auswertung verwenden soll, da dies ebenfalls nicht dokumentiert sei.", dann wäre man ja mit dem Klammerbeutel gepudert, wenn man in seinen Skripten den einen undokumentierten Registrywert "ReleaseID" durch einen neuen undokumentierten Registrywert "DisplayVersion" ersetzt: Wer sagt mir denn, wie lange der dann hält und ob nicht mit dem nächsten Versionswechsel dann wieder noch ganz andere neue Registryschlüssel Einzug halten? Soll man dann zukünftig alles halbe Jahr all seine Powershellskripte anpacken und die Methode zum Ermitteln der Versionsnummer mit jeder neuen Version wieder austauschen?
Selbst wenn das immer nur ein einzelner Registry-Key ist, der jeweils geändert werden muss, es macht doch Arbeit. Oder man kapselt die Versionsüberprüfung in separate Funktionen. Dann hat man zwar weniger Stellen, die man im Fall der Fälle ändern müsste, bekommt dafür aber zusätzliche Abhängigkeiten in seine Skripte.
Wenn Microsoft davor warnt, sich auf die Registry zu verlassen und nur garantiert, dass bestimmte API-Aufrufe stabil und zukunftsfähig sind, dann sollte die Verwendung dieser APIs z.B. in Powershell nicht so schwer gemacht werden!
~~~~
Hallo Philipp.
Bei deiner Aussage "Wenn Microsoft davor warnt, sich auf die Registry zu verlassen und nur garantiert, dass bestimmte API-Aufrufe stabil und zukunftsfähig sind, dann sollte die Verwendung dieser APIs z.B. in Powershell nicht so schwer gemacht werden!" gebe ich dir zu 100% recht. Das ist einfach ein Unding.
Bezüglich des Registrywertes sei gesagt, dass ich ganz sicher nicht empfehlen würde den "DisplayVersion"-Wert als Ersatz zu verwenden. Wer weiß, wie lange es den gibt. Ich würde stattdessen aus "CurrentBuild" oder "CurrentBuildNumber" (19043) wechseln. In der Hoffnung, dass sie die nicht auch in einem Jahr abschaffen.
Tendenziell wage ich die Prophezeiung, dass es bald keine Featureupdates, wie wur sie kennen, mehr geben wird. (Wenn man das Experiencepack, die Zurückportierung von Funktionen in der letzten Zeit, die versionsunabhängig neuen GPOs und die Funktionalität der Enablementpackages bedenkt.) – Eben Windows 10 as a Service. Und die Dummen dabei sind dann die Admins, die jede Woche GPOs anpassen und neue Features testen müssen.
– Heiko
Da fehlen einem die Worte. Arbeitet bei MS eigentlich wirklich noch jemand mit dem eigenen OS oder sind sie schon alle auf andere Plattformen ausgewichen ?
Sorry,
ich kann den ganzen Aufschrei nicht wirklich nachvollziehen.
MS hat mehrfach deutlich kommuniziert, dass die Build 21H1 keine neue "Version" ist, sondern nur Features, die bereits in 20H2 vorhanden waren, durch ein kleines "Funktions-Update" freischaltet!
Von daher verstehe ich diese ganze "Entrüstung" grade überhaupt nicht.
Wenn man sich beim Schreiben von Skripten auf die ReleaseID verlässt, sollte man ganz schnell umdenken!
Hier lieber die BuildID abfragen.
Ist ja nicht so schwer, ich frage dies via PS bei den Clients ab.
So mache ich dies bei meinen Scripts im SCCM.
Immerhin habe ich mitlterweile knapp 800 Clients mit 20H1, 20H2 und ein paar mit 21H1 zu verwalten.
Umdenken ist angesagt!
Denke, MS, wird zukünftig nur noch die BuildID´s aktualisieren.
Alles Andere ist Nebensache.
Euch Allen schöne Rest-Pfingsten.
Immer wieder interessant – ich bin ja nur Chronist und Beobachter. In diesem Kontext bist Du der Einzige, der mir mit "nicht wirklich nachvollziehen" aufgefallen. Und ich habe einige Stimmen gesehen. Schlecht von MS kommuniziert, oder lesen die Leute das nicht, was Redmond so schreibt? Kopf kratz.
Leute probieren was aus, stellen fest, dass es aktuell funktioniert und sind dann entrüstet, wenn es das nach einem Update nicht mehr tut.
Aber warum machen die Leute das? Weil sie vielfach keine andere Wahl haben, weil Dinge schlecht oder gar nicht dokumentiert sind oder nur mit COM / C++ vernünftig nutzbar sind, sie aber Visual Basic oder .NET/C# oder Powershell oder was auch immer einsetzen.
Ja, Microsoft warnt davor, dass undokumentierte Dinge sich jederzeit ändern können und garantiert die langfristige Funktionalität nur bei dokumentierten APIs. Aber solange es viel zu viele Bereiche gibt, die anders nicht nutzbar sind, werden Leute auch weiterhin undokumentierte Funktionen nutzen, solange sie funktionieren. Und je länger eine undokumentierte Sache funktioniert hat, desto größer der Aufschrei, wenn sich dann doch was so ändert, dass es dann nicht mehr funktioniert.
Hallo.
Wie Philip schon sagt, wenn's anders nicht geht, bleibt einem nichts anderes Übrig.
Aber wenn's nach MS geht, sind ja eh alle in einer homogenen, problemlos funktionierenden Umgebung, die immer das neuste Windows und die neusten Anwendungen (nicht älter als zwei Tage) nutzt. Da funktioniert dann alles, weil immer die neuesten APIs/Schnittstellen genutzt werden. Da ja nur das aktuellste System im Einsatz ist braucht dann auch kein Admin mehr die Version abzufragen. – Ergo: Problem gelöst.
– Heiko
Hallo Günter, Hallo Lutz.
Ich kann aus meiner Sicht als betroffener (Softwaremanagement, automatisierte Installation von Windows) sagen, dass ich es zwar wie oben beschrieben schon habe kommen sehen. Aber mir fehlte einfach die Zeit mal eben auf Verdacht zu prüfen welche Skripte betroffen sind und angepasst werden müssen.
Zum Thema einfach die Build-ID nehmen: Zum einen geht mir dieses Versionschaos aus Build-ID, Codenamen, Versionsnummer, Marketingversion und Marketingname echt auf die Nerven. (Nicht zu vergessen die Anpassung der Bildnummer beim welchsel von Dev, Beta zu Release und die Chemischen Codenamen für den Kernel oder so.) Und wenn ich jetzt schon wieder auf Deskmodder lesen muss, dass aus der 19043 (21H1) per Skript/Enablementpackage eine 19044 (21H2) gemacht werden kann, bekomme ich echt zu viel. Eigentlich hatte ich erwartet die 21H2 wird ein großes Upgrade mit 20er BuildID oder so. (Was MS davtreibt ist selbst für so manchen Admin nur noch verwirrend!!)
Zum Anderen ist der Wert 2009 oder ähnlich für andere, die nicht so tief in den Bildnummern drin sind, besser verständlich.
Allerdings werde ich natürlich jetzt auch auf die BuildID wechseln. Auch wenn das bei so manchem Skript mit zusätzlichem Aufwand, weil compiliert, verbunden ist.
– Heiko
P. S.: Es wäre aber echt super, wenn MS da mal ein bissel mehr Klarheit rein bringen könnte. Also welche Bezeichnung/Nummer bedeutet was.
Ich nutze scho seit Jahren die Build Nummer. Dies ist wahrscheinlich dem geschuldet das ich mich sehr oft im Exchange Umfeld bewege und dort zählt nichts anderes. Dies funktioniert zuverlässig, bis dato und lässt sich in der Powershell einfach und direkt auslesen.
[System.Environment]::OSVersion.Version.Build
Kann man den bekannten Operatoren verwenden. Ich benutze meist -gt -lt -eq oder -in.
ReleaseID oder DisplayVersion habe ich noch nie benutzt, wie gesagt bin durch den Exchange vorbelastet, dort ist nur die Build relevant.
mfg
Die Package-GUID der System-Komponenten ist aktuell auch eine sehr stabile Referenz. Bevorzuge dennoch auch die Build.
Wobei ich vermute, dass mit fortlaufendem Upgrade des Component-Store weder die GUID der Packages noch die Build zuverlässig sein wird. Wenn der mal fertig entwickelt ist – keine Ahnung warum das seit Vista so lange dauert – dann dürfte es in einer idealen Welt nur noch Komponenten und nicht mehr komplett Windows-Builds geben und dann muss dann eh auf Komponenten-Basis geprüft werden. =)
Die Entwicklung des Komponenten-Stores ist auf alle Fälle sehr interessant. Die Abhängigkeiten untereinander nehmen mit jeder Build ab. Man kann heute schon sehr viele Packages entfernen ohne das es extreme Auswirkungen auf andere hat. Die Kapselung wird also immer besser. Bei Vista endete das noch oft in Blue Screens. Ab 8.1 wurde er langsam brauchbar.
Rein technisch gesehen ist es seit Vista eh ein und derselbe Kernel mit Anpassungen, Verbesserungen und Verschlechterungen. Erst mit den letztes Technical-Previews wurde eine neues OS draus. Wegen der Marketing-Abteilung. W10 ist ja sooooooo neu und so viel besser als 7/8, da passt es nicht nur die stelle nach dem Komma zu ändern. =)
Marketing – GUI-Optik gehört da auch mit rein – und Technik ist nunmal nicht das selbe. ;)
Und doch verstehe ich den Unmut auch. Wozu einen ziemlich spezifischen Parameter einführen um ihn dann sang und klanglos ohne Ankündigen nicht mehr zu pflegen und die sonstiges Benamsung sowie das Marketing dennoch mit dem neuen Parameter zu bewerben. Aber so kann man sagen W10 ist noch von 20, jetzt haben wir W11 :D