WMI and CIM seem to cause a LOT of confusion. Its really simple. CIM is an industry standard from DMTF.org. WMI was Microsoft’s implementation of CIM way back in Windows NT days. The complication is that Microsoft had a set of WMI cmdlets in PowerShell v2. In PowerShell v3 they introduced a set of CIM cmdlets that work differently. The bottom line is you should use CIM cmdlets not WMI cmdlets.
Here’s three reasons why you should use CIM cmdlets not WMI cmdlets.
Reason 1: the WMI cmdlets are deprecated and won’t have much if any further work done on them. The WMI help files tell you to use the CIM cmdlets! PowerShell v6 doesn’t have the WMI cmdlets – just the CIM cmdlets.
Reason 2: the CIM cmdlets use WS-MAN for remote access. The WMI cmdlets use DCOM which is blocked by default on Windows firewall. Using the CIM cmdlets makes your remoting easier.
Reason 3: The CIM cmdlets do some extra work for you. For instance finding the time a machine was started:
PS> Get-WmiObject -Class Win32_OperatingSystem | select LastBootUpTime
LastBootUpTime
————–
20171001113546.966894+060
Read it left to right = Year = 2017; Month = 10; day = 01; hour = 11; minute = 35; second = 46.966894 with a +60 minute offset for daylight saving time.
That date format is painful to deal with so you convert it. the nice PowerShell Team added a conversion method for you
PS> Get-WmiObject -Class Win32_OperatingSystem | select @{N=’LastBootUpTime’; E={$_.ConvertToDateTime($_.LastBootUpTime) }}
LastBootUpTime
————–
01/10/2017 11:35:46
It works great but means you have to do more work.
By contrast the CIM cmdlets do the work for you
PS> Get-CimInstance -ClassName Win32_OperatingSystem | select LastBootUpTime
LastBootUpTime
————–
01/10/2017 11:35:46
On a slightly off topic point anyone thinking of attending the PowerShell Summit next April will be aware that we have an Iron Scripter event planned for the last day. IF access to WMI classes is required anyone using the WMI cmdlets instead of the CIM cmdlets will be marked down. You have been warned 