When managing Windows in the enterprise, it's practically imperative that you take advantage of scripting in order to automate administrative tasks across a large number of client systems.
Previously, I introduced the idea of managing resources with scripts using Windows Management Instrumentation (WMI). I covered using the tool to bind to WMI in a Visual Basic script, and introduced the idea of using WMI classes found in specific namespaces to manage those resources. I used these ideas to show you how to obtain some basic information from a computer, such as a list of services or the name of the video adaptor that is installed.
Now, I'll go into more detail about classes, their properties and methods, and how to locate them. I'll cover using WMI ExecQuery for a slightly more efficient script, and then show you how to use those concepts to actually modify a resource on your computer, rather than merely to obtain information.
Classes, methods, and properties
In order to make efficient use of WMI, you need to know all of the available classes and their properties and methods. One very useful tool for that purpose is the WMI Software Development Kit (SDK), available from Microsoft's Web site. It's actually a set of tools, one of which is the WMI Object Browser. Using this tool, you can browse within a specific WMI namespace and see all of the classes, along with all of the properties and methods available to that class.
Figure A shows what the Object Browser looks like. In the left pane, at the top, note that it is browsing within the root\cimv2 namespace (you can navigate to any namespace). Below that, in the left pane, is a complete list of all classes within the root\cimv2 namespace. The class W32_VideoController has been selected, and in the right pane are three tabs, for properties, methods, and associations. The properties tab has been selected, and all of the properties for the W32_VideoController class are displayed. As you can see, there are quite a few of them. The Object Browser also shows the values of properties for the computer on which it is installed.
What does this tell us? Well, if we wanted to know what kind of video card was installed on a computer, we can see via the Object Browser that we could use the Description property to tell us, with script code like this:
As you look through the various classes, you'll notice that some of the classes begin with CIM and some begin with Win32. CIM stands for Common Information Model, which is an industry standard for representing all of the managed resources in a computer environment. Those classes form the basis for the Microsoft implementation, which are the classes that begin with Win32. Very few of the CIM classes can be used directly within Windows.
Use WMI ExecQuery to find instances
In my previous article, we used the InstancesOf method of GetObject to enumerate all instances of the W32_Service class, as shown here.
However, there's a more efficient way of doing that, using the WMI ExecQuery method. Using ExecQuery, the same script would look like this.
What we have done, after defining the object reference objWMI, is to use the ExecQuery method of that object and assign it to the variable colServices. The col prefix of the variable name indicates that it is a collection of instances. Following the keyword ExecQuery, in parentheses, is the query itself, written in WMI Query Language:
"SELECT * FROM Win32_Service"
The asterisk is a wildcard character indicating "everything." So the query is really saying, "Select everything from the Win32_Service class." If you think this seems somewhat similar to the syntax in the Structured Query Language (SQL), you're exactly right. WMI Query Language is a subset of SQL. This actually has major implications for your WMI scripts. While using the InstancesOf method will only give you all instances of a given object, using the ExecQuery method will allow you to filter your inquiries using the SQL WHERE clause. For example, you could tell it to give you a list only of all Services that are running, ignoring those that are stopped or disabled, as shown in this example.
In this example, we filtered the request using the SQL WHERE clause to show only those services that are running and to ignore the ones that are stopped. Notice that the word Running is enclosed in single quotes. This is because it is contained in a clause that is itself enclosed in double quotes. This will always be the case in WMI scripting when quotes are required.
Use WMI to modify properties
So far, we have only used WMI to give us information, using the wscript.echo method. As useful as that can be in certain instances, WMI is also capable of modifying properties of various classes. For example, let's say we want to change the properties of a given service. There are a number of properties in the service object. The following properties are among the more important ones: :
- DisplayName—the name you see displayed in the Services MMC
- Name—the name that Windows uses to refer to the service
- State—Running or Stopped
- StartMode—Manual, Auto, or Disabled
The Change method for WMI objects can be used to change some of the properties, but not all. In the case of the Service object, the state can be changed not with the Change method, but with the StartService method and the StopService method. Let's say that we want to start the ClipBook service. ClipBook is the DisplayName property, and ClipSrv is the Name property. So our script to start that service might look like this.
On the other hand, we would use different code to disable the ClipBook service. There are eleven Service properties that can be changed using the Change method (we say that these properties are exposed by the Change method.). In using the Change method, we must specify one or more arguments. That is, we must tell it what property or properties to change. However, there is a specific order of arguments for the Change method that must be followed. The property that we want to change in order to disable the ClipBook service is the StartMode property, which is the fifth out of eleven properties. It might look a little strange, but we must leave spaces for the first four properties. Our script would look like this, leaving four spaces and commas in the argument.
On to enterprise management
We could easily argue that it would be simpler to use the MMC GUI for Services to disable one service than to write the script shown above. However, the real power of WMI is in its capability to run on many computers on a network. If we have to disable a service on a thousand computers or more, then without question a WMI script is much easier.
In my next article, I'll discuss creating and deploying WMI scripts in the enterprise, and also address security concerns in WMI.