Posted by: Jerry Lees
Development, Networking, Objects, SQL, VBScript, VBScript Statements
In my last blog entry I explained error control via on error resume next and on error goto 0, there are other ways as well– but for now this should work to get us by.
Next well discuss the Set, GetObject, ExecQuery, and “For Each” commands in the script we worked with, these are on lines 3, 4 and 5 below.
The script was basically (line numbers included as a reference):
1. On Error Resume Next
2. strComputer = “.”
3. Set objWMIService = GetObject(”winmgmts:\\” & strComputer & “\root\cimv2″)
4. Set colItems = objWMIService.ExecQuery(”Select * from Win32_PrinterDriver”,,48)
5. For Each objItem in colItems
6. Wscript.Echo “ConfigFile: ” & objItem.ConfigFile
7. Wscript.Echo “DataFile: ” & objItem.DataFile
8. Wscript.Echo “DriverPath: ” & objItem.DriverPath
9. Wscript.Echo “Name: ” & objItem.Name
10. Wscript.Echo “OEMUrl: ” & objItem.OEMUrl
11. WScript.Echo “_________________” & vbcrlf
The Set command basically tells cscript (or wscript) to assign the value of a variable to be the value of another or creates an object. For all intensive purposed, you can think of an object as a piece of specialized code that is already written that you can call from within your program and use as if it were your own. An object can contain many different types of values, that are referenced by names. These names are either properties (values) or methods (functions to do something and probably give you a value back).
Next, the GetObject command. this is the true heart of our WMI script. In fact, this is where almost all the magic happens! The Getobject comamnd lets us use pieces of code outside of our application as if we had written them on our own– the plus being that we don’t have to write them. In this case it is a WMI call to retrieve an object called “winmgmts:\\.\root\cimv2″.
This object is the root WMI provider that is built into the OS and the period represents the local machine, to get other machine you would specify it’s name instead– this is why we used a variable in the script. (Remember, scripts are powerful when they are reusable for the same situation at a different time, so try to use variables where ever you think a piece of information could change in the furture to allow you to reuse the script.) This WMI provider returns a WMI object that allows us to reference and use the piece of the OS that deals with WMI. Notice we SET the object to the variable objWMIService in the line?
In the next line of code we actually USE it, again another SET command. But this time we use:
… objWMIService.ExecQuery(”Select * from Win32_PrinterDriver”….
The execQuery method is a part of the WMI classes Microsoft has written, and we are simply calling it to preform work. In this case, we are constructing a call to pull back all the printer drivers. The part in the quotes works exactly like a simple SQL statement would operate. Essentially in english it works like– Select all values from Table containing the printer driver information. This “table” contains lots of information on the printer drivers, I’ve only chosen to show a few items from the table, you can get more information here.
After this command completes, colItems will contain a collection of objects that each have properties named the same as the columns in the table. We use the For Each command on line 5 to loop through each member of a collection one at a time and do something with the data (or to the data). The Next command on line 12 loops back to the beginning as long as there is another object after the one currently being used in the collection.
That’s it! It’s pretty easy stuff, once you get the concepts down. Remember, The WMI object is used to execute a query against the WMI database on the system. This query returns a collection of objects containing data for the query you built.
The actual data returned (and names of methods and properties used to get the data) depends on the query you specified. More on that next time!