WMI 脚本入门：第三部分

核心和公共类

核心和公共类扮演了两个角色。首先，也是最重要的，它们表现抽象类 — 系统和应用程序软件开发人员（例如 Microsoft 的开发人员）从这些抽象类派生和创建特定技术的扩展类。其次，它们定义了特殊管理区域所共有的，但是不受限于特殊的技术或实现的资源。Distributed Management Task Force (DMTF) 定义并维护这组可以通过 CIM_ 前缀来识别的核心和公共类。图 1 中四个以 CIM_ 开头的类是核心和公共类。

在 root/cimv2 命名空间中定义的大约 275 个核心和公共类中，除了几个例外其余全部都是抽象类。这对您来说意味着什么呢？这意味着您将极少在 WMI 脚本中使用核心和公共类（以 CIM_ 为前缀的类）。为什么？因为您不能检索抽象类的实例，抽象类只能用作新类的基础。因为核心和公共类中的 271 个都是抽象的，所以它们主要被软件开发人员用来创建特定技术扩展类。

那么，例外是什么呢？275 个核心和公共类中的 4 个不是抽象类。它们是使用 Win32 提供程序 (cimwin32.dll) 来检索托管资源实例的动态类。请记录下来，这 4 个动态类是 CIM_DataFile、CIM_DirectoryContainsFile、CIM_ProcessExecutable 和 CIM_VideoControllerResolution。

扩展类

扩展类是由系统和应用程序软件开发人员创建的特定技术类。图 1 中展示的Win32_BaseService、Win32_Service、Win32_SystemServices 和 Win32_ComputerSystem 类是 Microsoft 扩展类。在 root/cimv2 命名空间中的 Microsoft 扩展类可以通过 Win32_ 前缀来识别。虽然这么说，您不应该推断所有的 Microsoft 扩展类名都以 Win32_ 开始，因为并非如此。例如，在 root/DEFAULT 命名空间中定义的 StdRegProv 类不是以 Win32_ 为前缀的，尽管事实上 StdRegProv 类是用于注册表管理任务的 Microsoft 扩展类。在您问之前，我们要先说：不，我们不知道为什么 StdRegProv 类在 root/DEFAULT 命名空间而非 root/cimv2 定义。

当我们编写这篇文章时，在 root/cimv2 命名空间中定义了大约 463 个 Win32 扩展类。在 463 个 Win32 类中，68 个是抽象类而其余 395 个是动态类。这对您来说意味着什么呢？这意味着扩展类是您将要在 WMI 脚本中使用的主要的类类别。

注我们提供的类统计数据是基于测试版的 Windows Server 2003，且只想说明一般的 CIM 概念。基于个别因素，如：Windows 版本、WMI 版本以及安装的软件，您的数字会有所不同。

列出类

此时，我们将要告诉您的事情不应该是一个大的意外。您可以编写一个脚本来检索在一个命名空间中定义的所有类。例如，清单 8 列出了所有在 root/cimv2 命名空间中定义的类。但是，与前面所有使用 SWbemServicesInstancesOf 方法的脚本不同，清单 8 使用一个不同的方法，即 SubclassesOf，它也是由 WMI 脚本库的 SWbemServices 对象提供的。

正如该方法的名称所暗示的，SubclassesOf 返回一个指定父类或命名空间（当没有提供父类的时候）的所有子类。如 InstancesOf，SubclassesOf 返回 SWbemObjectSet 集合中的所有子类，这里该集合中的每个项目都是一个表示单一类的 SWbemObject。

清单 8 中另一个重要的不同是回显在 For Each 循环正文中的 objClass.Path_.Path 属性。让我们查看一下 For Each 循环来了解这究竟是什么。For Each 循环正在枚举由 SWbemServicesSubclassesOf 方法返回的 SWbemObjectSet (colClasses) 集合中的每个 SWbemObject (objClass)。每个 SWbemObject 表示 root/cimv2 命名空间中的一个离散类。

这是有可能产生混淆的部分。与我们前面所有显示由托管资源蓝图（类定义）定义的属性的脚本不同，Path_ 是由 WMI 脚本库的 SWbemObject 提供的属性。要了解这一点，您要考虑使用 SWbemObject 的上下文。您在使用 SWbemObject 来访问托管资源的实例吗？或者您是否在使用 SWbemObject 访问托管资源的类定义？

当您使用 SWbemObject 访问托管资源的实例时，您更有可能使用 SWbemObject 来访问由托管资源蓝图（类定义）定义的属性和方法。当您使用 SWbemObject 来获得详细的类信息 — 如支持的属性、方法和限定符 — 时，您使用由 SWbemObject 自己提供的属性和方法。Path_ 就是一个这样的属性。

Path_ 实际上引用了另一个名为 SWbemObjectPath 的，提供 Path 属性的 WMI 脚本库对象。SWbemObjectPathPath 属性包含了到被 SWbemObject（清单 8 中的 objClass）引用的类的完全限定路径。再一次提醒您，现在不要太专注于脚本对象，因为我们将在第三部分做详细讨论。

清单 8：使用 WMI 和 VBScript 检索所有在 root/cimv2 命名空间中定义的类

strComputer = "."

Set objWMIService = GetObject("winmgmts://" & strComputer & "/root/cimv2")
Set colClasses = objWMIService.SubclassesOf()

For Each objClass In colClasses
WScript.Echo objClass.Path_.Path
Next

在我们的 Windows Server 2003 计算机上运行清单 8 显示出一个有 914 个类的长列表，图 5 展示了它的一部分。



图 5：GetClasses.vbs 输出

当然，您可以通过仅仅改变一下脚本的目标命名空间而轻松地修改清单 8 来列出其他命名空间中的类。您也可以将清单 8 与 findstr.exe 命令结合使用以搜索类。对于不熟悉 findstr.exe 命令的用户：findstr.exe 是一个在文件中搜索字符串的命令行工具。

例如，假设您需要知道您正在运行的 Windows 版本是否支持新的 Windows XP 和 Windows Server 2003的 Win32_TSSessionSetting 类。可以使用下列命令行来确定 Win32_TSSessionSetting 类是否存在于 root/cimv2 命名空间中。

C:/Scripts> cscript GetClasses.vbs |findstr /I "Win32_TSSessionSetting"

这里来尝试几个另外的方案。

•	列出 root/cimv2 命名空间中的所有系统类： C:/Scripts> cscript GetClasses.vbs |findstr /I "__"
•	列出 root/cimv2 命名空间中的所有核心和公共类： C:/Scripts> cscript GetClasses.vbs |findstr /I "CIM_"
•	列出 root/cimv2 命名空间中所有的 Win32 扩展类： C:/Scripts> cscript GetClasses.vbs |findstr /I "Win32_"
•	列出 root/cimv2 命名空间中所有包含字符串“process”的类： C:/Scripts> cscript GetClasses.vbs |findstr /I "process"

CIM 类类型定义

此时应该明显的看出：类是 CIM 储存库的基本构造块。WMI 配置信息和 WMI 托管资源由一个或更多类进行定义。与 Active Directory 架构相似，CIM 类是按等级组织起来的，在这种组织结构中子类从父类继承属性、方法和限定符（目前不必过多考虑属性、方法和限定符，我们将在下一节进行讨论）。例如，Win32_Service 动态类是从 Win32_BaseService 抽象类继承的；而后者是从 CIM_Service 抽象类继承而来的；CIM_Service 抽象类则是从 CIM_LogicalElement 抽象类继承的；而 CIM_LogicalElement 抽象类又是从 CIM_ManagedSystemElement 抽象类继承而来的（如图 1 所示）。是托管资源的类层级中的类的总和最终定义了托管资源。

如前面提到的，有 3 个主要的类类型：抽象、静态和动态。

抽象类

抽象类是用于定义新类的模版。如 Active Directory 架构中的抽象类，CIM 抽象类是作为其他抽象、静态和动态类的基类。每个，嗯，差不多是每个 WMI 托管资源类的定义是从一个或更多抽象类构建（或派生）的。

您可以通过检查类的 Abstract 限定符来识别抽象类。抽象类必须定义 Abstract 限定符并将该 Abstract 限定符的值设置为 true。本文结尾的补充清单 A 示范如何使用 WMI 脚本库来列出所有在 root/cimv2 命名空间中定义的抽象类。

抽象类类型最常用于核心和公共类的定义。抽象类极少在 WMI 脚本中使用，这是因为您不能检索抽象类的实例。

静态类

静态类定义物理存储在 CIM 储存库中的数据。静态类拥有与动态类一样的实例，但是静态类的实例存储在 CIM 储存库中。同样，静态类实例是直接从 CIM 中检索的。它们不使用提供程序。

您可以通过检查类的限定符来识别静态类。但是，不同于通过含有指定的限定符来识别的抽象和动态类类型，静态类是通过不含有 Abstract 和 Dynamic 限定符进行识别的。

静态类类型最常用于系统类的定义。静态类极少在 WMI 脚本中使用。

动态类

动态类是为从提供程序动态检索的 WMI 托管资源建模的类。

您可以通过检查类的 Dynamic 限定符来识别动态类。动态类必须定义 Dynamic 限定符并将 Dynamic 限定符的值设置为 true。本文结尾的补充清单 B 示范如何使用 WMI 脚本库来列出在 root/cimv2 命名空间中定义的所有动态类。

动态类类型最常用于扩展类的定义。动态类是在 WMI 脚本中使用的最常见的类类型。

关联类

第四种类类型称作关联类，也是受支持的。关联类是描述两个类或托管资源之间关系的抽象、静态或动态类。图 1 所示的 Win32_SystemServices 类是一个动态关联类的示例，它描述了计算机与运行在其上的服务之间的关系。

您可以通过检查类的 Association 限定符来识别关联类。抽象、静态或动态关联类必须定义 Association 限定符并将 Association 限定符的值设置为 true。



返回页首

剖析类

冒着听起来像破了纪录的风险，每个通过 WMI 可托管的硬件和软件资源均由一个类进行定义。一个类就是一个离散的 WMI 托管资源的蓝图（或模板），且资源的所有实例都使用这个蓝图。类表示计算机所拥有的东西。因为计算机拥有诸如磁盘、事件日志、文件、文件夹、内存、打印机、进程、处理器、服务等东西，WMI 就有针对磁盘、事件日志、文件、文件夹、内存、打印机、进程、处理器、服务等的类。尽管也有例外（如 __Event 抽象系统类），但脚本中使用的大多数类都能够直接联系到实际的、活动的物质。

这些所谓的蓝图是由属性、方法 和限制符 组成的。在研究属性、方法和限制符之前，让我们简要地讨论一下托管资源类定义的起源。

假设 Microsoft 决定要创建一个新的、系统管理员可以用来管理和监视 Microsoft DNS 服务器的 WMI 提供程序。DNS 提供程序开发小组至少需要创建两个文件：一个提供程序和一个托管对象格式 (MOF) 文件。

提供程序是担当 WMI 基础结构与基础托管资源（在本例中，即 Microsoft DNS 服务器）之间的中间方的动态链接库。提供程序通过调用托管资源的本地 API 来响应 WMI 请求。

MOF 文件包含描述由 DNS 提供程序提供的功能的类定义。MOF 文件利用为通常与 DNS 服务器关联的资源建模的类描述 DNS 提供程序的功能。在 DNS MOF 文件中定义的每个类都定义数据（属性） — 这些数据和属性与指定的 DNS 相关资源、以及在此资源上您可以执行的操作（方法）相关联。

安装 DNS 提供程序之后，DNS 提供程序动态链接库就注册到操作系统和 WMI，而 DNS MOF 文件则经历了一个编译过程，该过程将 DNS 提供程序的类定义加载到 CIM 储存库。此时，DNS 提供程序可以供任何启用 WMI 的使用者（包括脚本）使用。

虽然我们的故事是真实的 — Microsoft 为 Windows Server 2003 开发了一个新的 DNS 提供程序，但所能得到的重要的东西就是托管资源类定义来自 MOF 文件。MOF 文件对 WMI 来说及如同 MIB 文件之于 SNMP.

MOF 文件是基于由 Distributed Management Task Force (DMTF) 创建和维护的 MOF 语言的文本文件。如图 6 所示，每个托管资源的类定义都遵守定义完善的结构和语法。



图 6：托管资源类定义的结构

如图 6 所示，每个托管资源类定义都是由属性、方法 和限定符 组成的。

属性

属性是描述托管资源的名词。类使用属性来描述诸如标识、配置和托管资源状态等。例如，服务有名称、显示名称、描述、启动类型和状态。Win32_Service 类也有相同的东西。

每个属性都有名称、类型和可选的属性限定符。与前面清单 1 中演示的方法一样，将属性名与 WMI 脚本库的 SWbemObject 一起使用来访问托管资源的属性。

方法

方法是在托管资源上执行一个操作的动词。您可以对服务做些什么呢？好，您可以启动它们、停止它们、暂停它们或继续它们。结果是有允许您启动、停止、暂停和继续服务的方法。没有什么不可思议的。

每个方法都有名称、返回类型、可选参数和可选的方法限定符。与属性一样，将方法的名称与 WMI 脚本库的 SWbemObject 结合使用来调用方法。

不是所有的类都定义方法。

限定符

限定符是提供关于类、属性或方法的附加信息到其所应用的事物的形容词。例如，问题“Win32_Service 类的类型是什么？”是由该类的 Dynamic 限定符来回答的。当您开始编写不只是简单地检索信息的 WMI 脚本（例如，修改属性或调用方法）时，限定符变得愈加重要，因为它们定义了您正在更新的属性或正在调用的方法的操作特性。那么限定符提供哪种信息呢？

类限定符

类限定符提供了关于类的操作信息。例如：

•	如您之前了解的，Abstract、Dynamic 和 Association 限定符会告诉您类类型。
•	Provider 限定符告诉您服务这个类的提供程序。例如，Win32_Service 类的 Provider 限定符告诉您这个类使用 CIMWin32 提供程序 (cimwin32.dll)。另一方面，如由 Win32_NTLogEvent 类的 Provider 限定符表明的那样，Win32_NTLogEvent 类使用 MS_NT_EVENTLOG_PROVIDER 提供程序 (ntevt.dll)。
•	Privileges 限定符告诉您要使用这个类所需要的专用特权。例如，Win32_NTLogEvent 类的 Privileges 限定符告诉您在 Win32_NTLogEvent 类可以用来管理安全日志前，SeSecurityPrivilege 必须被启用。

属性限定符

属性限定符提供关于每个属性的信息。例如：

•	CIMType 限定符告诉您属性的数据类型。
•	Read 限定符指出这个属性是可读的。
•	Write 限定符指出您是否可以修改属性的值。例如，我们在清单 4 中修改的 Win32_WMISetting 类的 ASPScriptDefaultNamespace 属性被标记为可写。另一方面，清单 1 中回显的所有 Win32_Service 属性都被定义为只读 — 就是说，它们不定义 Write 限定符。
•	Key 限定符指出该属性是类的密钥，并且用于识别在相同资源集合中的托管资源的唯一实例。

方法限定符

方法限定符提供关于每个方法的信息。例如：

•	Implemented 限定符表明这个方法有一个由提供程序提供的实现。
•	ValueMap 限定符为方法参数或返回类型定义了一组允许的值。
•	Privileges 限定符告诉您调用这个方法所需的专用特权。

注有比这里所提到的更多的限定符。有关完整的列表，参阅 WMI SDK 中的 WMI Qualifiers 主题。

如图 7 所示，您可以使用 WMI 测试器 (wbemtest.exe) 工具来检查类的属性、方法和限定符。当然，您也可以用 WMI 脚本库来检索相同的信息，不久您就会看到。



图 7：使用 WMI 测试器 (wbemtest.exe) 查看 Win32_Service 类