Several fields are optional in constructing a finely tuned WMI moniker, and there are clearly defined defaults for those optional fields. The defaults are stored in the following registry location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\Scripting.
There are two keys: impersonation level and default namespace. Impersonation level is set to a default of 3, which means that WMI impersonates the logged-on user. The default namespace is set to root\cimv2. In reality, these are pretty good defaults. The default computer is the local machine, so you don’t need to specify the computer name when you’re simply running against the local machine. All this means is that you can simplify your connection string to WMI. A default moniker would just be “winmgmts:\\”. When using the getObject method, you can use the default connection string as follows:
Set objWMIService = GetObject(“winmgmts:\\”)
By using a default moniker and omitting the Header information, you come up with a rather lean script. You can still shorten it even more, as you’ll learn in a bit, but the SmallBIOS.vbs script that follows is a shorter script than the DetermineBIOS.vbs script, which is included on the companion CD-ROM. (The Header information of Small-BIOS.vbs is omitted.)
wmiQuery = “Select * from Win32_BIOS"
Set objWMIService = GetObject(“winmgmts:\\”) Set colItems = objWMIService.ExecQuery(wmiQuery) For Each objItem in colItems
strBIOSVersion = Join(objItem.BIOSVersion, “,”) WScript.Echo “BIOSVersion: “ & strBIOSVersion WScript.Echo “: “ & objItem.caption
WScript.Echo “: “ & objItem.releaseDate Next
Reference Information
The Reference information section of the script comprises three lines. Two of the lines would be consistent among many WMI scripts; the first line in the Reference informa
tion section would change depending upon what query you wanted to run. For the
script to return information about the BIOS on the server, you need to connect to the Win32_BIOS namespace. Your WMI query does nothing fancy—it simply tells WMI that you want to select everything contained in the Win32_ BIOS namespace. The actual query looks like the following:
wmiQuery = “Select * from Win32_BIOS”
The two standard lines in the Reference section are the connection to WMI that uses the GetObject method and the moniker. The short version of the moniker follows:
Set objWMIService = GetObject(“winmgmts:\\”)
Once you have the connection into WMI, you can begin to perform tasks with it. In this case, you want to issue a query and hold the results of that query in a variable called colItems. So you use the following line:
Set colItems = objWMIService.ExecQuery(wmiQuery)
By removing the contents of the WMI query from the line that uses the ExecQuery method, you won’t normally need to change this line of the script. The same is true for the WMI connection string—as long as you are running the script on your local machine and working in the root\cimv2 namespace, you don’t need to modify that line either. Now you can see why in our earlier WMI scripts we specified the computer by using strComputer—it gave us the ability to modify the value of that variable without having to change the rest of the script.
Worker and Output Information
The Worker and Output information section of the script is used to iterate through the collection that is returned by wmiQuery. After that information is loaded into the collec
tion of items (colItems), you use a For Each...Next construction to walk through the col
lection and return the desired information. The code for this section of script follows:
For Each objItem in colItems
strBIOSVersion = Join(objItem.BIOSVersion, “,”) WScript.Echo “BIOSVersion: “ & strBIOSVersion WScript.Echo “: “ & objItem.caption
WScript.Echo “: “ & objItem.releaseDate Next
Each item in the collection is assigned to the variable objItem. In this particular situa
tion, only one BIOS can be queried from Win32_BIOS; however, the nature of WMI is to return single items as a collection. Display the requested information by using the For Each...Next construction. Only one item is in the collection, so you make only one loop through.
Working with Multivalue Properties
Most of the items in the Output information section are obvious to readers at this point.
You use WScript.Echo to output specific values. However, the first item, strBIOS-Version, is unique because you use the VBScript Join method to echo out the informa
tion. (We talk about the Join method in two paragraphs, so for now, let’s think of a Join as a “black box tool.”) This Join is necessary because the data contained in the BIOS-Version property is stored as an array. Recall from earlier chapters that you can think of an array as multiple cells in a spreadsheet, each of which can contain a certain amount of data. The BIOSVersion property of Win32_BIOS contains several fields of information, but you can’t simply do a WScript.Echo objItem.BIOSVersion because WScript won’t know which field you want returned and, consequently, the command would fail. As you learned in your previous discussion of arrays, you could use some-thing like objItem.BIOSVersion(0), and if you knew which field in the array contained the most salient information, this would be a valid approach. However, short of run
ning the script multiple times and changing the array value an arbitrary number of times, you need to take a better approach.
See Also For more information about arrays, refer to Chapter 4, “The Power of Many.”
One cool way to deal with the multivalue property problem is to use the Join tech
nique demonstrated in our earlier script. Let’s see how that works. First you need to use a new variable that will hold the result of your Join statement:
strBIOSVersion = Join(objItem.BIOSVersion, “,”)
The Join statement should be old hat to readers who are familiar with T-SQL. An exe
cuted Join takes two arguments. It’s saying, “I want to join the first thing with the sec
ond thing.” This is actually quite sophisticated. In the preceding Join statement, you join each field from BIOSVersion with a comma. You assign the result of the operation to the variable strBIOSVersion, and you’re ready to echo it out in the next line of your script. Keep in mind that the default query language into WMI is WQL. Now WQL is pronounced “weequil” and SQL is pronounced “seaquil”—they not only sound alike but are alike in that many of the tasks you can perform in SQL can also be accom
plished in WQL. The Join technique is very important, and you’ll use it again when you come across other arrayed properties. Wondering how I knew that BIOSVersion was an array? The Platform SDK told me.
Quick Check
Q. Why do you need a moniker for WMI?
A. The WMI moniker gives you the ability to connect to WMI in an easier fashion.
Q. What construction is required to return property data stored in an array?
A. You need to either specify the element you’re interested in, or simply use a Join function with a comma to give you a string to work with.
Q. What part of the WMI moniker is required?
A. The required part of the WMI moniker is the prefix, WinMgmts:.
Q. What are the two optional parts to the WMI moniker?
A. The two optional parts of the WMI moniker are the security settings and the WMI object path.