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:\Users\zsofi> 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

As far as I know the only way is the Compatibility module. This is a very neat module by Microsoft that actually makes Windows PS cmdlets available in PS Core by means of implicit remoting to a Windows Powershell 5.1 session on the same machine. https://github.com/PowerShell/WindowsCompatibility

Answer 2

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

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 too (v6+):

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 effort will go, the CIM cmdlets are your only option, but it is also 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)

• have support for sessions

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