WMI 脚本入门
发布日期： 09/03/2004 | 更新日期： 09/03/2004
Greg Stemp、Dean Tsaltas 和 Bob Wells
Microsoft Corporation
Ethan Wilansky
网络设计小组
摘要：Scripting Guys 的第一个 Scripting Clinic专栏展示了如何使用 WMI 脚本库创建大量有用的 Windows 系统管理脚本。
本页内容
 | 什么是 WMI？ |
| | 快速启动到 WMI 脚本 |
| | WMI 体系结构 |
| | 托管资源 |
| | WMI 基础结构 |
| | 浏览 CIM |
| | 就到这里吧 |
Microsoft®Windows®Management Instrumentation (WMI) 大概是我们已知的 Microsoft 保存最好的秘密。尽管如此，但毫无疑问，WMI 是 Microsoft 主要的针对 Windows 的管理支持技术。这对您来说意味着什么呢？那么，如果您管理 Windows 服务器和工作站，或者如果您创建 Windows 管理应用程序，您就需要了解 WMI。本文是教授您 WMI，更确切地说，是教您如何使用 WMI 脚本库来创建大批 Windows 系统管理脚本的系列文章中的第一篇。
在开始之前，我们应该用一点时间来感谢 Andrew Clinick，他让我们有机会来传承 Scripting Clinic。可以说，当 Andrew 在其最近的专栏中说他计划移交更多内容的时候，他并不是在开玩笑！事实上，Andrew 正在转移到另一个项目，因此他客气地请我们从他停止的地方继续。除了开始时由于 Andrew 为Scripting Clinic建立了很高的质量水准而感到有点勉强之外，我们很高兴接手这一工作。
那么，我们是谁呢？我们是 Scripting Guys，是编写 System Administration Scripting Guide 一书的小组，这本书作为 Microsoft® Windows Server 2003 资源工具箱附带的一部分。在专栏的大头照中，左面是 Dean，右面是 Greg。有传言说 Ethan 和 Bob 由于去做每周一次的肉毒杆菌除皱而错过了拍照。所以，如果以后在网上看到他们的照片时，发现他们俩看起来非常英俊，我们在这儿要先告诉您，Ethan 和 Bob 真的是我们见过的最笨得令人讨厌的家伙！记得要注意啊。
什么是 WMI？
WMI最初于 1998 年作为一个附加组件与 Windows NT 4.0 Service Pack 4 一起发行，是内置在 Windows 2000、Windows XP 和 Windows Server 2003 系列操作系统中核心的管理支持技术。基于由 Distributed Management Task Force (DMTF) 所监督的业界标准，WMI 是一种规范和基础结构，通过它可以访问、配置、管理和监视所有的 — 几乎所有的 Windows 资源。
要掌握 WMI 的强大功能和范围，需要考虑以前（或者现在）如何管理并监视 Windows 工作站和服务器。您可能用过或仍在使用众多的图形化管理工具来管理 Windows 资源 — 例如磁盘、事件日志、文件、文件夹、文件系统、网络组件、操作系统设置、性能数据、打印机、进程、注册表设置、安全性、服务、共享、用户、组等等。
尽管图形化工具提供了一种功能管理解决方案，它们所共有的东西是什么呢？一种答案是，在 WMI 之前，所有的 Windows 图形化管理工具都依赖于 Win32 应用程序编程接口（Application Programming Interfaces，APIs）来访问和管理 Windows 资源。为什么？因为在 WMI 之前，能够以编程方式访问 Windows 资源的惟一方法就是通过 Win32 API。这种情况使 Windows 系统管理员无法通过一种简便的方法利用常见的脚本语言来自动化常用的系统管理任务，因为大多数脚本语言都不能直接调用 Win32 API。通过提供一致的模型和框架，WMI 改变了这种情况 — 通过模型和框架，所有的 Windows 资源均被描述并公开给外界。最好的一点是，系统管理员可以使用 WMI 脚本库创建系统管理脚本，从而管理任何通过 WMI 公开的 Windows 资源！
使用 Windows Script Host 和 Microsoft Visual Basic Scripting Edition (VBScript)，或任何支持 COM 自动化的脚本语言（例如，ActiveState Corporation 的 ActivePerl），可以编写脚本来管理和自动化企业系统、应用程序和网络的下列方面：
| • | Windows Server 2003 、 Windows XP 专业版和 Windows 2000 系统管理 。您可以编写脚本来检索性能数据，管理事件日志、文件系统、打印机、进程、注册表设置、计划程序、安全性、服务、共享以及很多其他的操作系统组件和配置设置。 |
| • | 网络管理 。您可以创建基于 WMI 的脚本来管理网络服务，例如 DNS、DHCP 和启用 SNMP 的设备。 |
| • | 实时健全监视 。使用 WMI 事件订阅，您可以编写代码以在事件发生时监视并响应事件日志项，监视并响应文件系统、注册表修改及其他实时的操作系统更改。基本上对 WMI来说，WMI 事件订阅和通知是在 SNMP 环境中 SNMP 陷阱是什么。 |
| • | Windows .NET 企业服务器管理 。您可以编写脚本来管理 Microsoft Application Center、Operations Manager、Systems Management Server、Internet Information Server、Exchange Server 和 SQL Server。 |
返回页首
快速启动到 WMI 脚本
为了让您对 WMI 脚本是什么有一些概念，让我们来看看一个表面看来不怎么重要的任务 — 检索安装在基于 Windows 的远程计算机中的物理内存的总量。在 WMI 之前，如果没有另外的第三方工具，是不能通过一个脚本来轻松完成这个任务的。实际上，在 WMI 之前，使用包括操作系统工具的工具确定安装在计算机中内存数量的惟一方法是通过系统属性对话框。今天，如果目标计算机上安装了 WMI，并且有计算机的管理员访问权限，您就可以使用一个 WMI 脚本来检索在远程 Windows 计算机上安装的物理内存量，如清单 1 中所示的一样简单。
清单 1 ：使用 WMI 和 VBScript 检索总物理内存strComputer = "atl-dc-01"
Set wbemServices = Getobject("winmgmts://" & strComputer)
Set wbemObjectSet = wbemServices.InstancesOf("Win32_LogicalMemoryConfiguration")
For Each wbemObject In wbemObjectSet
WScript.Echo "Total Physical Memory (kb): " & wbemObject.TotalPhysicalMemory
Next
要运行清单 1 中的示例脚本，将其复制并粘贴到您最常用的文本编辑器中（notepad.exe 也可以），将分配给 strComputer 变量的值更改为域中一个有效的启用 WMI 的计算机，保存脚本（扩展名为 .vbs），并如
图 1所示运行脚本。
有点不可思议，无须任何录入，您应该会看到目标计算机的物理内存量回显到控制台。
现在，在你说“天哪！真的用六行脚本来检索一台计算机中的内存数量？”之前，让我们先礼貌地插几句话，因为至今尚不明显的是，您可以使用与在清单 1 中所演示的相同的基本步骤，从任何通过 WMI 公开的 Windows 资源检索配置和状态信息。
假设您想要检索安装在一台远程计算机上的所有服务的名称、状态和启动类型。清单 2 中的示例脚本完全使用清单 1 中使用过的相同的基本步骤来完成。
清单 2 ：使用 WMI 和 VBScript 检索服务信息strComputer = "atl-dc-01"
Set wbemServices = Getobject("winmgmts://" & strComputer)
Set wbemObjectSet = wbemServices.InstancesOf("Win32_Service")
For Each wbemObject In wbemObjectSet
WScript.Echo "Display Name: " & wbemObject.DisplayName & vbCrLf & _
" State: " & wbemObject.State & vbCrLf & _
" Start Mode: " & wbemObject.StartMode
Next
运行清单 2 生成如
图 2中所示的输出。
假设您对服务不感兴趣，但是需要从 Windows 事件日志检索记录。再次使用清单 1 中的脚本模板，您可以很容易地读取 Windows 事件日志，如清单 3 中所演示。在您运行清单 3 之前我们要指出的是，如果您的事件日志包含数千个记录，示例脚本可能需要用很长的时间运行。
清单 3 ：读取 Windows 事件日志记录strComputer = "atl-dc-01"
Set wbemServices = Getobject("winmgmts://" & strComputer)
Set wbemObjectSet = wbemServices.InstancesOf("Win32_NTLogEvent")
For Each wbemObject In wbemObjectSet
WScript.Echo "Log File: " & wbemObject.LogFile & vbCrLf & _
"Record Number: " & wbemObject.RecordNumber & vbCrLf & _
"Type: " & wbemObject.Type & vbCrLf & _
"Time Generated: " & wbemObject.TimeGenerated & vbCrLf & _
"Source: " & wbemObject.SourceName & vbCrLf & _
"Category: " & wbemObject.Category & vbCrLf & _
"Category String: " & wbemObject.CategoryString & vbCrLf & _
"Event: " & wbemObject.EventCode & vbCrLf & _
"User: " & wbemObject.User & vbCrLf & _
"Computer: " & wbemObject.ComputerName & vbCrLf & _
"Message: " & wbemObject.Message & vbCrLf
Next
如果我们仔细检查清单 1、2 和 3，我们会得出关于这三个脚本的两个非常重要的观察结果。第一个观察结果是，所有三个脚本都执行相同的三个步骤：脚本连接到 WMI，检索一个 WMI 托管资源，并回显资源的几个属性。第二个重要的观察结果是，在每个脚本中，惟一的更改是标识目标资源的类名（即分别为
Win32_LogicalMemoryConfiguration、
Win32_Service和
Win32_NTLogEvent），以及资源的相应属性。
脚本中使用的三个步骤，对于任何用于检索 WMI 托管资源信息的 WMI 脚本来说是共同的。让我们稍详细一些地看一下每个步骤。
步骤 1：连接到 WMI 服务
在任何 WMI 脚本中，第一个步骤都是建立一个到目标计算机上的 Windows 管理服务的连接。连接到在本地或远程计算机上的 WMI 与调用 VBScript 的
Getobject函数并将 WMI 脚本库的名字对象的名称（即“winmgmts:”，后跟目标计算机的名称）传递到
Getobject一样简单。
用这种方法连接到 WMI，返回一个对
SWbemServices对象的引用，我们使用清单 1、2、3 中的名为 wbemServices 的变量来引用该对象。
SWbemServices是在 WMI 脚本库中定义的一打左右的对象中的一个。WMI 脚本库提供一组用于访问 WMI 基础结构的通用对象脚本。一旦有一个对
SWbemServices对象的引用，您就可以调用任何提供了
SWbemServices的方法；
InstancesOf就是此种方法中的一个。
步骤 2：检索 WMI 托管资源的实例
普遍认为，第二个步骤主要取决于要执行的任务。在检索 WMI 托管资源的信息中，步骤 2 与调用
SWbemServices对象的
InstancesOf方法一样简单。正如方法名所示，
InstancesOf返回由资源的类名标识的托管资源的所有实例。
InstancesOf以一个
SWbemObjectSet集合的形式返回所需的资源，通过使用名为 wbemObjectSet 的变量我们在清单 1、2、3 中引用它。
SWbemObjectSet是 WMI 脚本库中定义的另一个脚本对象。
步骤 3：显示 WMI 托管资源的属性
最后一个步骤是枚举
SWbemObjectSet集合的内容。
SWbemObjectSet中的每个项都是一个
SWbemObject（WMI 脚本库中的另外一个对象） — 表示所需资源的一个单个实例。使用
SWbemObject来访问托管资源类定义中定义的方法和属性。
那么，如果从 WMI 检索信息的脚本编写步骤都是相同的，
Win32_LogicalMemoryConfiguration、
Win32_Service和
Win32_NTLogEvent类是什么呢？此外，它们来自哪里？哪些其他的类是可用的？还有，如何使用它们？这些问题的答案分散在构成 WMI 体系结构的各组件中。让我们来看一下。
返回页首
WMI 体系结构
WMI 体系结构由三个主层组成，如
图 3所示：
| • | 托管资源 |
| • | WMI 基础结构 |
| • | 使用者 |
我们将从最低层开始，因为资源是驻留在那里的。
返回页首
托管资源
托管资源是任意逻辑或物理组件，通过使用 WMI 进行公开和管理。可以使用 WMI 管理的 Windows 资源包括：计算机系统、磁盘、外围设备、事件日志、文件、文件夹、文件系统、网络组件、操作系统子系统、性能计数器、打印机、进程、注册表设置、安全性、服务、共享、SAM 用户和组、Active Directory、Windows 安装程序、Windows 驱动程序模式 (WDM) 设备驱动程序，以及 SNMP 管理信息基 (MIB) 数据等。WMI 托管资源通过一个提供程序与 WMI 通讯。当开始编写脚本来与 WMI 托管资源交互时，您经常会看到一个术语实例，它被用于引用在运行中的脚本中的托管资源的虚拟表示形式。
返回页首
WMI 基础结构
中间层是 WMI 基础结构。WMI 由三个主要组件构成：公共信息模型对象管理器（Common Information Model Object Manager，CIMOM）、公共信息模型（Common Information Model，CIM）储存库，以及提供程序。这三个 WMI 组件共同提供通过其定义、公开、访问和检索配置和管理数据的基础结构。虽然小，但是对编写脚本来说绝对不可或缺的第四个组件是 WMI 脚本库。
WMI 提供程序
WMI 提供程序在 WMI 和托管资源之间扮演着中间方的角色。提供程序代表使用者应用程序和脚本从 WMI 托管资源请求信息，并发送指令到 WMI 托管资源。例如，清单 1 和清单 2 使用内置 Win32 提供程序来检索内存和服务相关信息。清单 3 使用内置的事件日志提供程序来从 Windows 事件日志检索记录。
通过将托管资源公开给基于 WMI 标准的、统一访问模型的 WMI 基础结构，提供程序隐藏托管资源独有的实现详细信息。WMI 提供程序使用托管资源本机 API 与其相应的托管资源通讯，使用 WMI 编程接口与 CIMOM 通讯。例如，内置的事件日志提供程序调用 Win32 事件日志 API 来访问事件日志。
基于 WMI 的可扩展体系结构，软件开发人员可以开发并集成附加提供程序来公开其产品特有的管理函数。监视 Exchange 连接器状态的 Exchange Server 2000 提供程序就是一个这样的示例。同样，Application Center、Operations Manager、Systems Management Server、Internet Information Server 和 SQL Server 都包含 WMI 提供程序。
提供程序通常作为驻留在 %SystemRoot%/system32/wbem 目录中的动态链接库 (DLL) 实现。WMI 包括很多针对Windows 2000、Windows XP 以及 Windows Server 2003 系列操作系统的内置提供程序。内置提供程序（也被称为标准提供程序），从已知的操作系统源（如 Win32 子系统、事件日志、性能计数器、注册表等）提供数据和管理函数。表 1 中列出一些包含在 Windows 2000、Windows XP 和 Windows Server 2003 系列操作系统中的 WMI 提供程序。
| 表 1：部分标准的 WMI 提供程序清单 | |||
| 提供程序 | DLL | 命名空间 | 说明 |
| Active Directory 提供程序 | dsprov.dll | root/directory/ldap | 将 Active Directory 对象映射到 WMI。 |
| 事件日志提供程序 | ntevt.dll | root/cimv2 | 管理 Windows 事件日志，例如，读取、备份、清除、复制、删除、监视、重命名、压缩、解压缩和更改事件日志设置。 |
| 性能计数器提供程序 | wbemperf.dll | root/cimv2 | 提供对原始性能数据的访问。 |
| 注册表提供程序 | stdprov.dll | root/default | 读取、写入、枚举、监视、创建、删除注册表项和值。 |
| SNMP 提供程序 | snmpincl.dll | root/snmp | 提供对 SNMP MIB 数据的访问，并从 SNMP 托管设备捕获。 |
| WDM 提供程序 | wmiprov.dll | root/wmi | 提供对 WDM 设备驱动程序中信息的访问。 |
| Win32 提供程序 | cimwin32.dll | root/cimv2 | 提供关于计算机、磁盘、外围设备、文件、文件夹、文件系统、网络组件、操作系统、打印机、进程、安全性、服务、共享、SAM 用户及组，以及更多资源的信息。 |
| Windows 安装程序提供程序 | msiprov.dll | root/cimv2 | 提供对已安装软件信息的访问。 |
Windows XP 和 Windows Server 2003 包含很多附加的标准提供程序。如需标准提供程序的完整列表，参见 WMI Software Developers Kit (SDK) 文档中的 WMI 提供程序参考。
CIMOM
CIMOM（读作 see-mom）处理使用者和提供程序之间的交互。这一术语是来自于基于 Web 的企业管理软件和由 Distributed Management Task Force 维护的公共信息模型规范。
您可以将 CIMOM 想象为 WMI 信息代理。所有的 WMI 请求和数据都经过 CIMOM。Windows Management Instrumentation 服务 (winmgmt.exe)，在 Windows XP 和 Windows Server 系列操作系统上提供了 CIMOM 角色，在通用服务主机进程 (svchost.exe) 的控制下运行。
注在运行 Windows 2000 或 Windows NT 4.0 Service Pack 4 的计算机上，WMI 服务作为一个单独的服务进程运行。在运行 Windows Millennium Edition (Me)、Windows 98 或 Windows 95 OSR 2.5 的计算机上，WMI 作为一个标准可执行进程运行。
除了提供公共接口（使用者通过它访问 WMI）之外，CIMOM 还向 WMI 基础结构提供下列核心服务：
| • | 提供注册 。WMI 利用 CIMOM 提供注册位置和功能信息。此信息存储在 CIM 储存库中。 |
| • | 请求传送 。CIMOM 使用提供程序注册信息，将使用者请求传送到合适的提供程序。 |
| • | 远程访问 。使用者通过连接到远程系统上的 CIMOM 访问启用 WMI 的远程系统。一旦连接建立，使用者可以执行与在本地可以执行的操作相同的操作。 |
| • | 安全性 。在本地计算机或是远程计算机上，允许用户在连接到 WMI 之前通过验证每个用户的访问标记，CIMOM 控制对 WMI 托管资源的访问。WMI 并不覆盖或阻止由操作系统提供的安全性。 |
| • | 查询处理 。允许使用者使用 WMI 查询语言（WMI Query Language，WQL）发出关于任何 WMI 托管资源的查询。例如，您可以查询所有发生在过去 24 小时的，符合一个特定事件 ID 的事件的事件日志。CIMOM 只在提供程序本身不支持查询操作的情况下执行查询计算。 |
| • | 事件处理 。允许使用者订阅表示对 WMI 托管资源更改的事件。例如，您可以订阅表明逻辑磁盘驱动器上的空间何时下降到可接受的阈值以下的事件。CICOM 按一个指定的间隔轮询托管资源，并在满足订阅条件时生成一个事件通知。 |
管理应用程序、管理工具和脚本调入 CIMOM 以挖掘数据、订阅事件或执行一些其他的与管理相关的任务。CIMOM 获得必需的提供程序和类信息以满足来自 CIM 的使用者的请求。CIMOM 使用从 CIM 获得的信息，将使用者的请求传递到合适的提供程序。
CIM 储存库
WMI 的基本思想是 — 可以用一个架构统一表示来自不同源的配置和管理信息。CIM 就是这个架构，还调用了模型化托管环境和定义每个由 WMI 公开的数据块的对象储存库或类存储。该架构基于 DMTF 公共信息模型标准。
与建立在类概念基础上的 Active Directory 的架构非常相似，CIM 由类 组成。类是一个 WMI 托管资源的一个蓝图。然而，不同于 Active Directory 类表示创建并存储在目录中的对象，CIM 类通常表示动态资源。就是说，资源的实例并不存储在 CIM 中，而是通过基于使用者请求的提供程序动态检索。其原因很简单，大多数 WMI 托管资源的操作状态更改很频繁，因而必须按需读取以确保检索的是最新的信息。
注在 CIM 的上下文中，储存库这一术语有些被误解。尽管 CIM 是一个储存库，而且能够存储静态数据，但其主要角色是存储托管资源的蓝图。
与 Active Directory 类相似之处还有就是，CIM 类是分级组织的，每一级的子类从父类继承。DMTF 维护一组核心和公共基类，系统和应用程序软件开发人员（如 Microsoft 的那些）从这些类派生和创建系统（或应用程序）特定的扩展类。
类被分组到命名空间 中，命名空间是表示一个特定的管理区域的类逻辑组。例如，命名空间
root/cimv2包括大部分表示通常与计算机和操作系统相关联的资源的类。在前面的脚本中使用的类（
Win32_LogicalMemoryConfiguration、
Win32_Service和
Win32_NTLogEvent）驻留在命名空间
root/cimv2，它们只是在 CIM 中定义的数百个类中的三个。
CIM 类由属性和方法构成。属性描述 WMI 托管资源的配置和状态，方法是在 WMI 托管资源上执行操作的可执行函数。
注不要将由 CIM 定义的方法和属性与由 WMI 脚本库中的自动化对象提供的方法和属性相混淆。
从物理校对看，CIM 驻留在 %SystemRoot%/system32/wbem/Repository/FS/ 目录中，由下列 4 个文件组成：
| • | index.btr 。二叉树 (btree) 索引文件。 |
| • | index.map 。事务控制文件。 |
| • | objects.data 。存储托管资源定义的 CIM 储存库。 |
| • | objects.map 。事务控制文件。 |
在 Microsoft Windows 2000 和 Windows NT 4.0 Service Pack 4 中，CIM 存储在 %SystemRoot%/system32/wbem/Respository/cim.rep 中。在 Windows Millennium Edition (Me)、Windows 98 和 Windows 95 OSR 2.5 操作系统中，CIM 存储在 %windir%/system/wbem/Respository/cim.rep 中。
虽然 CIM 基于面向对象的设计原则，但是您无须成为信息建模或架构设计的专家，就可以有效地使用 WMI 并编写基于 WMI 的脚本。重要的是您了解 CIM 的基础结构和组织，并了解如何浏览和解释它的内容。
WMI 脚本库
WMI 脚本库提供自动化对象集，脚本语言（如 VBScript、Jscript 及 ActiveState 的 ActivePerl）利用它访问 WMI 基础结构。
WMI 脚本库中的自动化对象为 WMI 基础结构提供一个一致且统一的脚本模型。如前面所示，一旦您了解如何使用 WMI 脚本库检索一个托管资源类型，您就可以轻松使用相同的步骤来检索其它的 WMI 托管资源。例如，您可以使用前面列出的 3 个脚本中的任何一个，并很容易地修改这个脚本来检索在远程计算机上运行的进程 (Win32_Process) 信息、处理器 (Win32_Processor) 信息、操作系统 (Win32_OperatingSystem) 信息，或者由 WMI 公开的数百个托管资源中的任何一个。
WMI 脚本库在一个名为 wbemdisp.dll 的单个 DLL 中实现，该 DLL 物理驻留于 %SystemRoot%/system32/wbem 目录中。WMI 脚本库还包括一个名为 wbemdisp.tlb 的类型库。您可以使用 WMI 脚本类型库来从基于 XML 的 Windows 脚本文件（扩展名为 .wsf 的 WSH 脚本）引用 WML 常数。
WMI 使用者
使用者是顶层。使用者是脚本、企业管理应用程序、基于 Web 的应用程序，或其他管理工具，它们通过 WMI 基础结构访问并控制可用信息。
注很多管理应用程序担当 WMI 使用者和 WMI 提供程序的双重角色。有数种 Microsoft 管理产品都属于这种情况，如 Application Center、Operations Manager 以及 Systems Management Server。
返回页首
浏览 CIM
我们已经讨论了相当一部分的内容，但是还留有一个细节没有谈到，那就是如何确定哪些资源是通过 WMI 公开的。幸运的是，您可以使用多种不同工具来浏览 CIM 架构并检查 WMI 托管资源的类定义。
| • | WMI 控件 。WMI 控件 (wmimgmt.msc) 是一个 Microsoft 管理控制台 (MMC) 管理单元，它允许您在本地或远程计算机上配置 WMI 设置。尽管您不能使用 WMI 控件浏览 CIM，但是可以使用该工具的“安全性”选项卡来确定在本地或远程计算机上可用的 CIM 命名空间。有关更多使用 WMI 控件的信息，参阅 Windows 2000 帮助或 Windows XP 帮助和支持中心内的 WMI 控件概述。 |
| • | WMI 测试器 。WMI 测试器 (wbemtest.exe) 是一个用于与 WMI 基础结构交互的通用、图形化工具。您可以使用 WMI 测试器来浏览 CIM 架构并检查托管资源类定义。WMI 测试器还可用于执行与基于 WMI 的脚本执行的相同的操作，例如检索托管资源的实例和运行查询。WMI 测试器是在所有启用了 WMI 的计算机上默认的 WMI 安装的一部分，因此 wbemtest.exe 是一个出色的 WMI 学习和疑难解答工具。有关使用 WMI 测试器的信息，参阅 Windows XP 帮助和支持中哪诘?WMI 测试器概述。 |
| • | WMI 命令行 。作为 Windows XP 的一部分发布的 WMI 命令行工具 (wmic.exe) 提供一个到 WMI 基础结构的命令行接口。可以使用 wmic.exe 执行来自命令行的常见 WMI 任务，包括浏览 CIM 和检查 CIM 类定义。有关使用 WMI 命令行工具的信息，参阅 Windows XP 帮助和支持中心内的“使用 WMI 命令行 (WMIC) 工具” |
| • | CIM Studio 。作为 WMI SDK 的一部分，CIM Studio 提供一个基于 Web 的界面实现与 WMI 基础结构交互。与 WMI 测试器一样，您可以使用 CIM Studio 来浏览 CIM 架构、查看类定义并检索托管资源的实例。通过 CIM Studio 的超级用户界面可轻松查看类关系和关联，而且 CIM Studio 提供一个基本的搜索工具 — 它们是 WMI 测试器工具所不具备的两个功能。要使用 CIM Studio，您必需下载并安装 WMI SDK。您可以从 Windows Management Instrumentation (WMI) SDK 下载 WMI SDK。 |
| • | EnumClasses.vbs 和 EnumInstances.vbs 。Windows 2000 Server 资源工具箱包括很多利用了 WMI 的强大功能的脚本。这里所列出的三个脚本是常见脚本，可用于浏览 CIM 架构、查看类定义以及检索托管资源的实例。 |
您应该查看的一些附加资源包括：
| • | WMI SDK 文档 。WMI SDK 包含一个由标准的 WMI 提供程序提供的类的完整列表。您可以访问 MSDN 联机库中的 WMI SDK 文档。 |
| • | TechNet 脚本中心 。如果您愿意，可以把它叫做无用的废物，但是TechNet 脚本中心包含数百个来自即将推出的 System Administration Scripting Guide 中的基于 WMI 的示例脚本。 |
WMI 测试器 (wbemtest.exe) 演练
现在，您对可用于浏览和查看 CIM 的工具已经有了一些认识，让我们使用 WMI 测试器 (wbemtest.exe) 来检查
Win32_Process类定义并修改清单 2，以便从在您的本地计算机上运行的进程检索一些属性。
| 1. | 打开一个命令提示，键入 C:/>wbemtest.exe，按下 Enter 来开始 WMI 测试器工具。请注意，大部分按钮在主 WMI 测试器窗口上是被禁用的，这说明此时您没有连接到 WMI。 |
| 2. | 单击 Connect? 连接到本地或远程计算机上的 WMI 服务。显示“连接”对话框，它提供一个标记为 Namespace 的文本输入区域，该区域默认值为 root/default 。将 Namespace 区域的值更改为 root/cimv2 ，单击“连接”对话框的 Connect 按钮返回到主 WMI 测试器窗口。 |
| 3. | 主窗口中左上角的命名空间标识符应该显示为 root/cimv2。请注意，所有的按钮现在都已启用，这说明在当前凭据环境下，您已经成功连接到本地主机上的 WMI。单击 Enum Classes? 打开“超类信息”对话框。 |
| 4. | 在“超类信息”对话框中，不要填写 Enter superclass name 区域，单击 Recursive 选项，单击 OK 以枚举 root/cimv2 名称空间中定义的所有 CIM 类。 此时，您可能应该正在查看一个列出了数百个类定义的“查询结果”对话框。类的数量主要取决于您正在运行的 Windows 的版本。例如，如果使用 Windows 2000，则您应该会看到大约 600 个类定义。如果运行 Windows XP，则您应该会看到大约 900 个类定义。 请注意，列于“查询结果”对话框顶部的类是以两个下划线为开头的。这些是系统类。系统类是预定义的 CIM 类，支持内部 WMI 配置与操作，例如提供程序注册、命名空间安全性及事件通知等。现在，忽略系统类，向下滚动“查询结果”对话框直至看到以 CIM_ 开头的类。 名称以 CIM_ 开头的类是由 DMTF 维护的核心与公共基类。继续向下滚动直至到达以 Win32_ 开头的类。 名称以 Win32_ 开头的类是 Microsoft 扩展类，表示 Windows 特定的托管资源。如果这是您第一次检查 root/cimv2 命名空间，您可能希望熟悉 root/cimv2 命名空间中的类的完整集合，尤其是有 Win32_ 前缀的类。 |
| 5. | 向下滚动“查询结果”对话框直至到达 Win32_Process 类，双击该类名打开 Win32_Process 对话框的对象编辑器。 |
| 6. | “对象编辑器”对话框显示被选定类的定义和实现的详细信息（属性和方法）。回忆一下我们之前讨论的内容 — 类定义是 WMI 可管理资源的蓝图。 选择 Hide System Properties复选框隐藏系统属性。剩余的 Win32_Process 属性表示您可以从在本地或远程计算机上运行的进程检索的信息。 要完成您的 WMI 脚本练习，尝试去检索 Name 、 Handle 和 ProcessID 属性。使用前面的三个清单之一作为模板，试着在进行到第 7 步之前运行脚本。 注 要在本地计算机上运行脚本，将 strComputer 变量的值设置为“.”（引号内的一个单点）。 |
| 7. | 在运行新创建的 GetProcesses.vbs 脚本之后，您可以用 WIMI 测试器验证脚本的结果。在 Win32_Process 对话框的对象编辑器中，单击 Instances 。产生的查询结果对话框列出在计算机上运行的进程的实例。双击一个指定的进程实例，查看该实例的详细信息。 |
返回页首
就到这里吧
诚然，我们只是触及了 WMI 脚本撰写的表层。十分坦诚地说，这是有意的。WMI 提供了如此之多的脚本编写的可能性，因此很容易造成“只见树木，不见森林”的结果。不过不要担心，随着本系列内容的展开，我们将填补所有的缺口。此时要提炼出的重要内容是：WMI 是 Windows 中单独的、最重要的管理支持技术，您无需成为开发人员或者脚本编写权威就可以开始编写基于 WMI 的脚本。继续修改您新创建的脚本以检索另外的进程属性，或再进一步 — 检索其他托管资源。在我们下个月见面之前，您可能发现自己有了一个满是自定义的系统管理脚本的工具箱。让我们知道您做得到底怎么样。
清单 4 ： WMI 测试器演练的答案strComputer = "." ' Dot (.) equals local computer in WMI
Set wbemServices = Getobject("winmgmts://" & strComputer)
Set wbemObjectSet = wbemServices.InstancesOf("Win32_Process")
For Each wbemObject In wbemObjectSet
WScript.Echo "Name: " & wbemObject.Name & vbCrLf & _
" Handle: " & wbemObject.Handle & vbCrLf & _
" Process ID: " & wbemObject.ProcessID
Next
是美国国内公认的脚本编写权威之一，并且被大家广泛誉为世界级……哈哈！嗯，他们 的履历表中怎么都当过足球教练？真的吗？他被解雇 了？哦，很好！Greg Stemp 工作在……哦，来吧，难道我连这都不能说吗？好吧！Greg Stemp 从 Microsoft 领薪水，在 Microsoft 他拥有并不显赫的首席作家（System Administration Scripting Guide）的头衔。
Bob Wells漫无目的地四处游走，向每个听他说话的人大赞脚本编写的好处。有传言说，Bob 的两只达克思猎犬对脚本编写比大多数人类知道的都多。业余时间，Bob 向 System Administration Scripting Guide 投稿。
Ethan Wilansky把他的很多工作时间花在了写作和咨询方面。他狂热于脚本编写、瑜伽、园艺和他的家庭（不一定按此顺序）。他目前正致力于一种创建能倒垃圾和洗餐盘的脚本的方法。
如果要建造一所房子，您需要知道如何阅读和解释建筑图。如果要制造一个电子器具，您需要知道如何阅读和解释示意图。那么如果要编写一个 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
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 概念。
—
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所示运行脚本。您应该看到本地计算机的默认命名空间回显到控制台中。
要设置脚本的默认命名空间，执行与清单 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
显示在一台 Windows Server 2003 计算机上运行清单 5 的结果。命名空间列表会根据安装在目标计算机上不同版本的 Windows 和 WMI 而变化。
如您可能已经注意到的，清单 5 不提供目标计算机上所有可用的命名空间的完整描述。它只检索并显示在单一的、指定命名空间下的命名空间。为了在本地或远程的启用 WMI 的计算机上回显所有命名空间，您需要修改清单 5 来递归地连接到并枚举每个命名空间。幸运的是，这不想您想象中的那么难 — 尤其像清单 6 中展示的那样，有我们为您做这件事的时候。
将清单 5 更改到清单 6 中所示的递归命名空间脚本，主要包括实现子例程内的原始脚本正文，以及提供一个机制来调用从 CIM 检索的每个命名空间实例的子例程。清单 6 通过执行下列步骤完成了这个任务：
| 1. | 清单 6 从用目标计算机的名称初始化 strComputer 开始。WMI 中的单点 (“.”) 表示本地计算机。您可以将分配给 strComputer 的值更改为在您有管理控制权的域中的任何启用 WMI 的计算机。 | ||||||||
| 2. | 脚本调用递归子例程 (EnumNameSpaces)，然后传递给子例程一个标识初始化命名空间连接到“根”的字符串。 | ||||||||
| 3. | EnumNameSpaces 子例程的正文除了一个重要的改变外，与清单 5 是一样的。让我们逐步研究子例程。
|
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
展示了在同一台 Windows Server 2003 计算机上运行清单 6 的结果。
定义类的分类
如前面
图 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展示了它的一部分。
当然，您可以通过仅仅改变一下脚本的目标命名空间而轻松地修改清单 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 命名空间中的所有系统类： |
| • | 列出 root/cimv2 命名空间中的所有核心和公共类： |
| • | 列出 root/cimv2 命名空间中所有的 Win32 扩展类： |
| • | 列出 root/cimv2 命名空间中所有包含字符串“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所示，每个托管资源类定义都是由属性、方法 和限定符 组成的。
属性
属性是描述托管资源的名词。类使用属性来描述诸如标识、配置和托管资源状态等。例如，服务有名称、显示名称、描述、启动类型和状态。
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 脚本库来检索相同的信息，不久您就会看到。
比较类与托管资源
大部分 WMI 属性和方法是合理命名的。例如，如
图 8所示，如果您将由
Win32_Service类定义的属性和方法与服务的属性对话框相比，就不难推断出
Win32_Service.Name、
Win32_Service.DisplayName或
Win32_Service.Descritpion可能会包含什么。
那么我们为什么要关心所有这些内容？因为类决定了您能够（或不能）用 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
显示由
Win32_Service类定义（或继承）的 25 个属性的名称。
除了一个显著的例外，清单 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
显示由
Win32_Service类定义（或继承）的 10 个方法的名称。
除了三点例外，清单 11 与清单 9 和 清单10 相同。
| 1. | For Each 循环枚举类的 SWbemQualifierSet 集合（通过 SWbemObject Qualifiers_ 属性），并回显 SWbemQualifierSet 集合中每个 SWbemQualifier (objClassQualifier) 的 Name 属性。 |
| 2. | 因为类限定符是类定义的一部分而且限定符有值，清单 11 也检索并回显 SWbemQualifierSet 集合中每个 SWbemQualifier (objClassQualifier) 的 Value 属性。 |
| 3. | 因为一个限定符可以有多个存储在数组中的值，清单 11 必须在读取限定符的值前说明此点。如果不这么做，如果脚本试图将一个基于数组的限定符作为标量变量来读取，将会导致运行时错误。 Win32_NTLogEvent 类的 Privileges 限定符是一个基于数组的限定符实例。 |
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
显示由
Win32_Service类定义（或继承）的 5 个类限定符的名称和值。
如您可能已经注意到的，清单 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 中的系统属性。 |
| • | 包含对所有属性和方法的类起源。 |
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
显示所生成的 XML 文件，Win32_Service.xml，使用 Microsoft Internet Explorer。
返回页首
就到这里吧
如果对 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
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
长期以来被公认为美国国内的脚本编写权威之一，并且被大家广泛誉为世界级……哈哈！嗯，他们 的履历表中怎么都当过足球教练？真的吗？他被解雇 了？哦，好吧。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把他的很多的工作时间花在了写作和咨询方面。他狂热于脚本编写、瑜伽、园艺和他的家庭（不一定按此顺序）。他目前正致力于一种创建能倒垃圾和洗餐盘的脚本的方法。