WMI is a great tool for managing your Windows machines – I’d argue that PowerShell wouldn’t be as powerful as it is without WMI. If you question that remember that 60% of the additional cmdlets in Windows Server 2012 & 2012 R2 are CDXML based i.e. publish a WMI class as a PowerShell module.
PowerShell 2.0 introduced a suite of WMI cmdlets:
Get-WmiObject
Invoke-WmiMethod
Register-WmiEvent
Remove-WmiObject
Set-WmiInstance
PowerShell 3.0 introduced the CIM cmdlets:
Get-CimAssociatedInstance
Get-CimClass
Get-CimInstance
Get-CimSession
Invoke-CimMethod
New-CimInstance
New-CimSession
New-CimSessionOption
Register-CimIndicationEvent
Remove-CimInstance
Remove-CimSession
Set-CimInstance
So which should you use?
There are a number of differences.
The WMI cmdlets return live objects and the CIM cmdlets return inert objects. This isn’t too much of an issue if you use Invoke-CimMethod. I’d also recommend using Invoke-WMImethod over creating an object and calling the method on that.
The real difference is in the protocol used to access remote machines. The WMI cmdlets use DCOM and the CIM cmdlets default to WSMAN. At this point you may be thinking that you can just use the CIM cmdlets but the remote machine must be running WSMAN 3.0 which comes with PowerShell 3.0 or 4.0.. The CIM cmdlets can’t connect to WSMAN 2.0 which is the PowerShell 2.0 version.
At that point you have to use a CIM session that drops back to DCOM or run Get-WMIobject through a PowerShell remoting session.
Overall the CIM cmdlets win – especially when you consider Get-CimClass and Get-CimAssociatedInstance