WMI 脚本入门：第二部分 (MSDN)

WMI 脚本入门：第二部分

发布日期 : 09/06/2004 | 更新日期 : 09/06/2004

Greg Stemp、Dean Tsaltas、Bob Wells
、Microsoft Corporation、My.Settings、My.User 和 My.WebServices

Ethan Wilansky
网络设计小组

摘要： Scripting Guys 继续他们对编写 WMI 脚本的讨论，这次集中在 CIM 储存库和 CIM 类以帮助您巧用 WMI 脚本的全部强大功能。

如果要建造一所房子，您需要知道如何阅读和解释建筑图。如果要制造一个电子器具，您需要知道如何阅读和解释示意图。那么如果要编写一个 WMI 脚本，您猜到了，需要知道如何解释 WMI 对于管理的蓝图 — CIM 储存库。CIM 储存库，在 WMI SDK 中也称为 WMI 储存库，是存储建模 WMI 托管资源的类定义的 WMI 架构。

为了强调 CIM 和 CIM 类的重要性，仔细考虑在 WMI 脚本入门：第一部分 中展示的 4 个脚本，以及下面的清单 1 和清单 2。清单 1 是来自第一部分的服务脚本的一个略有增强的版本，而清单2 是使用 Win32_OperatingSystem 类的相同脚本的另一个变体。

注 如果您对清单 1 和 2 有疑惑，我们建议您阅读（或视具体情况重读）本系列内容的第一部分。

清单 1 ：使用 WMI 和 VBScript 检索服务信息

strComputer = "."   ' Dot (.) equals local computer in WMI



Set objWMIService = GetObject("winmgmts:\\" & strComputer)

Set colServices = objWMIService.InstancesOf("Win32_Service")



For Each objService In colServices

    WScript.Echo "Name:           " & objService.Name        & vbCrLf & _

                 "Display Name:   " & objService.DisplayName & vbCrLf & _

                 "   Description: " & objService.Description & vbCrLf & _

                 "   Path Name:   " & objService.PathName    & vbCrLf & _

                 "   Start Mode:  " & objService.StartMode   & vbCrLf & _

                 "   State:       " & objService.State       & vbCrLf

Next

清单 2 ：使用 WMI 和 VBScript 检索操作系统信息

strComputer = "."



Set objWMIService = GetObject("winmgmts:\\" & strComputer)

Set colOperatingSystems = objWMIService.InstancesOf("Win32_OperatingSystem")



For Each objOperatingSystem In colOperatingSystems

    Wscript.Echo "Name:            " & objOperatingSystem.Name   & vbCrLf & _

        "Caption:         " & objOperatingSystem.Caption         & vbCrLf & _

        "CurrentTimeZone: " & objOperatingSystem.CurrentTimeZone & vbCrLf & _

        "LastBootUpTime:  " & objOperatingSystem.LastBootUpTime  & vbCrLf & _

        "LocalDateTime:   " & objOperatingSystem.LocalDateTime   & vbCrLf & _

        "Locale:          " & objOperatingSystem.Locale          & vbCrLf & _

        "Manufacturer:    " & objOperatingSystem.Manufacturer    & vbCrLf & _

        "OSType:          " & objOperatingSystem. OSType         & vbCrLf & _

        "Version:         " & objOperatingSystem.Version         & vbCrLf & _

        "Service Pack:    " & objOperatingSystem.ServicePackMajorVersion  & _

                "." & objOperatingSystem.ServicePackMinorVersion & vbCrLf & _

        "Windows Directory: " & objOperatingSystem.WindowsDirectory

Next

在本系列文章第一部分中的每个脚本以及本文的清单 1 和 2 中，唯一有区别的特征是标识 WMI 托管资源的类名和每个类属性的子集。相同脚本模板可以用来检索全部的物理内存、服务、事件日志记录、进程和操作系统信息，这一事实证明了 CIM 类在 WMI 脚本中扮演的重要角色。一旦知道如何编写一个脚本来管理一类 WMI 托管资源，您就可以对其他托管资源使用相同的基本技术。

当然，知道一个托管资源的类名以及该类的相应属性只是本文的一部分。在您能够巧用 WMI 脚本的全部强大功能之前，您需要对 CIM 储存库和 CIM 类的结构了解得再多一些。为什么呢？我们将给出两个重要的理由。

1. 了解如何浏览 CIM 将帮助您确定通过 WMI 公开的计算机和软件资源。

2. 了解如何解释托管资源的蓝图（类定义），将帮助您理解可以在托管资源上执行的任务。

无论使用什么 WMI 工具，这两点都成立，无论使用 WMI 脚本库、WMI 命令行工具 (wmic.exe)，或者企业管理应用程序，您都需要知道如何浏览 CIM 并解释 CIM 类。

一个不那么明显但是同样重要的学习 CIM 的原因是，CIM 是 WMI 托管资源的极好的文档资源。没错，如果需要关于 WMI 类的详细信息，可以使用 WMI SDK。但是，如果不 需要关于 WMI 类的详细信息呢？假设您只想知道正在运行的 Microsoft Windows 版本是否支持一个指定的类、方法或属性。那么，看看目标计算机的 CIM 吧。

例如，我们经常被问及“为什么 TechNet 的脚本中心 里的‘加入计算机到域’脚本在 Windows 2000 中不能用？”回答是，因为在 Windows 2000 中的 Win32_ComputerSystem 类（它是在脚本中使用的 WMI 类）不支持 JoinDomainOrWorkGroup 方法。在内置于 Windows XP 和 Windows Server 2003 的 WMI 版本中，JoinDomainOrWorkGroup 方法被添加到 Win32_ComputerSystem 类中。

那么如何了解或学习它呢？一种方法是使用我们在第一部分中列出的 WMI 工具集合。另一种更强大、灵活的方法是使用 WMI 脚本库。关于 WMI，真正酷的事情之一是，您可以使用 WMI 脚本库来学习 WMI。没错，用编写 WMI 脚本来检索 WMI 托管资源相同的方法，您也可以编写 WMI 脚本来学习关于 WMI 本身的各种有趣的详细信息。您可以编写 WMI 脚本来列出 CIM 储存库中所有的命名空间和类。您可以编写脚本来列出一台启用 WMI 的计算机上安装的所有提供程序。您甚至可以编写 WMI 脚本来检索托管资源类定义。

无论选择使用现有的工具或者创建自己的工具，您都需要对 CIM 储存库的结构有一个基本的了解。所以，让我们从第一部分停止的地方开始，仔细了解一下 WMI 的管理蓝图 — CIM 储存库。在整个讨论中，我们将使用 WMI 脚本库为您说明如何检索 WMI 配置信息和托管资源类定义。

管理蓝图

在第一部分中，我们说到 WMI 的基本思路是 — 来自不同来源的配置和管理信息能够用一种架构统一地表示，而 CIM 储存库就是针对 WMI 的架构。可以将架构想象为蓝图或者代表现实世界中存在的某事物的模型。就好像建筑图构建物理结构的模型（例如，房子），WMI CIM 构建构成计算机的硬件、操作系统和软件的模型。CIM 是 WMI 的数据模型。

注 虽然 CIM 储存库能够存储一些数据（而且它确实存储了），但是它的主要目的是构建管理环境的模型。CIM 不是为存储它所定义的大量管理信息而设计的。相反，大部分数据是根据需要动态地从 WMI 提供程序检索的。一个例外是 WMI 操作数据。WMI 操作数据（例如，命名空间信息、提供程序注册信息、托管资源类定义和永久事件订阅）存储于 CIM 储存库中。

图 1 提供了一个 CIM 储存库的内部结构和组织的概念化视图。如图 1 所示，CIM 使用类来创建数据模型。不可否认，CIM 包含的类远超过关系图中展示的 11 个 — 上次我们在 Windows Server 2003 上统计大约有 5000 个。要了解的重要内容是，CIM 储存库是定义 WMI 托管环境和每个通过 WMI 公开的可托管资源的类存储。

图 1 中展示三个重要的 CIM 概念，您需要了解它们以成功地浏览并解释 WMI 架构。

1. CIM 储存库被划分为多个命名空间。

2. 每个命名空间包含下面一个或多个类的组：系统类、核心和公共类和/或扩展类。

3. 有三种主要的类类型：抽象、静态和动态。抽象类 是用于派生（定义）新的抽象和非抽象类的模板，不能用于检索托管资源的实例。静态类 定义物理存储在 CIM 储存库中的数据 — 最常见的是 WMI 配置和操作数据。动态类 是为从提供程序中动态检索的 WMI 托管资源建模的类。称作关联类的第四种类类型，也是受支持的。关联类 是一个抽象、静态或动态的类，描述两个类或托管资源之间的关系。暂时别太担心关于 CIM 类类型问题，我们很快就会在一个更实际的环境中讨论 CIM 类类型。

让我们更详细地看看每一个 CIM 概念。

图 1 ： CIM 储存库的结构化视图 — WMI 架构

注 CIM 物理驻留在 Windows XP 和 Windows Server 2003 中名为 %SystemRoot%\system32\wbem\Repository\FS\objects.data 的文件内。Windows 2000 和 Windows NT 4.0 Service Pack 4 将 CIM 存储在 %SystemRoot%\system32\wbem\Repository\cim.rep 中。而在 Windows Millennium Edition (Me)、Windows 98 和 Windows 95 OSR 2.5 操作系统中，CIM 存储在 %windir%\system\wbem\Repository\cim.rep 中。

命名空间定义

CIM 类被组织到命名空间中。命名空间是 CIM 使用的分区机制，控制托管资源类定义的范围和可见性。CIM 中的每个命名空间包含一个表现特定技术或管理区域的相关类的逻辑组。命名空间中的所有类必须有一个唯一的类名，一个命名空间中的类不能从另一个命名空间中的类派生，这就是为什么您将发现在多个命名空间中定义的相同的系统、核心以及公共类。

多数为 Windows 托管资源建模的类驻留在 root/cimv2 命名空间中。不过，按照图 1 中的建议，root\cimv2 不是您唯一需要注意的命名空间。例如，事件日志、性能计数器、Windows 安装程序和 Win32 提供程序都将它们的托管资源类定义存储在 root\cimv2 命名空间中。另一方面，注册表提供程序将其类定义存储在 root\DEFAULT 命名空间中。另外，新的 Windows Server 2003 DNS 提供程序将其托管资源类定义存储在 root\MicrosoftDNS 命名空间中。

命名空间使用

那么，命名空间如何影响您的 WMI 脚本呢？每个 WMI 脚本都作为初始化连接步骤（上个月我们简要地讨论过）的一部分连接到一个命名空间，如下所示：

strComputer = "."

Set wbemServices = GetObject("winmgmts:\\" & strComputer)

如上，如果没有指定目标命名空间，则脚本连接到由下列注册表设置识别的命名空间：

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\Scripting\Default 命名空间

默认的命名空间设置是 WMI 脚本，%PATH% 环境变量的默认设置是操作系统。当您通过命令提示提交了一个命令而没有指定命令的完全限定路径时，操作系统使用 %PATH% 环境变量来定位该命令的可执行文件。如果操作系统不能找到这个文件，就会产生错误。

同样，当您在 WMI 脚本中检索一个托管资源时，如果没有指定命名空间，CIMOM（WMI 服务）就在默认的命名空间寻找该托管资源的蓝图（类定义）。如果 CIMOM 在默认的命名空间中找不到托管资源类定义，就会产生一个 WBEM_E_INVALID_CLASS (0x80041010) 错误。

注 不要将默认的命名空间设置与 root\DEFAULT 命名空间相混淆。它们是不相关的，除非您将 root\DEFAULT 设置为您的默认命名空间。

命名空间 root\cimv2 被初始配置为脚本默认的命名空间；但是，默认的脚本命名空间可以很容易地进行更改。因此，您应该始终 在您的 WMI 脚本中标识一个托管资源的命名空间，而不是采用默认设置。如果上个月就遵照了我们自己的建议，所有 4 个清单（以及本文的清单 1 和 2）中的连接步骤就应该编写如下：

strComputer = "."

Set wbemServices = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

将目标命名空间添加到连接字符串会告诉 CIMOM 在 CIM 中到哪里去寻找托管资源类定义，很像完全限定路径告诉操作系统到底去哪里寻找一个文件。当您指定了目标命名空间，默认的命名空间就不使用了。

管理脚本的默认命名空间

您可以像清单 3 和清单 4中展示的那样，将 WMI 脚本库与 Win32_WMISetting 类结合使用来读取和更改脚本的默认命名空间。Win32_WMISetting 是一个为 WMI 服务的操作参数建模的动态类。可写的属性表示脚本的默认命名空间是 ASPScriptDefaultNamespace 。

清单 3 使用了相同的 3 个 WMI 脚本编写步骤 — 连接、检索和显示 — 我们一直在使用的步骤，不过有一个明显的改变。正如前面建议的，我们在传递到 Microsoft Visual Basic Scripting Edition (VBScript) 的 GetObject 函数的 WMI 连接字符串中，指定 Win32_WMISetting 类的完全限定命名空间。那么，这里您会认为 Microsoft 没有遵循他们自己的建议。我们不但在清单 3 中遵循我们命名空间的建议，而且从此以后我们将限定命名空间。是的，如果想在您的 WMI 脚本中避免无效的类错误，它就是那么的重要。

清单 3 ：为使用 WMI 和 VBScript ，检索脚本的默认命名空间

strComputer = "."



Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colWMISettings = objWMIService.InstancesOf("Win32_WMISetting")



For Each objWMISetting in colWMISettings

    Wscript.Echo "Default namespace for scripting: " & _

                 objWMISetting.ASPScriptDefaultNamespace 

Next

要运行清单 3 中的示例脚本，将这段脚本复制并粘贴到您最喜欢的文本编辑器中，保存脚本（扩展名为 .vbs），然后如图 2 所示运行脚本。您应该看到本地计算机的默认命名空间回显到控制台中。

图 2 ： GetDefaultNamespace.vbs 输出

要设置脚本的默认命名空间，执行与清单 3 中的相同脚本编写步骤，但要做一个重要的更改 — 好吧，如果您在数脚本行数的话就算两个。您应该使用 SWbemObject 来设置后面跟有调用 SWbemObject 的 Put_ 方法的属性来将更改提交到 WMI 托管资源，而不要使用 WMI 脚本库的 SWbemObject 从 WMI 托管资源的实例中读取属性。设置和提交操作在清单 4 中的 For Each 循环内执行，因为 SWbemServices InstancesOf 方法总是返回一个 SWbemObjectSet 集合，即便是只有一个目标 WMI 托管资源实例，如 Win32_WMISetting 。

清单 4 ：用 WMI 和 VBScript 设置脚本的默认命名空间

strComputer = "."



Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colWMISettings = objWMIService.InstancesOf("Win32_WMISetting")



For Each objWMISetting in colWMISettings

        objWMISetting.ASPScriptDefaultNamespace = "root\cimv2"

        objWMISetting.Put_

Next

不要太专注于 WMI 脚本库的结构，因为我们将在本系列的第三部分中详细说明 WMI 脚本库。现在，让我们把注意力转回到 CIM。

列出命名空间

到目前为止，我们已经用相同的 WMI 脚本技术来检索动态的 WMI 托管资源的实例。例如，在第一部分中，我们使用相同的脚本模板来检索物理内存、服务、事件日志记录和进程。在第二部分中，我们检索服务、操作系统信息和脚本的默认命名空间。这表明，您可以使用相同的 WMI 脚本技术来从 CIM 中检索命名空间信息。象在托管资源脚本中的情况一样，您需要对脚本做的唯一更改就是目标类名。

命名空间信息作为 __NAMESPACE 类的一个静态实例存储在 CIM 中。__NAMESPACE 类是我们前面简要定义的静态类类型的示例。不同于从提供程序按需检索的动态 WMI 托管资源，静态类实例存储在 CIM 中，且无需使用WMI 提供程序而直接从 CIM 中检索。清单 5 使用 __NAMESPACE 类来检索并回显所有直接在根命名空间下的命名空间。

清单 5 ：使用 WMI 和 VBScript 检索 CIM 命名空间

strComputer = "."



Set objServices = GetObject("winmgmts:\\" & strComputer & "\root")

Set colNameSpaces = objServices.InstancesOf("__NAMESPACE")



For Each objNameSpace In colNameSpaces

    WScript.Echo objNameSpace.Name

Next

图 3 显示在一台 Windows Server 2003 计算机上运行清单 5 的结果。命名空间列表会根据安装在目标计算机上不同版本的 Windows 和 WMI 而变化。

图 3 ： GetNamespaces.vbs 输出

如您可能已经注意到的，清单 5 不提供目标计算机上所有可用的命名空间的完整描述。它只检索并显示在单一的、指定命名空间下的命名空间。为了在本地或远程的启用 WMI 的计算机上回显所有命名空间，您需要修改清单 5 来递归地连接到并枚举每个命名空间。幸运的是，这不想您想象中的那么难 — 尤其像清单 6 中展示的那样，有我们为您做这件事的时候。

将清单 5 更改到清单 6 中所示的递归命名空间脚本，主要包括实现子例程内的原始脚本正文，以及提供一个机制来调用从 CIM 检索的每个命名空间实例的子例程。清单 6 通过执行下列步骤完成了这个任务：

1. 清单 6 从用目标计算机的名称初始化 strComputer 开始。WMI 中的单点 (“.”) 表示本地计算机。您可以将分配给 strComputer 的值更改为在您有管理控制权的域中的任何启用 WMI 的计算机。

2. 脚本调用递归子例程 (EnumNameSpaces)，然后传递给子例程一个标识初始化命名空间连接到“根”的字符串。

3. EnumNameSpaces 子例程的正文除了一个重要的改变外，与清单 5 是一样的。让我们逐步研究子例程。

   1. EnumNameSpaces 从回显子例程单一参数 strNameSpace 的值开始。strNameSpace 标识了每次子例程被调用时在连接字符串中使用的命名空间。

   2. 在 VBScript 中使用 GetObject 函数，子例程连接到由子例程的 strNameSpace 参数标识的命名空间。

   3. 在建立到目标计算机的 WMI 服务和命名空间的连接后，子例程立即在由 strNameSpace 引用的命名空间下检索所有命名空间实例

   4. 使用 For Each 循环，子例程立即枚举在当前连接的命名空间下的命名空间实例。但是，并不是简单地回显子命名空间的名字，每个子命名空间的名称与传递到 EnumNameSpaces 子例程的新调用中的当前命名空间连接。重复这些子例程步骤，直至枚举了所有的命名空间实例。

清单 6 ：使用 WMI 和 VBScript 检索所有 CIM 命名空间

strComputer = "."



Call EnumNameSpaces("root")



Sub EnumNameSpaces(strNameSpace)



  WScript.Echo strNameSpace



  Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\" & strNameSpace)

  Set colNameSpaces = objWMIService.InstancesOf("__NAMESPACE")



  For Each objNameSpace In colNameSpaces

    Call EnumNameSpaces(strNameSpace & "\" & objNameSpace.Name)

  Next



End Sub

图 4 展示了在同一台 Windows Server 2003 计算机上运行清单 6 的结果。

图 4 ： GetAllNamespaces.vbs 输出

定义类的分类

如前面图 1 中所示，有 3 个通用的类的分类用于构造 CIM：系统、核心与公共，以及扩展。

系统类

系统类是支持内部 WMI 配置和操作（例如，命名空间配置、命名空间安全性、提供程序注册以及事件订阅和通知）的类。浏览 CIM 时，您可以通过前缀在每个系统类名前的两条下划线轻易地识别出系统类。例如，图 1 中展示的 __SystemClass 、__Provider 和 __Win32Provider 类都是系统类。在上一节中，我们研究的 __NAMESPACE 类是另一个系统类的示例。

系统类可以是抽象的或静态的。抽象系统类是用于派生其他抽象或静态系统类的模板。静态系统类定义物理存储在 CIM 储存库中的 WMI 配置和操作数据。例如，__Win32Provider 系统类定义存储在 CIM 中的提供程序注册信息。CIMOM（WMI 服务）使用存储在 CIM 中的提供程序注册信息，将动态托管资源的请求映射到相应的提供程序。

正如我们之前用 __NAMESPACE 系统类进行的演示，您可以使用相同的 WMI 脚本技术来检索存储在 CIM 中的系统类的静态实例。例如，清单 7 检索并显示所有在 root\cimv2 命名空间中注册的 __Win32Provider 实例。

清单 7 ：使用 WMI 和 VBScript 检索在 root\cimv2 命名空间中注册的 Win32 提供程序

strComputer = "."



Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colWin32Providers = objWMIService.InstancesOf("__Win32Provider")



For Each objWin32Provider In colWin32Providers

    WScript.Echo objWin32Provider.Name

Next

除非您在写一本关于 WMI 的书，否则您不太可能会在 WMI 脚本中用到系统类。有一个例外是 WMI 监视脚本。WMI 监视脚本是订阅 WMI 事件的脚本。（事件是关心的事物已经变更为一个 WMI 托管资源的实时通知。）我们会在未来的专栏中讨论 WMI 事件订阅和通知。

注 对于那些急不可耐的人，三个最常见的 WMI __Event 系统类是：__InstanceCreationEvent 、__InstanceModificationEvent 和 __InstanceDeletionEvent 。虽然我们还是不会在这里讨论它们，但是您可以在 TechNet 脚本中心的监视 一节中找到示范如何使用这些系统类的示例监视脚本。

核心和公共类

核心和公共类扮演了两个角色。首先，也是最重要的，它们表现抽象类 — 系统和应用程序软件开发人员（例如 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 命名空间中定义的类。但是，与前面所有使用 SWbemServices InstancesOf 方法的脚本不同，清单 8 使用一个不同的方法，即 SubclassesOf ，它也是由 WMI 脚本库的 SWbemServices 对象提供的。

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

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

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

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

Path_ 实际上引用了另一个名为 SWbemObjectPath 的，提供 Path 属性的 WMI 脚本库对象。SWbemObjectPath Path 属性包含了到被 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 类

比较类与托管资源

大部分 WMI 属性和方法是合理命名的。例如，如图 8 所示，如果您将由 Win32_Service 类定义的属性和方法与服务的属性对话框相比，就不难推断出 Win32_Service.Name 、Win32_Service.DisplayName 或 Win32_Service.Descritpion 可能会包含什么。

图 8 ：服务属性对话框与 Win32_Service 类属性及方法

那么我们为什么要关心所有这些内容？因为类决定了您能够（或不能）用 WMI做什么。如果有一个服务的类，您就可以管理服务；如果没有，您就不能这样做。属性和方法是很重要的，这是因为 WMI 的版本在操作系统间是有区别的。Windows XP 中的 Win32_ComputerSystem 类有很多新的属性和方法，而它们在 Windows 2000 中的 Win32_ComputerSystem 类中是没有的。您必须知道 WMI 的详细信息，因为不同于 ADSI，为了让工作顺利进行，WMI 属性和方法必须可用于目标计算机。

如何确定一台远程 Windows 计算机是否支持某个属性或方法？请检查类定义。

检索类定义

与 WMI 中所有东西一样，有无数方法可以检索托管资源的类定义。好吧，也许我们有点夸张了，但是也足以说，有许多为每个用户界面首选项提供解决方案的方法。如果您想要检索文本文件，只需分割 MOF 文件。如果您更喜欢命令行，就使用 WMI 命令行工具 wmic.exe（仅限 Windows XP）。如果您乐于将时间花在图形化工具上，就使用 WMI 测试器 (wbemtest.exe) 或 CIM Studio。或者如果您喜欢我们，就使用 WMI 脚本库。

使用 WMI 脚本库，您可以通过三种不同的方法检索托管资源类定义。

1. 您可以使用 SWbemObject Qualifiers_ 、Properties_ 和 Methods_ 属性检索类信息。

2. 您可以使用 SWbemObject GetObjectText_ 方法来检索以 MOF 语法格式化的类定义。

3. 您可以使用 SWbemObjectEx GetText_ 方法来检索以 XML 格式化的类定义（仅限 Windows XP 和 Windows Server 2003）。

让我们简要地看看每个脚本方案，就此结束今天的内容。

使用 SWbemObject Properties_、Methods_ 和 Qualifiers_

清单 9、10 和 11 演示了如何使用 WMI 脚本库的 SWbemObject 的 Properties_ 、Methods_ 和 Qualifiers_ 属性来检索关于 Win32_Service 类的信息。我们将研究清单 9，然后指出清单 10 和清单 11 中的不同之处，因为三个脚本使用了相同的基本方法。

清单 9 从初始化三个变量开始，它们是：strComputer、strNameSpace 和 strClass 分配给 strComputer 的值是启用了 WMI 的目标计算机。分配给 strNameSpace 的值是要连接到的命名空间。分配给 strClass 的值是在目标命名空间中的类的名称，此命名空间的属性将被检索和显示。将这三个值分开到多个变量中会使其他计算机、命名空间和类对脚本的重新使用变得简单。事实上，您可以用 Windows 脚本宿主 (WSH) 参数集合轻松地将清单 9 转换到命令行脚本。

接下来，这个脚本使用 VBScript 的 GetObject 函数连接到目标计算机上的 WMI 服务。注意传递到 GetObject 的连接字符串有什么不同？除了指定目标命名空间之外，类名也要进行指定，这对 GetObject 和 WMI 脚本库返回的内容有深远影响。如在我们前面的所有脚本，GetObject 返回一个对表示目标类的 SWbemObject 的引用，而不是返回对 SWbemServices 对象的引用。为什么？答案在于对象路径 。虽然我们在第三部分中会详细讨论对象路径，但是这里我们还是给您一个概要的解释来帮助您理解清单 9 到清单 11（以及补充清单 C）中到底在进行些什么。

每个 WMI 类和每个 WMI 托管资源实例都有一个对象路径 。将对象路径理解为一个文件的完全限定路径的 WMI 版本。每个文件都有一个完全限定路径，它由设备名称，后跟 0 或更多目录名称，再加上文件名组成。同样，每个类和托管资源也都有一个对象路径，它由启用了 WMI 的计算机名称，后跟 CIM 命名空间，后跟托管资源类名，后跟类的 key 属性以及 key 属性的值组成，如下所示。（注意，方括号只为了分清一个对象路径的四个许可部分，它们并不是对象路径的一部分。）

[\\ComputerName][\Namespace][:ClassName][.KeyProperty='Value']

当您在传递到 GetObject 的连接字符串中使用全部或部分的对象路径时（顺便说一下，这就是我们一直在做的），您使用的对象路径确定了由 GetObject 和 WMI 脚本库返回的引用类型。例如，如果只包含了对象路径的计算机名称部分，您就会获得一个连接到默认命名空间的 SWbemServices 对象引用。如果包含了计算机名称和/或命名空间，您也会获得对 SWbemServices 对象的引用。如果包含了计算机名称、命名空间和类名，您将会获得对表示这个类的 SWbemObject 的引用。如果包含了所有四个部分，您将会获得表示由类、密钥和值识别的托管资源实例的 SWbemObject 。再次提醒，我们会在本系列的第三部分更详细地讨论对象路径。现在，了解清单 9 中的 objClass 是对表示 Win32_Service 类的 SWbemObject 的引用。

脚本的剩余部分相当简明易懂。在回显一个简单的、标识其属性将被显示的类名的标题后，脚本使用从 GetObject 返回的 SWbemObject 引用 (objClass) 来访问 SWbemObject Properties_ 属性 (objClass.Properties_ )。SWbemObject Properties_ 属性引用了一个 SWbemPropertySet ，它是对这个类的属性的集合。SWbemPropertySet 集合中的每个属性都是一个 SWbemProperty (objClassProperty) 对象，我们用其读取并回显每个属性的名称。

概括地说，For Each 循环枚举了类的 SWbemPropertySet 集合（通过 SWbemObject Properties_ 属性）并回显SWbemPropertySet 集合中每个 SWbemProperty 的 Name 属性。

清单 9 ：使用 SWbemObject Properties_ 检索 Win32_Service 属性

strComputer = "."

strNameSpace = "root\cimv2"

strClass = "Win32_Service"



Set objClass = GetObject("winmgmts:\\" & strComputer & _

                         "\" & strNameSpace & ":" & strClass)



WScript.Echo strClass & " Class Properties"

WScript.Echo "------------------------------"



For Each objClassProperty In objClass.Properties_

    WScript.Echo objClassProperty.Name

Next

图 9 显示由 Win32_Service 类定义（或继承）的 25 个属性的名称。

图 9 ： GetProperties.vbs 输出

除了一个显著的例外，清单 10 与清单 9 是相同的。For Each 循环枚举类的 SWbemMethodSet 集合（通过 SWbemObject Methods_ 属性），并回显 SWbemMethodSet 集合中每个 SWbemMethod (objClassMethod) 的 Name 属性。

清单 10 ：使用 SWbemObject Methods_ 检索 Win32_Service 方法

strComputer = "."

strNameSpace = "root\cimv2"

strClass = "Win32_Service"



Set objClass = GetObject("winmgmts:\\" & strComputer & _

                         "\" & strNameSpace & ":" & strClass)



WScript.Echo strClass & " Class Methods"

WScript.Echo "---------------------------"



For Each objClassMethod In objClass.Methods_

    WScript.Echo objClassMethod.Name

Next

图 10 显示由 Win32_Service 类定义（或继承）的 10 个方法的名称。

图 10 ： GetMethods.vbs 输出

除了三点例外，清单 11 与清单 9 和 清单10 相同。

1. For Each 循环枚举类的 SWbemQualifierSet 集合（通过 SWbemObject Qualifiers_ 属性），并回显 SWbemQualifierSet 集合中每个 SWbemQualifier (objClassQualifier) 的 Name 属性。

2. 因为类限定符是类定义的一部分而且限定符有值，清单 11 也检索并回显 SWbemQualifierSet 集合中每个 SWbemQualifier (objClassQualifier) 的 Value 属性。

3. 因为一个限定符可以有多个存储在数组中的值，清单 11 必须在读取限定符的值前说明此点。如果不这么做，如果脚本试图将一个基于数组的限定符作为标量变量来读取，将会导致运行时错误。Win32_NTLogEvent 类的 Privileges 限定符是一个基于数组的限定符实例。

清单 11 ：使用 SWbemObject Qualifiers_ 检索 Win32_Service 类限定符

strComputer = "."

strNameSpace = "root\cimv2"

strClass = "Win32_Service"



Set objClass = GetObject("winmgmts:\\" & strComputer & _

                         "\" & strNameSpace & ":" & strClass)



WScript.Echo strClass & " Class Qualifiers"

WScript.Echo "------------------------------"



For Each objClassQualifier In objClass.Qualifiers_

    If VarType(objClassQualifier.Value) = (vbVariant + vbArray) Then

        strQualifier = objClassQualifier.Name & " = " & _

                       Join(objClassQualifier.Value, ",")

    Else

        strQualifier = objClassQualifier.Name & " = " & _

                       objClassQualifier.Value

    End If

    WScript.Echo strQualifier

    strQualifier = ""

Next

图 11 显示由 Win32_Service 类定义（或继承）的 5 个类限定符的名称和值。

图 11 ： GetClassQualifiers.vbs 输出

如您可能已经注意到的，清单 9 和清单 10 无法显示属性和方法限定符。说实话，这是故意让脚本保持在一个容易理解的大小。好消息是，在本专栏的结尾我们已经加入了完整的类限定符、属性、属性限定符、方法和方法限定符脚本（见补充清单 C）。欢迎参阅。

万一这不是很明显，您可以把清单 9、10、11 与清单 6（GetAllNamespaces.vbs 脚本）和清单 8（GetClasses.vbs 脚本）组合在一起来检索在 CIM 中定义的每个类的属性、方法和限定符。在使用所产生的带有 findstr.exe 命令的脚本，您会得到一个解决方案来搜索在 CIM 中定义的任何类、属性、方法或限定符。

使用 SWbemObject GetObjectText_

在前面我们说过，您可以直接从 MOF 文件（包含类的定义）中检索管理资源类定义。例如，如果您想要查找 Win32_Service 类，可以查看 %SystemRoot%\system32\wbem\cimwin32.mof 文件。但是，直接使用 MOF 文件是有代价的。您必须检查托管资源的类层次结构中的每个类，以获得完整的托管资源蓝图。

比如说，您想要查找 Win32_Service 。您就不得不检查 Win32_Service 类层次结构中所有的 5 个类，以获得完整的蓝图，如图 1 所示，。如果您使用 WMI 测试器 (wbemtest.exe) 的 Show MOF 按钮（见图 7），也是同样。获得类的 MOF 表示形式的较简单方法是使用 WMI 脚本库的 SWbemObject GetObjectText_ 方法，如清单 12 中演示的。

与清单 9 到 11 不同，清单 12 使用 SWbemServices Get 方法来检索类，而不使用 GetObject 。必须使用 SWbemServices Get 方法，这样才能启用 wbemFlagUseAmendedQuailifiers 标志。启用 wbemFlagUseAmendedQuailifiers 标志，告诉 WMI 返回整个托管资源蓝图（类定义）而不仅仅是本地的定义。

使用 wbemFlagUseAmendedQualifiers 标记还有第二个好处。您也取回了类描述，以及对每个类的属性、方法和限定符的描述。类、属性、方法和限定符描述通常在一个本地化目的、单独的 MOF 文件中定义。例如，Win32_Service 类的中性语言部分是在 cimwin32.mof 中定义的。Win32_Service 类的特定语言部分，包括描述信息，是在 cimwin32.mfl 中定义的。特定语言的（或本地化的） MOF 文件通常带有一个 .mfl（而非 .mof）扩展名。

SWbemServices Get 方法返回对表示目标类的 SWbemObject (objClass) 的引用，它用于调用 SWbemObject GetObjectText_ 方法。GetObjectText_ 方法返回该类的 MOF 表示形式。如果我们使用了 GetObjectText_ 而没有启用 wbemFlagUseAmendedQuailifiers 标记，这个方法将只返回那些由 Win32_Service 定义的属性、方法和限定符，继承的属性和方法会被省略。

图 12 ：使用 SWbemObject GetObjectText_ 来检索 Win32_Service 类的 MOF 表现形式

strComputer = "."

strNameSpace = "root\cimv2"

strClass = "Win32_Service"



Const wbemFlagUseAmendedQualifiers = &h20000





Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\" & strNameSpace)

Set objClass = objWMIService.Get(strClass, wbemFlagUseAmendedQualifiers)

strMOF = objClass.GetObjectText_



WScript.Echo strMOF

不过，对于使用 GetObjectText_ 有一个限定：没有关于在包含在由该方法返回的 MOF 语法中的继承限定符的信息。当 Key 限定符在一个父类的属性中定义时，如果您想要使用 GetObjectText_ 来确定一个类的 Key 属性，这可能会带来问题。

使用 SWbemObjectEx GetText_

Windows XP 和 Windows Server 2003 都包含一个名为 GetText_ 的新方法，它可以用于检索托管资源类定义的 XML 表现形式。

除了一个明显的例外，使用 GetText_ 与使用 GetObjectText_ 类似：传递到 GetText_ 方法的三个参数。

第一个参数是必需的，它标识所产生的 XML 格式。它目前可以是作为由 WMI WbemObjectTextFormatEnum 定义的两个值中的一个：wbemObjectTextFormatCIMDTD20 （值：1）或 wbemObjectTextFormatWMIDTD20 （值：2）。值 2 (wbemObjectTextFormatWMIDTD20 ) 告诉 GetText_ 根据 Distributed Management Task Force CIM 文档类型定义 (DTD) 2.0 版本的扩展 WMI 版本格式化所产生的 XML。

第二个参数是可选的，并且目前是为操作标记保留的。它必须被设置为 0（零）。

第三个参数 colNamedValueSet（也是可选的），是一个为 GetText_ 提供特殊说明的 SWbemNamedValueSet 集合。这里，我们让 GetText_ 进行：

• 检索并编码所有属性和方法，不仅仅是本地定义的属性和方法。

• 包含所产生的 XML 中的类限定符、属性限定符和方法限定符。

• 包含所产生的 XML 中的系统属性。

• 包含对所有属性和方法的类起源。

清单 13 ：使用 SWbemObjectEx GetText_ 来检索 Win32_Service 类的 XML 表现形式（仅限 Windows XP 和 Windows .NET ）

strComputer = "."

strNameSpace = "root\cimv2"

strClass = "Win32_Service"



Const wbemFlagUseAmendedQualifiers = &h20000



Const wbemObjectTextFormatWMIDTD20 = 2



Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\" & strNameSpace)

Set objClass = objWMIService.Get(strClass, wbemFlagUseAmendedQualifiers)



Set colNamedValueSet = CreateObject("Wbemscripting.SWbemNamedValueSet")

colNamedValueSet.Add "LocalOnly", False

colNamedValueSet.Add "IncludeQualifiers", True

colNamedValueSet.Add "ExcludeSystemProperties", False

colNamedValueSet.Add "IncludeClassOrigin", True



strXML = objClass.GetText_(wbemObjectTextFormatWMIDTD20, 0, colNamedValueSet)



WScript.Echo strXML

为了成功运行清单 13，将脚本复制并粘贴到您最常用的文本编辑器中，保存脚本（扩展名为 .vbs，例如：GetXML.vbs），然后使用下面列出的命令行运行脚本。

C:\Scripts> cscript //nologo GetXML.vbs >Win32_Service.xml

图 12 显示所生成的 XML 文件，Win32_Service.xml，使用 Microsoft Internet Explorer。

图 12 ： GetXML.vbs 输出

返回页首

就到这里吧

如果对 WMI 有任何疑惑、困难或不知所措，那可能是在处理由 WMI 公布的大量数据。我们愿意认为，我们已经为您装备了有效地寻找并解释 WMI 托管资源类定义所必需的知识和工具。当然，对于这一点您是最好的裁判，所以请尽量让我们知道我们是否以及有哪些不足。枯燥的内容结束了，准备在我们投入到 WMI 脚本库的详细信息时在第三部分玩得开心点吧。哦，不管怎么样，随意打发剩下的时间吧。

等一下！在您打包走人之前，还有最后一个要注意的地方：WMI 开发小组让我们告诉您，以前只能随 WMI SDK 使用的 WMI 工具 ，现在已经进行了更新。更新的工具（包括 WMI CIM Studio、WMI 事件注册、WMI 事件查看器 和 WMI 对象浏览器），现在都与 Windows XP 和 Windows Server 2003 以及 Windows 2000 兼容。此外，更新的工具不包含 WMI SDK，这意味着现在您可以安装这些工具而不必安装整个 WMI SDK。这难道不是非常酷么？

返回页首

补充脚本

清单 A ：列出在 root\cimv2 命名空间中定义的抽象类类型

strComputer = "."



Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colClasses = objWMIService.SubclassesOf()



For Each objClass in colClasses

    For Each objClassQualifier In objClass.Qualifiers_

        If LCase(objClassQualifier.Name) = "abstract" Then

            WScript.Echo objClass.Path_.Class   & ": " & _

                         objClassQualifier.Name & "="  & _

                         objClassQualifier.Value

        End If

    Next

Next

清单 B：列出在 root\cimv2 命名空间中定义的动态类类型

strComputer = "."



Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colClasses = objWMIService.SubclassesOf()



For Each objClass in colClasses

    For Each objClassQualifier In objClass.Qualifiers_

        If LCase(objClassQualifier.Name) = "dynamic" Then

            WScript.Echo objClass.Path_.Class   & ": " & _

                         objClassQualifier.Name & "="  & _

                         objClassQualifier.Value

        End If

    Next

Next

列表 C ：使用 SWbemObject Qualifiers_ 、 Properties_ 和 Methods_ 检索类限定符、属性、属性限定符、方法和方法限定符

strComputer = "."

strNameSpace = "root\cimv2"

strClass = "Win32_Service"



Set objClass = GetObject("winmgmts:\\" & strComputer & _

                         "\" & strNameSpace & ":" & strClass)



WScript.Echo strClass & " Class Qualifiers"

WScript.Echo "------------------------------"

i = 1

For Each objClassQualifier In objClass.Qualifiers_

    If VarType(objClassQualifier.Value) = (vbVariant + vbArray) Then

        strQualifier = i & ". " & objClassQualifier.Name & " = " & _

                                  Join(objClassQualifier.Value, ",")

    Else

        strQualifier = i & ". " & objClassQualifier.Name & " = " & _

                                  objClassQualifier.Value

    End If

    WScript.Echo strQualifier

    strQualifier = ""

    i = i + 1

Next



WScript.Echo

WScript.Echo strClass & " Class Properties and Property Qualifiers"

WScript.Echo "------------------------------------------------------"

i = 1 : j = 1

For Each objClassProperty In objClass.Properties_

    WScript.Echo i & ". " & objClassProperty.Name

    For Each objPropertyQualifier In objClassProperty.Qualifiers_

        If VarType(objPropertyQualifier.Value) = (vbVariant + vbArray) Then

            strQualifier = i & "." & j & ". " & _

                           objPropertyQualifier.Name & " = " & _

                           Join(objPropertyQualifier.Value, ",")

        Else

            strQualifier = i & "." & j & ". " & _

                           objPropertyQualifier.Name & " = " & _

                           objPropertyQualifier.Value

        End If

        WScript.Echo strQualifier

        strQualifier = ""

        j = j + 1

    Next

    WScript.Echo

    i = i + 1 : j = 1

Next



WScript.Echo

WScript.Echo strClass & " Class Methods and Method Qualifiers"

WScript.Echo "-------------------------------------------------"

i = 1 : j = 1

For Each objClassMethod In objClass.Methods_

    WScript.Echo i & ". " & objClassMethod.Name

    For Each objMethodQualifier In objClassMethod.Qualifiers_

        If VarType(objMethodQualifier.Value) = (vbVariant + vbArray) Then

            strQualifier = i & "." & j & ". " & _

                           objMethodQualifier.Name & " = " & _

                           Join(objMethodQualifier.Value, ",")

        Else

            strQualifier = i & "." & j & ". " & _

                           objMethodQualifier.Name & " = " & _

                           objMethodQualifier.Value

        End If

        WScript.Echo strQualifier

        strQualifier = ""

        j = j + 1

    Next

    WScript.Echo

    i = i + 1 : j = 1

Next

Scripting Clinic

Greg Stemp 长期以来被公认为美国国内的脚本编写权威之一，并且被大家广泛誉为世界级……哈哈！嗯，他们 的履历表中怎么都当过足球教练？真的吗？他被解雇 了？哦，好吧。Greg Stemp 工作在……哦，好了，难道我连这都不能说吗？好吧！Greg Stemp 从 Microsoft 领薪水，在那儿他拥有并不显赫的首席作家（System Administration Scripting Guide ）的头衔。

Dean Tsaltas 是一个生活在 Redmond 的 Nova Scotian 人。他已经开始说一口流利的美语了，甚至会笑他的滨海省的朋友和家人们的发音。他的计算机生涯开始于他很小的时候，那时他的祖母和父母资助他，为他买了他心爱的 C-64，并为他订阅了 Compute! 的学报。现在，他已经在 Microsoft 工作了若干年，他有句话要告诉在家乡和温哥华的朋友和家人：“没有，我还没见过比尔！”

Bob Wells 漫无目的地四处游走，向每个听他说话的人大赞脚本编写的好处。有传言说，Bob 的两只达克思猎犬对脚本编写比大多数人类知道的都多。业余时间里，Bob 向 System Administration Scripting Guide 投稿。

Ethan Wilansky 把他的很多的工作时间花在了写作和咨询方面。他狂热于脚本编写、瑜伽、园艺和他的家庭（不一定按此顺序）。他目前正致力于一种创建能倒垃圾和洗餐盘的脚本的方法。