What is CIM and Why Should I Use It in PowerShell?

Summary: Honorary Scripting Guy and guest blogger, Trevor Sullivan, explores CIM and using it with Windows PowerShell.

Microsoft Scripting Guy, Ed Wilson, is here. Today we have a guest post from Trevor Sullivan. Trevor is an Honorary Scripting Guy and a recognized Microsoft Community Contributor (MCC). To see more of Trevor’s guest posts, see these Hey, Scripting Guy! Blog posts. You can reach Trevor on Twitter (https://twitter.com/pcgeek86) or follow him on his blog, Trevor Sullivan's Tech Room, Minding the gap between administration and development.

Note  This is the first in a series of five posts by Trevor where he will talk specifically about using the CIM cmdlets. Today’s post provides a bit of background about CIM and explains why you will want to use this exciting technology.

Now, here’s Trevor…

For a long time, Microsoft has had a technology called Windows Management Instrumentation (WMI) built into the Windows operating system. WMI is built on the WBEM and CIM standards from the Distributed Management Task Force (DMTF). System information at the hardware and software layers is exposed via a standard interface through WMI. The net result of this is the ability to easily view, and sometimes modify, system information and configuration settings.

As described by the DMTF, “CIM provides a common definition of management information for systems, networks, applications and services, and allows for vendor extensions. CIM's common definitions enable vendors to exchange semantically rich management information between systems throughout the network.”

WMI in early Windows PowerShell

In Windows PowerShell 2.0 and Windows PowerShell 1.0, Microsoft offered interaction with WMI by using built-in cmdlets and type accelerators. The following list contains some of these, although not all of them were available in PowerShell 1.0:

  • Get-WmiObject
  • Invoke-WmiMethod
  • Remove-WmiObject
  • Register-WmiEvent
  • Set-WmiInstance
  • [wmi]
  • [wmiclass]
  • [wmisearcher]

Update for WMI

In Windows PowerShell 4.0 and Windows PowerShell 3.0, Microsoft offered an updated method for interacting with WMI: the CIMCmdlets module for Windows PowerShell. With this new Windows PowerShell module release, Microsoft also released an entirely new Application Programming Interface (API) for Windows called Management Infrastructure (MI).

The new MI API more closely aligns to the DMTF standards, as laid out on MSDN in Why Use MI? MI allows software developers and hardware manufacturers to expose information, and it allows IT professionals to interact with hardware, using standards-based mechanisms. As this technology continues to evolve, I believe that we will see more cross-platform integration between Microsoft Windows and competing platforms.

Note  The Windows PowerShell team blog has a couple of great posts that talk about understanding and using CIM. You probably should start with Introduction to CIM Cmdlets, and you may also want to look at CIM Cmdlets—Some Tips and Tricks. Another good resource is the WMI Cheat Sheet for PowerShell Users.

You can easily find Windows PowerShell cmdlets related to CIM by using the Get-Command cmdlet. The following image illustrates this technique. Note that in the first example, CIM returns nothing as a noun. But in the second command, using CIM* returns the necessary cmdlets.

Image of command output

In my upcoming posts, I will dive deeper into and demonstrate the usage of various commands included in the CIMCmdlets module for Windows PowerShell.


Thank you, Trevor, for taking the time to share with us about this cool and exciting technology. CIM Week will continue tomorrow when we have another guest post from Trevor.

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. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy 

Comments (6)

  1. pamarths says:

    Being a System administrator, I want to know why I should use CIM commands rather than legacy WMI cmdlets. What is the real advantage of using them? Does it improve query processing time? less resource intensive? gives much wider and granular results?
    Looking forward to see this kind of information in your future posts. Please take it as feedback.

    1. KERR says:

      Agree with parmaths – FYI, the benefits of CIM over WMI are:

      – use of WSMAN for remote access – no more DCOM error. You can drop back to DCOM for accessing systems with WSMAN 2 installed
      – use of CIM sessions for accessing multiple machines
      – Get-CIMClass for investigating WMI classes
      – improved way of dealing with WMI associations
      – CIM returns actual dates instead of a bunch of numbers
      – The CimSession allows you to use different credentials and even different authentication methods
      – WMI is processed sequentially whereas CIM can be done in parallel across multiple computers
      – CIM is faster (generally speaking)

  2. Humayun Lone says:

    Instead rambling the very first thing you should have explained is what CIM stands for. too many people are putting garbage on the internet. Articles should concise and to the point – people do not have time to go through rambling.

  3. Trevor Sullivan says:

    Hello Humayun Lone, Good catch! I typically try to spell out acronyms before using them in my writing, but it appears that I forgot to define CIM in this article. Thanks for your feedback! Cheers, Trevor Sullivan

  4. Badumtish says:

    For those, who like me, are wondering what CIM actually means and end up here. CIM stands for "Common Information Model".

Skip to main content