When you run winver.exe, you can easily retrieve the full Windows build number. Reading the build number from PowerShell is not as obvious. There is no a built-in cmdlet.
However, it’s easy to create a simple function that does it for you:
$path = 'Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
Get-ItemProperty -Path $path -Name CurrentBuild, UBR, ReleaseID, CompositionEditionID |
Select-Object -Property CurrentBuild, UBR, ReleaseID, CompositionEditionID
The result will look similar to this:
PS C:\> Get-OSInfo
CurrentBuild UBR ReleaseId CompositionEditionID
------------ --- --------- --------------------
15063 1088 1703 Enterprise
ReTweet this Tip!
CIM is only valid if you are in an OS / PS version that has it. There are still lots of folks on legacy OS and PSv2, so no CIM for them. Of course only the know why... 8^}
On the other hand, why use CIM, just use the cmdlet designed specifically for this use case.
Gets edition information about a Windows image. 'docs.microsoft.com/en-us/powershell/module/dism/get-windowsedition?view=win10-ps'
Although, this post a repeat of this Get-WMIObject approach, which of course still works today and keeps one out of the registry for this use case.http://community.idera.com/powershell/powertips/b/tips/posts/finding-out-windows-version
There will always be reasons to use the registry over some cmdlets, Win32_Product is one of those hot topic discussions when using WMI or CIM.'powershell.org/forums/topic/alternatives-to-win32_product''gregramsey.net/2012/02/20/win32_product-is-evil''sdmsoftware.com/group-policy-blog/wmi/why-win32_product-is-bad-news'
So, well, we all need to be careful of blanket statements. I've run into far too many instances where they are just wrong.
Sorry but why not just use CIM and stay out of the registry,,,get-ciminstance -ClassName win32_operatingsystem | select BuildNumber