WMI 脚本入门 第二部分.pdf

《WMI 脚本入门 第二部分.pdf》由会员分享，可在线阅读，更多相关《WMI 脚本入门 第二部分.pdf（21页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、14-6-15WMI 脚本入门：第二部分 脚本入门：第二部分发布日期:09/06/2004|更新日期:09/06/2004Greg Stemp、Dean Tsaltas、Bob Wells、Microsoft Corporation、My.Settings、My.User 和 My.WebServicesEthan Wilansky网络设计小组摘要：Scripting Guys 继续他们对编写 WMI 脚本的讨论，这次集中在 CIM 储存库和 CIM 类以帮助您巧用 WMI 脚本的全部强大功能。如果要建造一所房子，您需要知道如何阅读和解释建筑图。如果要制造一个电子器具，您需要知道如何阅读和解释

2、示意图。那么如果要编写一个 WMI 脚本，您猜到了，需要知道如何解释 WMI 对于管理的蓝图 CIM 储存库。CIM 储存库，在 WMISDK 中也称为 WMI 储存库，是存储建模 WMI 托管资源的类定义的 WMI 架构。为了强调 CIM 和 CIM 类的重要性，仔细考虑在 WMI 脚本入门：第一部分中展示的 4 个脚本，以及下面的清单 1 和清单 2。清单 1 是来自第一部分的服务脚本的一个略有增强的版本，而清单2 是使用 Win32_OperatingSystem 类的相同脚本的另一个变体。注 如果您对清单 1 和 2 有疑惑，我们建议您阅读（或视具体情况重读）本系列内容的第一部分。清单

3、 1：使用 WMI 和 VBScript 检索服务信息strComputer=.Dot(.)equals local computer in WMISet 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&vbCr

4、Lf&_ Description:&objService.Description&vbCrLf&_ Path Name:&objService.PathName&vbCrLf&_ Start Mode:&objService.StartMode&vbCrLf&_ State:&objService.State&vbCrLfNext清单 2：使用 WMI 和 VBScript 检索操作系统信息strComputer=.Set objWMIService=GetObject(winmgmts:&strComputer)Set colOperatingSystems=objWMIService.In

5、stancesOf(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&_

6、LocalDateTime:&objOperatingSystem.LocalDateTime&vbCrLf&_ Locale:&objOperatingSystem.Locale&vbCrLf&_ Manufacturer:&objOperatingSystem.Manufacturer&vbCrLf&_ OSType:&objOperatingSystem.OSType&vbCrLf&_ Version:&objOperatingSystem.Version&vbCrLf&_ Service Pack:&objOperatingSystem.ServicePackMajorVersion&

7、_ .&objOperatingSystem.ServicePackMinorVersion&vbCrLf&_ Windows Directory:&objOperatingSystem.WindowsDirectoryNext在本系列文章第一部分中的每个脚本以及本文的清单 1 和 2 中，唯一有区别的特征是标识 WMI 托管资源的类名和每个类属性14-6-15WMI 脚本入门：第二部分 CIM 类在WMI 脚本中扮演的重要角色。一旦知道如何编写一个脚本来管理一类 WMI 托管资源，您就可以对其他托管资源使用相同的基本技术。当然，知道一个托管资源的类名以及该类的相应属性只是本文的一部分。在您能

8、够巧用 WMI 脚本的全部强大功能之前，您需要对 CIM 储存库和 CIM 类的结构了解得再多一些。为什么呢？我们将给出两个重要的理由。1.了解如何浏览 CIM 将帮助您确定通过 WMI 公开的计算机和软件资源。2.了解如何解释托管资源的蓝图（类定义），将帮助您理解可以在托管资源上执行的任务。无论使用什么 WMI 工具，这两点都成立，无论使用 WMI 脚本库、WMI 命令行工具(wmic.exe)，或者企业管理应用程序，您都需要知道如何浏览 CIM 并解释 CIM 类。一个不那么明显但是同样重要的学习 CIM 的原因是，CIM 是 WMI 托管资源的极好的文档资源。没错，如果需要关于 WMI类

9、的详细信息，可以使用 WMI SDK。但是，如果不 需要关于 WMI 类的详细信息呢？假设您只想知道正在运行的 MicrosoftWindows 版本是否支持一个指定的类、方法或属性。那么，看看目标计算机的 CIM 吧。例如，我们经常被问及“为什么 TechNet 的脚本中心里的加入计算机到域脚本在 Windows 2000 中不能用？”回答是，因为在 Windows 2000 中的 Win32_ComputerSystem 类（它是在脚本中使用的 WMI 类）不支持JoinDomainOrWorkGroup 方法。在内置于 Windows XP 和 Windows Server 2003 的

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

11、可以编写WMI 脚本来检索托管资源类定义。无论选择使用现有的工具或者创建自己的工具，您都需要对 CIM 储存库的结构有一个基本的了解。所以，让我们从第一部分停止的地方开始，仔细了解一下 WMI 的管理蓝图 CIM 储存库。在整个讨论中，我们将使用 WMI 脚本库为您说明如何检索WMI 配置信息和托管资源类定义。管理蓝图在第一部分中，我们说到 WMI 的基本思路是 来自不同来源的配置和管理信息能够用一种架构统一地表示，而 CIM 储存库就是针对 WMI 的架构。可以将架构想象为蓝图或者代表现实世界中存在的某事物的模型。就好像建筑图构建物理结构的模型（例如，房子），WMI CIM 构建构成计算机的

12、硬件、操作系统和软件的模型。CIM 是 WMI 的数据模型。注 虽然 CIM 储存库能够存储一些数据（而且它确实存储了），但是它的主要目的是构建管理环境的模型。CIM 不是为存储它所定义的大量管理信息而设计的。相反，大部分数据是根据需要动态地从 WMI 提供程序检索的。一个例外是 WMI 操作数据。WMI 操作数据（例如，命名空间信息、提供程序注册信息、托管资源类定义和永久事件订阅）存储于 CIM 储存库中。图 1 提供了一个 CIM 储存库的内部结构和组织的概念化视图。如图 1 所示，CIM 使用类来创建数据模型。不可否认，CIM 包含的类远超过关系图中展示的 11 个 上次我们在 Wind

13、ows Server 2003 上统计大约有 5000 个。要了解的重要内容是，CIM 储存库是定义 WMI 托管环境和每个通过 WMI 公开的可托管资源的类存储。图 1 中展示三个重要的 CIM 概念，您需要了解它们以成功地浏览并解释 WMI 架构。1.CIM 储存库被划分为多个命名空间。2.每个命名空间包含下面一个或多个类的组：系统类、核心和公共类和/或扩展类。3.有三种主要的类类型：抽象、静态和动态。抽象类 是用于派生（定义）新的抽象和非抽象类的模板，不能用于检索托管资源的实例。静态类 定义物理存储在 CIM 储存库中的数据 最常见的是 WMI 配置和操作数据。动态类 是为从提供程序中动

14、态检索的 WMI 托管资源建模的类。称作关联类的第四种类类型，也是受支持的。关联类 是一个抽象、静态或动态的类，描述两个类或托管资源之间的关系。暂时别太担心关于 CIM 类类型问题，我们很快就会在一个更实际的环境中讨论 CIM 类类型。让我们更详细地看看每一个 CIM 概念。14-6-15WMI 脚本入门：第二部分 1：CIM 储存库的结构化视图 WMI 架构注 CIM 物理驻留在 Windows XP 和 Windows Server 2003 中名为%SystemRoot%system32wbemRepositoryFSobjects.data 的文件内。Windows 2000 和 Wi

15、ndows NT 4.0 ServicePack 4 将 CIM 存储在%SystemRoot%system32wbemRepositorycim.rep 中。而在 Windows Millennium Edition(Me)、Windows 98 和 Windows 95 OSR 2.5 操作系统中，CIM 存储在%windir%systemwbemRepositorycim.rep 中。命名空间定义CIM 类被组织到命名空间中。命名空间是 CIM 使用的分区机制，控制托管资源类定义的范围和可见性。CIM 中的每个命名空间包含一个表现特定技术或管理区域的相关类的逻辑组。命名空间中的所有类必须

16、有一个唯一的类名，一个命名空间中的类不能从另一个命名空间中的类派生，这就是为什么您将发现在多个命名空间中定义的相同的系统、核心以及公共类。多数为 Windows 托管资源建模的类驻留在 root/cimv2 命名空间中。不过，按照图 1 中的建议，rootcimv2 不是您唯一需要注意的命名空间。例如，事件日志、性能计数器、Windows 安装程序和 Win32 提供程序都将它们的托管资源类定义存储在rootcimv2 命名空间中。另一方面，注册表提供程序将其类定义存储在 rootDEFAULT 命名空间中。另外，新的 WindowsServer 2003 DNS 提供程序将其托管资源类定义存

17、储在 rootMicrosoftDNS 命名空间中。命名空间使用那么，命名空间如何影响您的 WMI 脚本呢？每个 WMI 脚本都作为初始化连接步骤（上个月我们简要地讨论过）的一部分连接到一个命名空间，如下所示：strComputer=.Set wbemServices=GetObject(winmgmts:&strComputer)如上，如果没有指定目标命名空间，则脚本连接到由下列注册表设置识别的命名空间：HKEY_LOCAL_MACHINESOFTWAREMicrosoftWBEMScriptingDefault 命名空间默认的命名空间设置是 WMI 脚本，%PATH%环境变量的默认设置是操

18、作系统。当您通过命令提示提交了一个命令而没有指定命令的完全限定路径时，操作系统使用%PATH%环境变量来定位该命令的可执行文件。如果操作系统不能找到这个文件，就会产生错误。14-6-15WMI 脚本入门：第二部分 WMI 脚本中检索一个托管资源时，如果没有指定命名空间，CIMOM（WMI 服务）就在默认的命名空间寻找该托管资源的蓝图（类定义）。如果 CIMOM 在默认的命名空间中找不到托管资源类定义，就会产生一个WBEM_E_INVALID_CLASS(0 x80041010)错误。注 不要将默认的命名空间设置与 rootDEFAULT 命名空间相混淆。它们是不相关的，除非您将 rootDEF

19、AULT 设置为您的默认命名空间。命名空间 rootcimv2 被初始配置为脚本默认的命名空间；但是，默认的脚本命名空间可以很容易地进行更改。因此，您应该始终 在您的 WMI 脚本中标识一个托管资源的命名空间，而不是采用默认设置。如果上个月就遵照了我们自己的建议，所有 4个清单（以及本文的清单 1 和 2）中的连接步骤就应该编写如下：strComputer=.Set wbemServices=GetObject(winmgmts:&strComputer&rootcimv2)将目标命名空间添加到连接字符串会告诉 CIMOM 在 CIM 中到哪里去寻找托管资源类定义，很像完全限定路径告诉操作系统

20、到底去哪里寻找一个文件。当您指定了目标命名空间，默认的命名空间就不使用了。管理脚本的默认命名空间您可以像清单 3 和清单 4中展示的那样，将 WMI 脚本库与 Win32_WMISetting 类结合使用来读取和更改脚本的默认命名空间。Win32_WMISetting 是一个为 WMI 服务的操作参数建模的动态类。可写的属性表示脚本的默认命名空间是ASPScriptDefaultNamespace。清单 3 使用了相同的 3 个 WMI 脚本编写步骤 连接、检索和显示 我们一直在使用的步骤，不过有一个明显的改变。正如前面建议的，我们在传递到 Microsoft Visual Basic Scr

21、ipting Edition(VBScript)的 GetObject 函数的 WMI 连接字符串中，指定 Win32_WMISetting 类的完全限定命名空间。那么，这里您会认为 Microsoft 没有遵循他们自己的建议。我们不但在清单 3 中遵循我们命名空间的建议，而且从此以后我们将限定命名空间。是的，如果想在您的 WMI 脚本中避免无效的类错误，它就是那么的重要。清单 3：为使用 WMI 和 VBScript，检索脚本的默认命名空间strComputer=.Set objWMIService=GetObject(winmgmts:&strComputer&rootcimv2)Set

22、colWMISettings=objWMIService.InstancesOf(Win32_WMISetting)For Each objWMISetting in colWMISettings Wscript.Echo Default namespace for scripting:&_ objWMISetting.ASPScriptDefaultNamespace Next要运行清单 3 中的示例脚本，将这段脚本复制并粘贴到您最喜欢的文本编辑器中，保存脚本（扩展名为.vbs），然后如图 2 所示运行脚本。您应该看到本地计算机的默认命名空间回显到控制台中。图 2：GetDefaultNam

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

24、in32_WMISetting。清单 4：用 WMI 和 VBScript 设置脚本的默认命名空间14-6-15WMI 脚本入门：第二部分 objWMIService=GetObject(winmgmts:&strComputer&rootcimv2)Set colWMISettings=objWMIService.InstancesOf(Win32_WMISetting)For Each objWMISetting in colWMISettings objWMISetting.ASPScriptDefaultNamespace=rootcimv2 objWMISetting.Put_Nex

25、t不要太专注于 WMI 脚本库的结构，因为我们将在本系列的第三部分中详细说明 WMI 脚本库。现在，让我们把注意力转回到CIM。列出命名空间到目前为止，我们已经用相同的 WMI 脚本技术来检索动态的 WMI 托管资源的实例。例如，在第一部分中，我们使用相同的脚本模板来检索物理内存、服务、事件日志记录和进程。在第二部分中，我们检索服务、操作系统信息和脚本的默认命名空间。这表明，您可以使用相同的 WMI 脚本技术来从 CIM 中检索命名空间信息。象在托管资源脚本中的情况一样，您需要对脚本做的唯一更改就是目标类名。命名空间信息作为 _NAMESPACE 类的一个静态实例存储在 CIM 中。_NAME

26、SPACE 类是我们前面简要定义的静态类类型的示例。不同于从提供程序按需检索的动态 WMI 托管资源，静态类实例存储在 CIM 中，且无需使用WMI 提供程序而直接从CIM 中检索。清单 5 使用 _NAMESPACE 类来检索并回显所有直接在根命名空间下的命名空间。清单 5：使用 WMI 和 VBScript 检索 CIM 命名空间strComputer=.Set objServices=GetObject(winmgmts:&strComputer&root)Set colNameSpaces=objServices.InstancesOf(_NAMESPACE)For Each objN

27、ameSpace In colNameSpaces WScript.Echo objNameSpace.NameNext图 3 显示在一台 Windows Server 2003 计算机上运行清单 5 的结果。命名空间列表会根据安装在目标计算机上不同版本的Windows 和 WMI 而变化。图 3：GetNamespaces.vbs 输出如您可能已经注意到的，清单 5 不提供目标计算机上所有可用的命名空间的完整描述。它只检索并显示在单一的、指定命名空间下的命名空间。为了在本地或远程的启用 WMI 的计算机上回显所有命名空间，您需要修改清单 5 来递归地连接到并枚举每个命名空间。幸运的是，这不想

28、您想象中的那么难 尤其像清单 6 中展示的那样，有我们为您做这件事的时候。14-6-15WMI 脚本入门：第二部分 5 更改到清单 6 中所示的递归命名空间脚本，主要包括实现子例程内的原始脚本正文，以及提供一个机制来调用从CIM 检索的每个命名空间实例的子例程。清单 6 通过执行下列步骤完成了这个任务：1.清单 6 从用目标计算机的名称初始化 strComputer 开始。WMI 中的单点(“.”)表示本地计算机。您可以将分配给strComputer 的值更改为在您有管理控制权的域中的任何启用 WMI 的计算机。2.脚本调用递归子例程(EnumNameSpaces)，然后传递给子例程一个标识初

29、始化命名空间连接到“根”的字符串。3.EnumNameSpaces 子例程的正文除了一个重要的改变外，与清单 5 是一样的。让我们逐步研究子例程。a.EnumNameSpaces 从回显子例程单一参数 strNameSpace 的值开始。strNameSpace 标识了每次子例程被调用时在连接字符串中使用的命名空间。b.在 VBScript 中使用 GetObject 函数，子例程连接到由子例程的 strNameSpace 参数标识的命名空间。c.在建立到目标计算机的 WMI 服务和命名空间的连接后，子例程立即在由 strNameSpace 引用的命名空间下检索所有命名空间实例d.使用 For

30、 Each 循环，子例程立即枚举在当前连接的命名空间下的命名空间实例。但是，并不是简单地回显子命名空间的名字，每个子命名空间的名称与传递到 EnumNameSpaces 子例程的新调用中的当前命名空间连接。重复这些子例程步骤，直至枚举了所有的命名空间实例。清单 6：使用 WMI 和 VBScript 检索所有 CIM 命名空间strComputer=.Call EnumNameSpaces(root)Sub EnumNameSpaces(strNameSpace)WScript.Echo strNameSpace Set objWMIService=GetObject(winmgmts:&st

31、rComputer&strNameSpace)Set colNameSpaces=objWMIService.InstancesOf(_NAMESPACE)For Each objNameSpace In colNameSpaces Call EnumNameSpaces(strNameSpace&objNameSpace.Name)NextEnd Sub图 4 展示了在同一台 Windows Server 2003 计算机上运行清单 6 的结果。14-6-15WMI 脚本入门：第二部分 4：GetAllNamespaces.vbs 输出定义类的分类如前面图 1 中所示，有 3 个通用的类的分

32、类用于构造 CIM：系统、核心与公共，以及扩展。系统类系统类是支持内部 WMI 配置和操作（例如，命名空间配置、命名空间安全性、提供程序注册以及事件订阅和通知）的类。浏览 CIM 时，您可以通过前缀在每个系统类名前的两条下划线轻易地识别出系统类。例如，图 1 中展示的_SystemClass、_Provider 和 _Win32Provider 类都是系统类。在上一节中，我们研究的 _NAMESPACE 类是另一个系统类的示例。系统类可以是抽象的或静态的。抽象系统类是用于派生其他抽象或静态系统类的模板。静态系统类定义物理存储在 CIM 储存库中的 WMI 配置和操作数据。例如，_Win32Pr

33、ovider 系统类定义存储在 CIM 中的提供程序注册信息。CIMOM（WMI 服务）使用存储在 CIM 中的提供程序注册信息，将动态托管资源的请求映射到相应的提供程序。正如我们之前用 _NAMESPACE 系统类进行的演示，您可以使用相同的 WMI 脚本技术来检索存储在 CIM 中的系统类的静态实例。例如，清单 7 检索并显示所有在 rootcimv2 命名空间中注册的 _Win32Provider 实例。清单 7：使用 WMI 和 VBScript 检索在 rootcimv2 命名空间中注册的 Win32 提供程序strComputer=.Set objWMIService=GetObj

34、ect(winmgmts:&strComputer&rootcimv2)Set colWin32Providers=objWMIService.InstancesOf(_Win32Provider)For Each objWin32Provider In colWin32Providers WScript.Echo objWin32Provider.NameNext14-6-15WMI 脚本入门：第二部分 WMI 的书，否则您不太可能会在 WMI 脚本中用到系统类。有一个例外是 WMI 监视脚本。WMI 监视脚本是订阅 WMI 事件的脚本。（事件是关心的事物已经变更为一个 WMI 托管资源的实

35、时通知。）我们会在未来的专栏中讨论WMI 事件订阅和通知。注 对于那些急不可耐的人，三个最常见的 WMI _Event 系统类是：_InstanceCreationEvent、_InstanceModificationEvent 和 _InstanceDeletionEvent。虽然我们还是不会在这里讨论它们，但是您可以在 TechNet 脚本中心的监视一节中找到示范如何使用这些系统类的示例监视脚本。核心和公共类核心和公共类扮演了两个角色。首先，也是最重要的，它们表现抽象类 系统和应用程序软件开发人员（例如 Microsoft 的开发人员）从这些抽象类派生和创建特定技术的扩展类。其次，它们定义

36、了特殊管理区域所共有的，但是不受限于特殊的技术或实现的资源。Distributed Management Task Force(DMTF)定义并维护这组可以通过 CIM_ 前缀来识别的核心和公共类。图 1 中四个以 CIM_ 开头的类是核心和公共类。在 rootcimv2 命名空间中定义的大约 275 个核心和公共类中，除了几个例外其余全部都是抽象类。这对您来说意味着什么呢？这意味着您将极少在 WMI 脚本中使用核心和公共类（以 CIM_ 为前缀的类）。为什么？因为您不能检索抽象类的实例，抽象类只能用作新类的基础。因为核心和公共类中的 271 个都是抽象的，所以它们主要被软件开发人员用来创建特

37、定技术扩展类。那么，例外是什么呢？275 个核心和公共类中的 4 个不是抽象类。它们是使用 Win32 提供程序(cimwin32.dll)来检索托管资源实例的动态类。请记录下来，这 4 个动态类是 CIM_DataFile、CIM_DirectoryContainsFile、CIM_ProcessExecutable和 CIM_VideoControllerResolution。扩展类扩展类是由系统和应用程序软件开发人员创建的特定技术类。图 1 中展示的Win32_BaseService、Win32_Service、Win32_SystemServices 和 Win32_ComputerS

38、ystem 类是 Microsoft 扩展类。在 rootcimv2 命名空间中的 Microsoft 扩展类可以通过 Win32_ 前缀来识别。虽然这么说，您不应该推断所有的Microsoft 扩展类名都以 Win32_ 开始，因为并非如此。例如，在 rootDEFAULT 命名空间中定义的 StdRegProv 类不是以Win32_ 为前缀的，尽管事实上 StdRegProv 类是用于注册表管理任务的 Microsoft 扩展类。在您问之前，我们要先说：不，我们不知道为什么 StdRegProv 类在 rootDEFAULT 命名空间而非 rootcimv2 定义。当我们编写这篇文章时，在

39、 rootcimv2 命名空间中定义了大约 463 个 Win32 扩展类。在 463 个 Win32 类中，68 个是抽象类而其余 395 个是动态类。这对您来说意味着什么呢？这意味着扩展类是您将要在 WMI 脚本中使用的主要的类类别。注 我们提供的类统计数据是基于测试版的 Windows Server 2003，且只想说明一般的 CIM 概念。基于个别因素，如：Windows 版本、WMI 版本以及安装的软件，您的数字会有所不同。列出类此时，我们将要告诉您的事情不应该是一个大的意外。您可以编写一个脚本来检索在一个命名空间中定义的所有类。例如，清单 8 列出了所有在 rootcimv2 命名

40、空间中定义的类。但是，与前面所有使用 SWbemServices InstancesOf 方法的脚本不同，清单 8 使用一个不同的方法，即 SubclassesOf，它也是由 WMI 脚本库的 SWbemServices 对象提供的。正如该方法的名称所暗示的，SubclassesOf 返回一个指定父类或命名空间（当没有提供父类的时候）的所有子类。如InstancesOf，SubclassesOf 返回 SWbemObjectSet 集合中的所有子类，这里该集合中的每个项目都是一个表示单一类的SWbemObject。清单 8 中另一个重要的不同是回显在 For Each 循环正文中的 objCl

41、ass.Path_.Path 属性。让我们查看一下 For Each 循环来了解这究竟是什么。For Each 循环正在枚举由 SWbemServices SubclassesOf 方法返回的 SWbemObjectSet(colClasses)集合中的每个 SWbemObject(objClass)。每个 SWbemObject 表示 rootcimv2 命名空间中的一个离散类。这是有可能产生混淆的部分。与我们前面所有显示由托管资源蓝图（类定义）定义的属性的脚本不同，Path_ 是由 WMI 脚本库的 SWbemObject 提供的属性。要了解这一点，您要考虑使用 SWbemObject 的

42、上下文。您在使用 SWbemObject 来访问托管资源的实例吗？或者您是否在使用 SWbemObject 访问托管资源的类定义？当您使用 SWbemObject 访问托管资源的实例时，您更有可能使用 SWbemObject 来访问由托管资源蓝图（类定义）定义的属性和方法。当您使用 SWbemObject 来获得详细的类信息 如支持的属性、方法和限定符 时，您使用由SWbemObject 自己提供的属性和方法。Path_ 就是一个这样的属性。Path_ 实际上引用了另一个名为 SWbemObjectPath 的，提供 Path 属性的 WMI 脚本库对象。SWbemObjectPath Pat

43、h属性包含了到被 SWbemObject（清单 8 中的 objClass）引用的类的完全限定路径。再一次提醒您，现在不要太专注于脚本对象，因为我们将在第三部分做详细讨论。清单 8：使用 WMI 和 VBScript 检索所有在 rootcimv2 命名空间中定义的类14-6-15WMI 脚本入门：第二部分 objWMIService=GetObject(winmgmts:&strComputer&rootcimv2)Set colClasses=objWMIService.SubclassesOf()For Each objClass In colClasses WScript.Echo o

44、bjClass.Path_.PathNext在我们的 Windows Server 2003 计算机上运行清单 8 显示出一个有 914 个类的长列表，图 5 展示了它的一部分。图 5：GetClasses.vbs 输出当然，您可以通过仅仅改变一下脚本的目标命名空间而轻松地修改清单 8 来列出其他命名空间中的类。您也可以将清单 8 与findstr.exe 命令结合使用以搜索类。对于不熟悉 findstr.exe 命令的用户：findstr.exe 是一个在文件中搜索字符串的命令行工具。例如，假设您需要知道您正在运行的 Windows 版本是否支持新的 Windows XP 和 Windows

45、 Server 2003的Win32_TSSessionSetting 类。可以使用下列命令行来确定 Win32_TSSessionSetting 类是否存在于 rootcimv2 命名空间中。C:Scripts cscript GetClasses.vbs|findstr/I Win32_TSSessionSetting这里来尝试几个另外的方案。列出 rootcimv2 命名空间中的所有系统类：C:Scripts cscript GetClasses.vbs|findstr/I _列出 rootcimv2 命名空间中的所有核心和公共类：C:Scripts cscript GetClasses

46、.vbs|findstr/I CIM_列出 rootcimv2 命名空间中所有的 Win32 扩展类：14-6-15WMI 脚本入门：第二部分 cscript GetClasses.vbs|findstr/I Win32_列出 rootcimv2 命名空间中所有包含字符串“process”的类：C:Scripts cscript GetClasses.vbs|findstr/I processCIM 类类型定义此时应该明显的看出：类是 CIM 储存库的基本构造块。WMI 配置信息和 WMI 托管资源由一个或更多类进行定义。与 ActiveDirectory 架构相似，CIM 类是按等级组织起来

47、的，在这种组织结构中子类从父类继承属性、方法和限定符（目前不必过多考虑属性、方法和限定符，我们将在下一节进行讨论）。例如，Win32_Service 动态类是从 Win32_BaseService 抽象类继承的；而后者是从 CIM_Service 抽象类继承而来的；CIM_Service 抽象类则是从 CIM_LogicalElement 抽象类继承的；而CIM_LogicalElement 抽象类又是从 CIM_ManagedSystemElement 抽象类继承而来的（如图 1 所示）。是托管资源的类层级中的类的总和最终定义了托管资源。如前面提到的，有 3 个主要的类类型：抽象、静态和动态

48、。抽象类抽象类 是用于定义新类的模版。如 Active Directory 架构中的抽象类，CIM 抽象类是作为其他抽象、静态和动态类的基类。每个，嗯，差不多是每个 WMI 托管资源类的定义是从一个或更多抽象类构建（或派生）的。您可以通过检查类的 Abstract 限定符来识别抽象类。抽象类必须定义 Abstract 限定符并将该 Abstract 限定符的值设置为true。本文结尾的补充清单 A 示范如何使用 WMI 脚本库来列出所有在 rootcimv2 命名空间中定义的抽象类。抽象类类型最常用于核心和公共类的定义。抽象类极少在 WMI 脚本中使用，这是因为您不能检索抽象类的实例。静态类静

49、态类 定义物理存储在 CIM 储存库中的数据。静态类拥有与动态类一样的实例，但是静态类的实例存储在 CIM 储存库中。同样，静态类实例是直接从 CIM 中检索的。它们不使用提供程序。您可以通过检查类的限定符来识别静态类。但是，不同于通过含有指定的限定符来识别的抽象和动态类类型，静态类是通过不含有 Abstract 和 Dynamic 限定符进行识别的。静态类类型最常用于系统类的定义。静态类极少在 WMI 脚本中使用。动态类动态类 是为从提供程序动态检索的 WMI 托管资源建模的类。您可以通过检查类的 Dynamic 限定符来识别动态类。动态类必须定义 Dynamic 限定符并将 Dynamic

50、 限定符的值设置为true。本文结尾的补充清单 B 示范如何使用 WMI 脚本库来列出在 rootcimv2 命名空间中定义的所有动态类。动态类类型最常用于扩展类的定义。动态类是在 WMI 脚本中使用的最常见的类类型。关联类第四种类类型称作关联类，也是受支持的。关联类是描述两个类或托管资源之间关系的抽象、静态或动态类。图 1 所示的Win32_SystemServices 类是一个动态关联类的示例，它描述了计算机与运行在其上的服务之间的关系。您可以通过检查类的 Association 限定符来识别关联类。抽象、静态或动态关联类必须定义 Association 限定符并将Association