Previous Page
Next Page

Working with Objects and Namespaces

Let's go back to the idea of a namespace introduced earlier in this chapter. You can think of a namespace as a way to organize or collect data related to similar items. Visualize an old-fashioned filing cabinet. Each drawer can represent a particular namespace. Inside this drawer are hanging folders that collect information related to a subset of what the drawer holds. For example, at home in my filing cabinet, I have a drawer reserved for information related to my woodworking tools. Inside this particular drawer are hanging folders with information about my table saw, my planer, my joiner, my dust collector, and so on. In the folder for the table saw is information about the motor, the blades, and the various accessories I purchased for the saw (such as an over-arm blade guard).

The WMI namespace is organized in a similar fashion. The namespaces are the file cabinets. The providers are drawers in the file cabinet. The WMI classes are the folders in the drawers of the file cabinet. The namespaces on a Windows XP computer are seen in Figure 8-2.

Figure 8-2. WMI namespaces on Windows XP


Namespaces contain objects, and these objects contain properties you can manipulate. Let's use a WMI script, ListWMINamespaces.vbs, to illustrate just how the WMI namespace is organized.

ListWMINamespaces.vbs

strComputer = "."

Set objSWbemServices = GetObject("winmgmts:\\" & strComputer & "\root")
Set colNameSpaces = objSwbemServices.InstancesOf("__NAMESPACE")
For Each objNameSpace In colNameSpaces
    WScript.Echo objNameSpace.Name
Next

On a Windows Server 2003 Server, the results would look like the following when running ListWMINamespaces.vbs from CScript:

SECURITY
perfmon
RSOP
Cli
MSCluster
WMI
CIMV2
MicrosoftActiveDirectory
Policy
MicrosoftDNS
MicrosoftNLB
Microsoft
DEFAULT
directory
subscription

So what does all this mean, you ask? It means that on a Windows Server 2003 server there are more than a dozen different namespaces from which you could pull information about the server. Understanding that the different namespaces exist is the first step to being able to navigate in WMI to find the information you need. Often, students and people new to VBScript work on a WMI script to make the script perform a certain action, which is a great way to learn scripting. However, what they often do not know is which namespace they need to connect to so that they can accomplish their task. When I tell them which namespace to work with, they sometimes reply, "It is fine for you to tell me this, but how do I know that the such and such namespace even exists?" By using the ListWMINamespaces.vbs script, you can easily generate a list of namespaces installed on a particular machine, and armed with that information, search on Microsoft Developer Network (MSDN) to see what information it is able to provide.

Let's discuss the preceding script, ListWMINamespaces.vbs, because it's similar to many other WMI scripts. The first line sets the variable strComputer equal to ".". With this construction (period in quotation marks), the script will operate on this computer only. The dot allows the script to run locally on many computers without you needing to define or change the name included in the script.

The next line of the script is used to define the variable objSWbemServices and set it equal to the handle that is returned by using the GetObject method to connect to winmgmts and access the root namespace on the local computer. (The connection string in WMI is sometimes referred to as a moniker. The word moniker comes from old Irish and simply means nickname, or familiar name.) We will discuss the WMI moniker in much more detail in Chapter 9, "WMI Continued." These first two lines of the script can be reused time and again in many WMI scripts. In the third line of the script, you use the Set command to assign colNameSpaces to be equal to a collection represented by the instances of the command that query for the presence of the word__Namespace. The Worker information section of the script simply uses a For Each...Next loop to iterate through the collection of namespaces returned by the query and to echo them out to the screen.

Tip

Although in the ListWMINamespaces.vbs script I used all lowercase in code for the winmgmts name, there really is no requirement for name case with this particular moniker, and in the Microsoft Platform SDK, you will find nearly every possible combination: winmgmts, WinMgmts, WINMGMTS, and I bet even winMgmts.

Keep in mind, however, that name case does matter with some monikers such as "WinNT:", which is used with Active Directory Service Interfaces (ADSI).



Previous Page
Next Page