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.

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

~Trevor

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