Timothy Warner, author of Sams Teach Yourself Windows PowerShell in 24 Hours, differentiates between the often-confused terms WMI and CIM, and explains how best to use these technologies with Windows PowerShell.

Let's imagine that you and I started a business manufacturing and selling network interface cards (NICs). Industry standards would be pretty important to us, right? How could we make it easier for our Ethernet NICs to work natively with systems based on, say, Windows, Linux, and OS X? What about compatibility with different network architectures, protocols, and client/server applications? (Whoa—I'm glad we don't really need to worry about that</em> particular set of problems!)

Windows systems administrators rely on several Distributed Management Task Force</span></u></a> (DMTF) industry standards to make our lives easier. The DMTF is an industry consortium whose membership includes major computer hardware and software manufacturers. Their goal is to agree on standards so their products work together as seamlessly as possible.

In this article, we'll look at how to apply a couple of key DMTF standards to help us be more effective with Windows PowerShell–based systems administration.

Understanding the Relationship Between CIM and WMI</h3>
Common Information Model</span></u></a> (CIM, pronounced sim</em>) is a DMTF specification that describes computer hardware and software components. CIM is part of a larger systems-management framework called Web-Based Enterprise Management</span></u></a> (WBEM).

Every Windows server or client computer has a local CIM repository. As systems administrators, we can tap into that CIM repository to fetch and set properties and take action on the repository data.

Although it's a long-time DMTF member, a while back Microsoft made the ill-advised decision to write its own abstraction layer on top of CIM, called Windows Management Instrumentation</span></u></a> (WMI).

What's confusing to many admins is that in Windows PowerShell v3 and later we can access the CIM repository by using either WMI or CIM calls. One of my goals in this article is to show you the pros and cons of each approach.

Let's begin by running through a simple example to help us visualize the CIM repository. At the moment I'm running a Windows 8.1 computer on which I've installed the free and open-source WMI Explorer</span></u></a> desktop application. Figure 1</span></u></a> shows an annotated user interface.

</span></u></a>Figure 1</span></u></a> WMI Explorer.

We start using WMI Explorer by clicking Connect to load the current computer's CIM repository (annotation A</strong> in
Figure 1</span></u></a>). The namespace is the highest level in the CIM hierarchy. In my experience, we use ROOT\CIMV2</span></tt> almost exclusively for Windows systems management. When we double-click ROOT\CIMV2</span></tt>, after a moment the Classes pane populates (annotation B</strong>). Whereas a namespace defines a group of related classes, the class itself is a blueprint (definition) for a particular hardware or software component.

Type service</strong> in the Quick Filter list and double-click Win32_Service to load all service instances on the local computer (annotation C</strong>). If we think of a class as a generic object blueprint, an instance</em> is an individual copy of that blueprint.

Any Windows computer has many services running, so WMI Explorer displays a mighty big list of service instances. Type spooler</strong> in the Quick Filter list and double-click Win32_Service.Name="Spooler"</span></tt> to load the properties of that instance (annotation D</strong>).

At the bottom of the WMI Explorer window (annotation E</strong>) is the following query:

SELECT * FROM Win32_Service WHERE Name='Spooler'</pre>
Earlier I explained that WMI is Microsoft's implementation of CIM. Microsoft also created the
WMI Query Language</span></u></a> (WQL) to give admins a method that works like Structured Query Language</span></u></a> (SQL) for accessing CIM object data. If you don't yet know SQL, I'd encourage you to learn it, because you can apply that syntax in WQL to query system configuration data.

Finally, spend some time clicking across the six tabs marked at annotation F</strong>: