wmi - What Library for Powershell 6 contains the get-wmiobject command?

Question

I am getting the following error upon attempting to use the get-WmiObject command in PowerShell (version 6):

PS C:Userszsofi> Get-WmiObject Win32_product | select name, packagecache

Get-WmiObject : The term 'Get-WmiObject' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ Get-WmiObject Win32_product | select name, packagecache
+ ~~~~~~~~~~~~~
+ CategoryInfo          : ObjectNotFound: (Get-WmiObject:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException`

Answer 1

Gert Jan Kraaijeveld's helpful answer offers a solution for cmdlets that truly are available only in Windows PowerShell (not also in PowerShell [Core] 6+).

In this particular case, however, as Lee_Daily notes in a comment, you can use the
Get-CimInstance cmdlet, which is available in PowerShell [Core] 6+ too:

Get-CimInstance CIM_Product | Select-Object Name, PackageCache

^{Note the CIM_Product class name; CIM classes typically have the same properties as their WMI Win32_* counterparts.}

Why you should generally use the CIM cmdlets instead of the WMI cmdlets:

In PowerShell Core, where all future development effort will go, the CIM cmdlets are your only option, but it is advisable to use the CIM (*-Cim*) cmdlets even in Windows PowerShell, because the WMI (*-Wmi*) cmdlets were deprecated in PowerShell version 3 (released in September 2012), when the CIM cmdlets were introduced; from the Get-CimInstance docs:

Starting in Windows PowerShell 3.0, this cmdlet has been superseded by Get-CimInstance.

As for why the CIM cmdlets are the better choice (quoted from this TechNet blog post):

The big drawback to the WMI cmdlets is that they use DCOM to access remote machines. DCOM isn’t firewall friendly, can be blocked by networking equipment, and gives some arcane errors when things go wrong.

The same blog post also describes how the CIM cmdlets:

• use the same standards-based remoting mechanism as PowerShell itself (WS-Management, via its Windows implementation, WinRM)

  • That is, computers that are set up for PowerShell remoting (see about_Remote_Requirements) implicitly support targeting via the CIM cmdlets.

  • However, you can still use the DCOM protocol (like the WMI cmdlets did) on an opt-in basis, using the New-CimSessionOption cmdlet.

• have support for sessions

• function slightly differently than their obsolete WMI counterparts in that the objects returned do not have methods directly; methods must be called via Invoke-CimMethod.