Tags: PowerShell, Windows 10
Die Versionierung von Windows 10 ist komplizierter geworden, weil man neben der Major Version auch die Build Number und die Release ID kennen sollte, um die Fähigkeiten des Systems zu beurteilen. Diese Informationen muss man aus verschiedenen Quellen zusammenklauben.
Besonders konsistent war die Nummerierung von Windows nie, weil die internen Versionen schon lange nicht mehr mit der Bezeichnung des Betriebssystems übereinstimmen. So trägt Windows 7 intern die Versionsnummer 6.1 und bei Windows 8.1 lautet sie 6.3. Zumindest in dieser Hinsicht sorgt Windows 10 für Ordnung, indem diese beiden Werte auf den gleichen Stand bringt.
Major Version alleine nicht ausreichend
Allerdings ist diese Harmonisierung nur von bedingtem Nutzen, weil Windows 10 voraussichtlich das letzte Major Release sein soll. Es wird durch zwei bis drei Upgrades pro Jahr laufend aktualisiert und behält dabei seine Versionsnummer bei. Wenn man wissen muss, mit welchen Eigenschaften man bei einer Installation des OS rechnen kann, dann sind andere Angaben nicht minder wichtig.
Schon in früheren Ausführungen von Windows konnte man relativ leicht die Build Number ermitteln, und das ist auch weiterhin der Fall. So spuckt sie etwa der ver-Befehl von cmd.exe aus, und zwar als die vier Stellen nach dem letzten Punkt.
Angesichts der vielen Builds von Windows 10, die durch Insider Previews und verschiedene Service Branches in Umlauf sind, wird man mit dieser Information alleine nicht viel anfangen können.
Release ermitteln
Von größerer Bedeutung dürfte in den meisten Fällen eher sein, ob beispielsweise das November-Upgrade 1511 (Threshold 2) auf einem Rechner installiert ist. Diese Auskunft erteilt aber weder ver noch die WMI-Klasse Win32_OperatingSystem:
Get-CimInstance Win32_OperatingSystem -Property *
Keines der zahlreiche Attribute dieser Klasse gibt Aufschluss auf das installierte Release. Schlauer ist dagegen das Dienstprogramm winver.exe, das neben der Build Number auch 1511 als Version ausgibt. Da es sich bei winver aber um ein grafisches Tool handelt, kann man diese Information nicht nutzen, wenn man sie etwa in einer PowerShell-Abfrage benötigt.
Als Ausweg bleibt hier nur das Auslesen des entsprechenden Schlüssels ReleaseId in der Registrierdatenbank:
(Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\" -Name ReleaseID).ReleaseId
Die analoge Operation mit reg.exe würde so aussehen:
reg.exe query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v ReleaseID
Current Branch for Business erkennen
Neben der ReleaseId ist oft noch bedeutsam, welchem Service Branch eine Installation von Windows angehört. Während der Current Branch die aktuellesten Upgrades schon kurz nach ihrem Erscheinen verteilt, erhält die Enterprise Edition im Rahmen des Long Term Service Branch (LTSB) überhaupt keine neuen Features, sondern nur Updates.
Auch diese Informationen finden sich nicht an einer zentralen Stelle, sondern müssen erst ermittelt werden. So liegt ein Upgrade-Rhythmus nach dem Current Branch for Business vor, wenn es sich um die Editionen Pro oder Enterprise handelt und zusätzlich die Option Upgrades zurückstellen oder die entsprechende Einstellung in den Gruppenrichtlinien aktiviert wurde.
Diese Bedingungen ließen sich mit einem PowerShell-Ausdruck wie diesem abfragen:
(Get-CimInstance Win32_OperatingSystem -Property *).Caption -notlike "*home*" -and
(((Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings" -ErrorAction Ignore -Name DeferUpgrade).DeferUpgrade -eq 1) -or
(Get-ItemProperty HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate -ErrorAction Ignore -name DeferUpgrade).DeferUpgrade -eq 1)
Hier müssen gleich zwei verschiedene Werte für DeferUpgrade geprüft werden, weil die App Einstellungen diesen an einem anderen Ort speichert als das GPO. Ist das Ergebnis der gesamten Bedingung TRUE, dann ist Current Branch for Business konfiguriert.
LTSB feststellen
Die Enterprise Edition kann alternativ zum Current Brach bzw. dem Current Branch for Business auch dem LTSM unterliegen. Dieser wird aber nicht vom Admin konfiguriert, sondern ist ein Feature einer eigenen Ausführung (Microsoft führt sie als eigene SKU). Diese kann man über WMI erfragen:
Get-WmiObject win32_operatingsystem | select OperatingSystemSKU | fl
Ist das Ergebnis 125, dann liegt die Enterprise Edition LTSB vor.
Täglich Know-how für IT-Pros mit unserem Newsletter
Verwandte Beiträge
- Semi-Annual Channel (Targeted): Service-Branch für Windows 10 konfigurieren und auslesen
- Windows 10 1803 kommt mit cURL und tar
- OpenSSH unter Windows 10 und Server 2016 aktivieren, PowerShell-Remoting nutzen
- Get-ComputerInfo: Systeminformationen auslesen mit PowerShell
- Convert-WindowsImage: Windows automatisch in einer VHDX installieren
Weitere Links
2 Kommentare
Die Abfrage für CB/CBB funktioniert bei mir unter Win10-1607 korrekt, unter Win10-1709 aber nicht: "Get-ItemProperty : Die Eigenschaft DeferUpgrade ist im Pfad HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings nicht vorhanden".
Unklar: Evtl. fehlt bei der ersten RegKey-Abfrage nur "-ErrorAction Ignore"?
Meine Suche nach 'powershell check "Semi-Annual Channel"' u.ä. hat zwar jede Menge Treffer geliefert aber bisher keine Lösung des Problems ...
Man kann im ersten Teil der Abfrage natürlich die Fehlermeldung unterdrücken (habe ich jetzt eingefügt für Versionen <= 1607).
In der 1709 haben sich die Namen der Schlüssel aber geändert, so dass die Abfrage ohnehin nicht mehr funktioniert. Sie befinden sich aber noch an der gleichen Stelle in der Registry. Ich habe dazu hier ein Update veröffentlicht.