The first thing to know about the WMI classes is that there are a ton of them. So many, in fact, that you will almost certainly never need to use most of them. As there are so many classes, finding the class that you want to work with can be interesting. The Get-WMIObject cmdlet has a parameter called –List, which lets you get a list of the classes installed on your computer. Combining this cmdlet with Measure-Object shows that my computer (Windows 7) has over a thousand classes in the default namespace:

You clearly don't want to look through a list of so many items, so you can narrow down the list with the –Class parameter, which accepts wildcards. For instance, to find classes that deal with the processor, you might do this:

The first two in the list (CIM_Processor and Win32_Processor) are the results that are most useful in this case. Depending on what wildcard you use, you may need to look at several classes to find the one that is most appropriate.

If you know the name of a class and what namespace that class belongs to, it is simple to retrieve the class using the Get-WMIObject cmdlet. For instance, there is a class that describes the installed operating system called Win32_OperatingSystem contained in the default (root\CIMV2) namespace. To retrieve this class, either of these command-lines will work:

Get-WMIObject –class Win32_OperatingSystem
Get-WMIObject –class Win32_OperatingSystem –namespace root\CIMV2

The output here is formatted, so you will probably want to use Select-Object –property * to see all the properties. In this case, there are 73 properties, which are too many for a screenshot.

One thing you probably noticed with Win32_OperatingSystem is that only one object (instance) was retrieved by the cmdlet. This makes sense, because there's only one operating system running on a computer at a time (not counting VMs, of course). The other classes might return zero, one, or any number of instances.

A class that should be easy to understand is the Win32_Service class. This class represents the Windows services that are installed in your operating system. You can see the beginning of the formatted output in the following screenshot:

You might ask why we would use WMI to get information about services when we have a perfectly good cmdlet (Get-Service) that is designed to do this. Even though we can see only a few properties of each WMI service object in the preceding output, theres enough information to illustrate an important point. The first object in the output, AdobeARMService, shows six properties. Comparing these properties with the full output of the Get-Service cmdlet reveals that the Name and State properties of the WMI object have analogous properties (Name and Status) in the Get-Service object, but the other four properties (including ProcessID) are missing from Get-Service:

Remember that WMI is a very mature technology that has been in use for over 20 years. As WMI is so well established, most aspects of the Windows ecosystem is covered very well by WMI.

WQL syntax

WQL syntax is very simple to use, and is very similar to SQL. In the WQL filter, you can use the property names of classes, constants, and operators to build the conditions you are looking for. For example, to return only the AdobeARMService instance from the Win32_Service class, you could use a filter of "Name='AdobeARMService'". Note that I have used double quotes around the filter and single quotes around the string value of the Name property. The full Get-WMIObject statement and output looks as follows:

Filters can be more complex as well. Consider the Win32_LogicalDisk class, which contains an instance for each drive on the local computer:

If we wanted to list all the drives that had less than 10GB free and didn't care about the removable, we could use a filter as follows:

 -Filter "DriveType=3 and FreeSpace< 10737418240"

Here, you can see that I have calculated the value of 10GB because WQL doesn't understand units, and also, I have used a variable to hold the filter in order to keep the line shorter.

Tip

Although WQL filters look like SQL syntax, there are crucial differences. You can use comparison operators (=, <>, >, <. <=, >=, LIKE) in the expressions and can link multiple expressions together with AND and OR. You can also group expressions using parentheses. Another important thing to remember is that the WQL strings use backslash as the escape character. For more details, including how to use the WQL queries, refer to the About_WQL help topic.

When dealing with WMI, there are two kinds of methods that come into play, instance methods and class methods. Calling the WMI instance methods is similar to calling methods on any PowerShell object, that is, using dot-notation. For instance, WMI objects from the Win32_Service class have a StartService() method defined in them, which we can verify using Get-Member:

To call this method, we can store the instance in a variable and use the variable to call the method. Note that the method outputs a structured result type. The ReturnValue property of the output gives us the outcome of the operation. A value of zero means success. An example of a successful method invocation can be seen in the following screenshot:

PowerShell 3.0 introduced the Common Information Model (CIM) cmdlets to access WMI repositories. The WMI cmdlets are still present, but they have been superseded by the CIM cmdlets that can perform all the same functions. From a functional level, the CIM cmdlets are similar to the WMI cmdlets. The main difference is the communication that the cmdlets perform with the target computer. The WMI cmdlets use the DCOM protocol, which is a pretty standard thing to do on Windows systems, especially 20 years ago when WMI was created. Unfortunately, DCOM is kind of a mess from a firewall standpoint, as it uses a range of ports (over 16000 ports by default) that need to be open in order to function. In a data center situation, requiring this many ports to be opened in the firewalls is something that network engineers frown upon.

The CIM cmdlets, by default, use Web Services for Management (WS-MAN), the protocol that PowerShell remoting is based on. WS-MAN uses a single port, and has a number of other properties that make it ideal from a networking standpoint. Finally, the CIM cmdlets support sessions, which allow you to reuse a connection to a computer or a set of computers for multiple requests, which can dramatically reduce the network traffic for some workloads.

If you're just looking at the WMI repositories on the local box like we've done in the examples of this chapter, both sets of cmdlets will work fine. If you're looking at the WMI classes across multiple computers in a network, you will need to consider firewall rules and whether WS-MAN is enabled. These are beyond the scope of Module 1, please see Module 2 and 3 for more, but are good to make a note of.

The CIM cmdlets

The two main CIM cmdlets that you will use are Get-CIMClass and Get-CIMInstance. Although Get-WMIObject is used to retrieve both the WMI classes (with –List) and WMI instances (without –List), these roles are carried out by separate CIM cmdlets. Using Get-CIMClass is virtually identical to using Get-WMIObject with the -List switch. We can recreate the processor example from earlier in the chapter with Get-CIMClass as follows:

Retrieving instances is done, of course, with Get-CIMInstance. Filters work exactly like they do with Get-WMIObject. Also, the objects output by these two cmdlets are the same, so working with the results will be exactly the same.

One of the drawbacks of using the WMI or CIM cmdlets is that you don't get to use parameters that are specific to the properties of the WMI class you are dealing with. For instance, when we looked at the Win32_LogicalDisk instances, it would have been really nice to have parameters such as DriveType or Name to easily filter the output without having to use a WQL filter statement. In PowerShell 3.0, the concept of a CDXML module was introduced. CDXML modules allow you to create an XML description of the cmdlets and the associated parameters dealing with a WMI class, and the PowerShell engine creates the cmdlets for you when you import the module.

The CDXML modules have two main advantages, as follows:

In PowerShell 4.0, the majority of modules on a server will be CDXML modules, because they are easy to write.

In this chapter, we have taken a quick look at the basics of using the WMI and CIM cmdlets. It should be clear that there is a lot of information in the WMI repository, and these cmdlets are essential tools for PowerShell scripters. With the introduction of CDXML modules, we're also seeing more cmdlets that are customized to specific WMI classes, making their usage even easier.

In the final chapter, we will look at administering Internet Information Services (IIS).