Class Categories
Microsoft® Windows® 2000 Scripting Guide
« Previous | Next »
As illustrated earlier in Figure 6.2, three general categories of classes are used to construct the CIM: system, core and common, and extension.
System Classes
System classes are classes that support internal WMI configuration and operations, such as namespace configuration, namespace security, provider registration, and event subscriptions and notifications. When browsing the CIM, you can easily identify system classes by the two underscores prefacing each system class name. For example, the __SystemClass, __Provider, and __Win32Provider classes shown in Figure 6.2 are system classes. The __NAMESPACE class examined in the preceding section is another example of a system class.
System classes are either abstract or static. Abstract system classes are templates used to derive (define) other abstract or static system classes. Static system classes define WMI configuration and operational data that is physically stored in the CIM repository. For example, the __Win32Provider system class defines provider registration information stored in the CIM. The CIMOM uses the provider registration information stored in the CIM to map requests for dynamic managed resources to the appropriate provider.
As demonstrated with the __NAMESPACE system class earlier, you can use the same WMI scripting technique to retrieve static instances of system classes stored in the CIM. Listing 6.12, for example, retrieves and displays all of the __Win32Provider instances registered in the root\cimv2 namespace.
Listing 6.12 Retrieving Win32 Providers Registered in the root\cimv2 Namespace
|
|
When the script runs on a Windows 2000 based computer, it returns the following provider names:
CIMWin32 WBEMCORE MS_Power_Management_Event_Provider MS_NT_EVENTLOG_PROVIDER MS_NT_EVENTLOG_EVENT_PROVIDER SECRCW32 MSIProv NT5_GenericPerfProvider_V1 It is unlikely you will use system classes in your WMI scripts, with one exception: WMI monitoring scripts. WMI monitoring scripts are scripts that subscribe to WMI events and provide real-time notification that something of interest has happened with a WMI-managed resource. WMI event subscriptions and notifications are covered later in this chapter.
It is useful to know what system classes are, however, if for no other reason than the fact that tools that browse the CIM repository will return these classes. Understanding the difference between system classes and other classes helps you determine which classes are likely to be useful to you and which ones are not.
Core and Common Classes
The core and common classes serve two roles. First, they represent the abstract classes from which system and application software developers can derive and create technology-specific extension classes. Second, they define resources common to particular management areas, but independent of a particular technology or implementation; in theory, these are resources that any operating system (not just Windows) is likely to support. The DMTF defines and maintains the set of core and common classes, which can be identified by the CIM_ prefix. The four classes prefaced with CIM_ in Figure 6.2 are core and common classes.
Of the approximately 275 core and common classes defined in the root\cimv2 namespace, all are abstract classes, with a few exceptions. You will rarely use core and common classes (classes prefaced with CIM_) in your WMI scripts because you cannot retrieve instances of abstract classes; abstract classes can be used only as a basis for new classes. Because 271 of the core and common classes are abstract, these classes are used primarily by software developers to create technology-specific extension classes. These classes serve as the basis for the scores of Win32_ classes used to manage computers running the Windows operating system.
Just four of the 275 core and common classes are dynamic classes rather than abstract classes. These four classes, which use the Win32 Provider (cimwin32.dll) to retrieve instances of managed resources, are CIM_DataFile, CIM_DirectoryContainsFile, CIM_ProcessExecutable, and CIM_VideoControllerResolution. This means you can actually use these classes to retrieve information about managed resources. For example, this script returns information about all the possible video modes supported by the video controllers on a computer:
strComputer ="."Set objSWbemServices = GetObject("winmgmts:\\"& strComputer &"\root\cimv2") Set colVideoControllers = _ objSWbemServices.InstancesOf("CIM_VideoControllerResolution") For Each objVideoController In colVideoControllers Wscript.Echo objVideoController.HorizontalResolution Wscript.Echo objVideoController.VerticalResolution Wscript.Echo objVideoController.NumberOfColors Wscript.Echo objVideoController.RefreshRate Next
Extension Classes
Extension classes are technology-specific classes created by system and application software developers. The Win32_BaseService, Win32_Service, Win32_SystemServices, and Win32_ComputerSystem classes shown in Figure 6.2 are Microsoft extension classes. Microsoft extension classes in the root\cimv2 namespace can be identified by the Win32_ prefix.
However, you should not conclude that all Microsoft extension class names begin with Win32_; they do not. For example, the StdRegProv class defined in the root\DEFAULT namespace is not prefaced with Win32_, even though the StdRegProv class is a Microsoft extension class for registry management tasks.
In the latest version of WMI, about 463 Win32 extension classes are defined in the root\cimv2 namespace. Of the 463 Win32 classes, 68 are abstract classes and the remaining 395 are dynamic. Extension classes are the primary category of classes you will use in your WMI scripts.
Note
- The class statistics are intended only to illustrate general CIM concepts. Your numbers will differ based on several factors, including Windows version, WMI version, and installed software.
Listing Classes in a Namespace
In addition to listing namespaces, you can write a script to retrieve all of the classes defined within a namespace. Listing 6.13, for example, lists all classes defined in the root\cimv2 namespace. However, unlike the previous scripts that used the SWbemServices InstancesOf method, Listing 6.13 uses a different method, SubclassesOf, which is also provided by the SWbemServices object.
As the name suggests, SubclassesOf returns all of the child (or sub) classes of a specified parent (super) class, or of a specified namespace when no parent class is provided. Like InstancesOf, SubclassesOf returns all of the subclasses in the form of an SWbemObjectSet collection, where each item in the collection is an SWbemObject representing a single class.
A new element is introduced in Listing 6.13: the objClass.Path_.Path property echoed in the body of the For Each loop. Like other For Each loops used in this chapter, this one enumerates each object in the collection returned by the SubclassesOf method. In this case, each object represents a discrete class in the root\cimv2 namespace.
However, in contrast with previous scripts that displayed properties defined by a managed resource blueprint (class definition), Path_ is a property provided by the SWbemObject. To understand this, you have to think about the context in which the script is using SWbemObject. In this case, you are not accessing an instance of a managed resource (for example, a service named Alerter or a process named Notepad.exe). Instead, you are accessing the managed resource class definition.
When you use SWbemObject to access an instance of a managed resource, you are more likely to access properties and methods defined by the blueprint for the managed resource (the class definition). When you use SWbemObject to get detailed class information, such as supported properties, methods, and qualifiers, you use properties and methods provided by SWbemObject itself. Path_ is one such property.
Path_ actually references another WMI scripting library object named SWbemObjectPath, which provides the Path property. The SWbemObjectPath Path property contains the fully qualified path to the class referenced by SWbemObject (objClass in Listing 6.13).
Listing 6.13 Retrieving All Classes Defined in the root\cimv2 Namespace
|
|
Running Listing 6.13 on a Windows 2000-based computer displays a long list of 636 classes, some of which are shown in the following output.
\\ATL-WIN2K-01\ROOT\CIMV2:Win32_NTEventlogFile \\ATL-WIN2K-01\ROOT\CIMV2:Win32_NTLogEvent \\ATL-WIN2K-01\ROOT\CIMV2:Win32_NTLogEventLog \\ATL-WIN2K-01\ROOT\CIMV2:Win32_NTLogEventUser \\ATL-WIN2K-01\ROOT\CIMV2:Win32_NTLogEventComputer \\ATL-WIN2K-01\ROOT\CIMV2:Win32_SID \\ATL-WIN2K-01\ROOT\CIMV2:Win32_AccountSID \\ATL-WIN2K-01\ROOT\CIMV2:Win32_SecuritySetting \\ATL-WIN2K-01\ROOT\CIMV2:Win32_SecuritySettingOfObject \\ATL-WIN2K-01\ROOT\CIMV2:Win32_SecuritySettingOwner \\ATL-WIN2K-01\ROOT\CIMV2:Win32_SecuritySettingGroup \\ATL-WIN2K-01\ROOT\CIMV2:Win32_SecuritySettingAccess \\ATL-WIN2K-01\ROOT\CIMV2:Win32_SecuritySettingAuditing \\ATL-WIN2K-01\ROOT\CIMV2:Win32_Trustee \\ATL-WIN2K-01\ROOT\CIMV2:Win32_ACE \\ATL-WIN2K-01\ROOT\CIMV2:Win32_SecurityDescriptor \\ATL-WIN2K-01\ROOT\CIMV2:Win32_LogicalFileSecuritySetting You can modify Listing 6.13 to list classes in other namespaces by changing the target namespace of the script. You can also use Listing 6.13 in combination with the findstr.exe command to search for classes. The Findstr.exe command is a command-line tool that searches for strings in files.
Suppose, for example, you need to know whether the new Windows XP Win32_TSSessionSetting class is supported on the version of Windows you are running. You can use the following command to determine whether this class exists in the root\cimv2 namespace. This command retrieves the classes found in the root\cimv2 namespace and "pipes" that output to Findstr.exe. Findstr.exe then searches the output and reports any instances of the string "Win32_TSSessionSetting".
cscript GetClasses.vbs |findstr /I "win32_tssessionsetting"
When the command runs on a Windows XP-based computer, the following output is returned:
\\ATL-WINXP-01\ROOT\cimv2:Win32_TSSessionSettingError \\ATL-WINXP-01\ROOT\cimv2:Win32_TSSessionSetting When the command runs on a Windows 2000-based computer, no data is returned. This means that the Win32_TSSessionSetting class is not supported in Windows 2000.
Here are a few additional scenarios you can try.
- List all system classes in the root\cimv2 namespace:
cscript GetClasses.vbs |findstr /I"__" - List all core and common classes in the root\cimv2 namespace:
cscript GetClasses.vbs |findstr /I"CIM_" - List all Win32 extension classes in the root\cimv2 namespace:
cscript GetClasses.vbs |findstr /I"Win32_" - List all classes in the root\cimv2 namespace that contain the string "process":
cscript GetClasses.vbs |findstr /I"process"
 Send us your feedback | « Previous | Next » |
EAN: N/A
Pages: 635