Prof. Powershell

WMI CIM-plified Part 1: Information Retrieval

In this first part of a six-part series, Jeffrey goes through some of the basics of the CIM standard and its role with the Windows Management Instrumentation.

• By Jeffery Hicks
• 04/16/2013

It is probably a safe bet to say that IT Pros (or at least readers of this column) couldn't do their jobs effectively without Windows Management Instrumentation or WMI. WMI is the secret sauce that makes systems management a much tastier experience. Although, it hasn't always gone down easily. In the days of VBScript, accessing WMI data felt like arcane spell making. Fortunately, PowerShell made it even easier with cmdlets like Get-WMIObject. But even with all this going for us, WMI is a problem.

First, the WMI implementation that most Windows professionals are familiar with is Microsoft's implementation of the Common Information Model (CIM) put forth by the Distributed Management Task Force (DMTF). The implementation is proprietary using the winmgmt service that is ubiquitous now on all Windows platforms. If you only ever have to manage Microsoft platforms this may not necessarily be that big of an issue.

But related to this, is that the protocol Microsoft uses to connect to remote WMI services is DCOM, which has a few issues today. First, it is a proprietary protocol and even more importantly, it doesn't play well in today's cloud-based datacenters. Microsoft's implementation of WMI worked fine when servers were all accessible on a subnet or two without having to worry about jumping through routers and firewalls. But many organizations no longer fit that scenario and using WMI to manage systems requires more than a little hoop jumping.

Today, Microsoft is changing its tune. WMI as we know it is still going to be around and tools like Get-WMIObject aren't going to change. But going forward, Microsoft is going to embrace the use of CIM standards and the WSMAN protocol for managing WMI information. This means that you should be able to manage any device that supports WSMAN 3.0 and CIM, not just servers and desktops. But for now, let's stick to the latter since that is easier for me to write about.

What you need to get started is a desktop running PowerShell 3.0 so you can use the new CIM-based cmdlets which I'm going to cover in the next few lessons. You'll be able to query WMI information from remote systems running PowerShell 2, PowerShell 3 or those that don't have PowerShell installed at all!

We'll wrap up this lesson with some terminology. First, a CIM Class is the name of the WMI class you want to query, such as Win32_OperatingSystem. Really, you should be able to use the same class names you used with WMI. A CIM Instance is an actual representation of the CIM Class. If you ask for instances of Win32_Process you might end up with 78 CIM Instances. Again, very much like Get-WMIObject. Finally, a CIM Session is a remote connection using WSMAN that can be used to query WMI information. There's much more to it than this brief definition but I'll cover that in an upcoming lesson.