Summary: Learn how to use CIM cmdlets for better speed, security, and data return as opposed to the WMI cmdlets in Windows PowerShell.

The other day, Windows PowerShell MVP, Richard Siddaway, posted Should I use CIM or WMI with Windows PowerShell? Today, I would like to continue that discussion a little bit. You should read Richard’s blog post before you read mine today.

In the old days (like way back in Windows PowerShell 1.0), if you wanted to do anything on a remote computer, you were pretty much limited to using WMI—kind of like things were in the VBScript days. Sure, there were some things that you could do, but they all required additional openings in the firewall, and some cases actually starting additional services to make things work. Neither of these solutions were a very secure thing to do on servers or even on workstations for that matter.

Speaking of firewalls, WMI uses DCOM which requires opening lots of ports through the firewall. The good thing was that using the Get-WMIObject Windows PowerShell cmdlet was way better than trying to wrestle with dozens of lines of arcane code ala VBScript. We added a bit to that in Windows PowerShell 2.0.

But now Windows PowerShell 2.0 and Windows PowerShell 1.0 are no longer supported, so it is time to move on. The CIM cmdlets were introduced in Windows PowerShell 3.0. After three versions, it is time to make the transition.

For me there are four big reasons for using the CIM cmdlets over the traditional WMI cmdlets:

1. Speed The cmdlets seem to return information faster than the Get-WMIObject
2. Better output The output is formatted much better, and therefore the returned data is easier to work with.
3. Remoting The CIM cmdlets use WINRM (the same remoting that Windows PowerShell remoting uses), so it is a single port through the firewall, and it is already set up for use in the server environment. On the workstation, it is as simple as typing Enable-PSRemoting to set this up.
4. Tab expansion of WMI class names The Get-CimInstance cmdlet will Tab expand the WMI class name, and that is great for some of those really long WMI class names.

So how difficult is it to make the change? Well, in many cases, it is a simple change of cmdlet name, for example:

• Get-WmiObject win32_bios
• Get-CimInstance Win32_BIOS

Here are the commands and the output from the commands:

Although the Get-CimInstance command is marginally longer than Get-WmiObject, the fact that I can use Tab expansion (for both the cmdlet name and for the WMI class name) makes the amount of typing about 50% less.

Other than that, the output appears to be the same, and both commands work rather quickly. On my system, the Get-CimInstance command comes back four times faster, but they are both sub-second responses, and therefore the results are not very accurate. Here is the output:

In reality, it gets even better, because both cmdlets have great built-in aliases:

• Get-WmiObject is gwmi
• Get-CimInstance is gcim

In this case, both are four letter aliases. Here is the output:

Faster, more secure, better output, and easy migration. What are you waiting for? Start using the CIM cmdlets today.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. Also check out my Microsoft Operations Management Suite Blog. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy