Windows 管理操作系统--在你的企业中管理Windows和应用程序(一)

领测软件测试网

　　 
　　本文假定读者对COM，Windows，脚本程序较为熟悉。

摘要  本文为读者提供了关于Windows管理操作系统方面的综述，这是一项通过调用标准API函数，来获得各种系统及设备信息的技术。使用WMI，管理信息通过常规信息模式(CIM)中的面向对象结构得以陈列，这些结构依赖于分级结构的再使用，以及表征系统设备的标准对象类型。本文简单介绍了如何使用查询语言对WMI进行查询，以获取关于存在的系统类型，处理系统事件和WMI的安全性的信息，该查询语言就是类似于SQL的所谓的Windows管理操作查询语言(WQL)

现在，面临企业管理人员的一个挑战是，计算机管理网络日益庞大，复杂。Windows? 管理操作系统(WMI)是一项功能强大的技术，它可以同时管理一台机器，或是上万台机器。不幸的是，WMI或许是近年来Microsoft保密工作做得最好的，不外泄的技术之一。它远没有其他，诸如Active Directory?或Windows DNA等技术受到公众的关注。本文将系统的介绍WMI，以便你能获得一些的背景知识，并且使用WMI编写自己的应用程序。也许用不了多久，你就会觉得WMI应该象COM, Win32?, 或 Microsoft一样成为应用程序开发者的日常词汇了。

概述

WMI是Microsoft用来支持企业管理系统而引进的几项技术之一。 Active Directory提供了企业范围内的地点、政策和组织管理信息。Microsoft? 管理控制台系统(MMC)是编写应用管理程序时的标准框架。Windows Script Host系统(WSH)允许管理人员自动处理复杂的任务。最后，WMI是基于Windows操作系统，及其应用程序的一项远程控制的技术。

WMI允许应用程序的开发者，使用简单的、一致的机制，去查询企业中的任一台计算机上的信息，或是进行系统配置。通过WMI接口可以获得的信息量是惊人的，包括硬件设置，状态信息，驱动器配置，BIOS信息，应用程序的设置，事件记录信息，以及其他。WMI通过一组API来获得信息，但它表征的是一种通过一个简单，工业标准对象管理模式来获取信息的函数。这使得应用程序的开发者不必学习Windows的每一个API的具体细节。

要理解这样做的效果，假定应用程序的开发者想枚举出机器上四种不同类型的对象：服务，指针，过程和CPU。如果没有WMI系统，该开发者只好寻求不同的API来完成不同类型的枚举；但是使用WMI系统，这就变得相当简单了，这是因为每一对象类型都是以同一种方式枚举的。例如图1（Figure 1）显示了，用VBScript代码编写的WSH系统完成此任务是如何的简单。

如果你运行的是Windows 2000，你可以将这段代码拷贝到ENUM.VBS文件中，并且在控制台窗口运行cscript.ENUM.VBS命令。如果遇到错误，最可能的原因是，为了使该程序更短而忽略了对空指针的查错。例如，若系统不存在已安装指针的备注列表，obj.Description文件将返回空指针。

如果，你运行的操作系统是Windows 9x或是Windows NT? 4.0，WMI控件是可选组件。在Microsoft的网站上可得到最新版本的WMI。

显然，图1中的程序也可以用来枚举远程机器上的同样信息。要显示MYSERVER的信息，只需使用WinMgmts://MYSERVER在首行作为GetObject的参数。实际上，不论是从本地或是从远程的机器，WMI得到的信息，都是使用同一个API得到的。虽然某些Win32 API提供辨认远程计算机的功能，其他的API只能访问本地的机器，无法实现从远程计算机上得到信息。

WMI还能使对被管理对象的信息进行设置，以及调用变得简单。可以采用同样的语法结构来进行中止服务，结束进程，或是从远程计算机注销用户，等操作。应用程序的开发者只需知道对象的名称，以及准备进行的操作的名称，而没有必要了解一个新的API。

为完成所有事情，事件的基础结构将对通过WMI可以访问的对象给出修正信息。在本文的稍后部分，我将举一个创建和撤销监视器进程的例子；另一个例子是当插入或取出软盘时产生一个提示信息。WMI对象管理各类型操作采用的是同样的函数。甚至当基本API不提供针对对象的此类信息，WMI体系结构可以模拟监控这些事件的行为。另外，WMI服务自由的提供所有这些功能的远程访问。

除了WMI已经列出的信息，应用程序还可以列出他们自定义的对象和事件。这样，任意WMI管理程序就能管理你的其他应用程序，包括远程配置，修改提示信息，或是接受自定义事件。

WMI技术的起源

虽然WMI是Microsoft开发的技术，但是它是建立在近年来才引入的工业标准的基础上的。要了解WMI，就需要了解它从最初的所谓企业网络管理系统（WBEM）的演化过程。几年以前，为建立企业系统和设备管理系统的标准体系，一些计算机公司创建了WBEM系统。最初的目的是，开发单一的管理企业任意网络组件标准体系。这将简化由诸如SNMP网络设备标准体系，DMI桌面标准体系，等多个独立体系存在而引起的问题。将来，计算机公司开发与WBEM相配套的硬件，软件，以及操作系统，都将能以同样的方式进行管理。这样，单个管理程序就将能轻易地管理企业范围内的所有不同类型的组件了。实际上，WBEM的最初功能设计是针对(Desktop Management Task Force (DMTF)的。DMTF系统是针对维持实现WBEM系统最初目标所需的标准系统而设计的。

CIM类

最初的WBEM系统的第一个标准是，所谓的常规信息模式（CIM）的管理信息描述函数。CIM采用面相对象函数模拟信息，使用分类定义，分级结构，事例，属性，以及函数描述管理信息。CIM类是通过管理对象格式（MOF）在文本文件中定义的。完整的MOF文件格式系统已经超出了本文的范围，但是，如果你熟悉C++，JAVA，或是接口定义语言(IDL)，则你将对它的语法结构相当熟悉。以下就是如何定义一个类，及其子类的一个例子：

[abstract] class Automobile
{    
[key] string Make;    
[key] string Model;    
void Recall();
};

class Car : Automobile
{    
real32 BlueBookValue;
};

class Truck : Automobile
{    
uint32 Axles = 2;
};
以上的MOF文件定义了Automobile作为一个基本类，及其两个子类：Car和Truck。Automobile具有Make属性，Model属性，以及Recall函数。Car具有BlueBookValue的额外属性。Truck具有Axles属性，默认值为2（对于Axles而言，如果不另外指定，Truck每一次得到的新的值是2）。括号里的文字（abstract和key）引入了CIM分类参数的概念。分类参数可以应用于整个类，属性，函数或是单独的函数参数。分类参数与IDL文件中属性的概念类似。它们提供了与类，属性和函数的使用相关的额外信息。在这个例子里，abstract类的分类参数意味着，你无法看到Automobile的示例。另一方面，由于Car和Truck不是abstract类，你可以列举Car和Truck的例子。Key属性分类参数意味着任意Automobile（或任意派生类）可以被参数Make和Model唯一确定。这是一个从数据库借用的概念。所有支持多种事例的类需要确定Key属性，即每一种事例必须是Key属性值的唯一组合。换句话说，即使Automobile类定义只允许存在唯一的Ford Mustang事例，但是你可以创建Ford Taurus，甚至Gm Mustang的事例。如果类有且只有一种事例，它可以用单独的一个类的分类参数来描述。在这种事例下，类不再需要确定诸如Key之类的其他属性了。MOF文件格式是用来描述事例或类定义的，以下的示例描述了Truck的一种事例：

instance of Truck
{    
Axles = 5;    
Make = "Ford";    
Model = "Big Rig";
};

单独的CIM标准体系还不足以使公司能创建可管理的对象，并且防止出现混乱。例如，一个公司将路由器称为网络路由器，而另一个公司将同一个东西称为路由器。甚至更糟的是，两个公司都可以定义同样的类的名称，但属性不同。为防止出现这种混乱，DMTF体系定义了CIM模式。模式是一个所有公司都统一遵循的一个有明确定义的类的集合。通常，作为CIM模式体系一部分的类，以CIM_为前缀（例如，CIM_Battery或CIM_Process）。CIM模式倚重于对分级结构的使用，允许管理程序以同样的方式处理相似对象的群。例如，CIM_Battery，CIM_Printer，以及CIM_Processor都是从基本类CIM_LogicalDevice派生得到的。这要求管理程序了解，如何通过CIM_LogicalDevice来管理有此类派生得到的任意类型的设备。此外，任意派生类都支持基本类的属性和函数。类CIM_LogicalDevice具有确定是否支持电源管理程序的属性(PowerManagementSupported)，以及允许设置电源状态的函数(SetPowerState)。通过从基本类功能列表得到的信息，应用程序可以管理打印机，处理器，以及其他任意从CIM_LogicalDevice派生的设备的电源状态。

分级结构的另一个好处是，如果计算机分销商们能够提供比CIM类定义的更多信息的话，他们能够扩展CIM_schema。例如，Windows操作系统知道已安装的打印机AveragePagesPerMinute参数。类CIM_Printer没有定义此信息，因此Microsoft由CIM_Printer派生定义了类Win32_Pointer，此类具有额外属性，AveragePagesPerMinute。知道类Win32_Proiner的管理程序可以使用这个信息，而只知道如何管理CIM_Pointer的管理程序也能正常工作。

WBEM支持

CIM和MOF标准体系，以及CIM模式是最初的WBEM体系的核心组件。这些标准体系是不依赖于操作平台和实现的应用程序的。为使统一的管理成为现实，硬件和软件的分销商们必须创建支持这些标准体系的系统（指的是实现WBEM的应用程序）。这包括通过由CIM模式派生出来的类的功能列表。Microsoft在Windows操作系统上实现WBEM的应用程序是WMI。

并不只有Microsoft支持WBEM系统，硬件厂商也同意为实现WBEM系统提供网络以及存储设备。Sun公司许诺为实现WBEM提供Solaris操作系统，诸如Tivoli Systems和Computer Associates等管理软件的主要厂商也同意在他们的产品中支持WBEM系统。有了这些软硬件方面的支持，以一种单一的，一致的方式管理企业将成为现实。

WMI体系结构

了解图2所示的WMI组件的体系结构，可以帮助分析WBEM标准体系实现方式的创建。首要的任务是，确定CIM schema中的哪些组件在计算机中运行Windows。第二步是通过将Windows下列出的所有额外信息定义为类，以扩展CIM schema。Microsoft使用的约定类是CIM类派生得到的，类的前缀为Win32_（例如，Win32_NetworkAdapter就是由CIM_NetworkAdapter派生得到的类）。最终，你仍需要编写某些软件，来实际提供管理功能。保留已有的被支持类的列表是必须的，并且当类的不同事例需要时，还需要提供某些实际数据；通过完成所要求的操作，来响应函数对对象的调用也是必须的。在最初的术语中，这被称为CIM对象管理程序（CIMOM）。在Windows NT中，CIMOM处于WinMgmt服务包中，通过WinMgmt.exe文件得到实现。虽然Windows 9x不支持Windows NT服务包，CIMOM仍可通过可执行文件WinMgmt.exe得到实现。

在某些地方，你需要一个API来讨论CIMOM。你需要能够查询schema，枚举事例，以及调用函数。虽然，CIM标准体系定义的内容可以包括在类中，但并不存在这些内容的二元表示法的定义，或是用来访问这些内容的机制。你可以随意的使用动态连接库，COM，sockets，有名管道，等等。Microsoft选择通过一组DCOM接口列出CIMOM的功能。所有这些接口都是以Iwbem为前缀的（例如，IwbemServer或是IwbemClassObject），在SDK平台中都有存档。这些接口使得，编写对WMI管理的类和事例进行操作的管理程序成为可能。

通过选择使用DCOM，Microsoft本质上可以通过远程计算机访问CIMOM的任意接口，而不用编写额外的代码。但实际上，将每一次接口调用传送到远程计算机的额外开销就可能使客户机程序瘫痪。此外，由接口返回的信息中带有大量的冗余信息，是对带宽的一种极大的浪费。例如，每一个WMI对象包含了让计算机知道对象所在的属性。返回对象阵列的接口函数，在每一个元素中都含有同一计算机名；依靠DCOM来排列数据，将导致计算机名被反复的传送。为改善性能，Microsoft开发了高级用户代理和存根程序，来压缩信息，是这种额外开销减小到最小。虽然，开发者们也许并不知道这些代理和存根程序的存在，但这些程序是针对远程连接的不良性能而编写的。

一旦，你定义了允许访问CIMOM的DCOM接口，下一步就是创建一个包括所有分类定义的数据库。此外，你需要存储大量的，诸如WMI自身的安全性能设置的静态信息，这些静态信息是不允许被改变的数据，除非是CIMOM对它们的直接操作，或是间接的通过对DCOM接口的调用而进行的。这包括静态的事例数据，以及分类定义，并且允许系统配置信息以静态信息在注册表内的同样方式进行存储。包含这些静态信息的数据库被称为CIM对象库，一个winntsystem32wbem espository目录下的文件。

为提供动态对象的信息，WinMgmt服务包支持WMI信息提供程序的记录。WMI信息提供程序实际上就是，支持在SDK平台上描述的一组定义明确的接口的COM服务器。对于动态信息，WMI信息提供程序可以用CIMOM命令进行查询，或是直接调用CIMOM以告知数据的改变。WMI信息提供程序最常用的功能是用来提供动态事例信息，激活进程的列表；它也可以用来在模式中动态描述类的信息提供程序程序，或是创建事件信息的信息提供程序程序（事件体系结构将在稍后的内容中讨论）。WMI装载了在模式中为大量类提供信息的信息提供程序（如图3所示）。开发者可以通过定义自定义类，以及编写提供动态事例信息的信息提供程序程序，来拓展由WMI所提供的信息。

由WinMgmt服务包提供的DCOM接口足以使C＋＋应用程序开发者编写应用管理程序，但不幸的是，不是所有的开发环境都支持访问任意COM接口。为从支持自动对象的环境中访问WMI，Microsoft提供了直接与DCOM接口转换的应用程序对象。在DCOM接口与应用程序对象之间存在着直接的映射关系。例如，SwbemObject转换IwbemClassObject，以及SwbemServices转换IwbemServices。虽然命名系统不是唯一的，但是熟悉一个接口的人很容易辨认和了解其他接口事例。应用程序对象允许通过Visual Basic?，Visual Basic的应用程序（VBA），WSH， VBScript， JScript?，ASP，或是支持自动对象的其他环境，对WMI进行完全访问。在参考查询体系中加入WMI Scripting V1.1 Library ，则Visual Basic或是VBA方案就可以访问这些对象了。支持ActiveX?程序的操作平台可以通过对象类的代号，或是类的名称创建这些对象，这些对象的前缀是WbemScripting，如WbemScripting.SwbemLocator。

Microsoft提供的另一个组件返回访问DCOM接口，是创建类，属性，类似于数据库表格，行或列的事例列表的ODBC适配器。若将WMI数据写入Microsoft Excel电子表格，ActiveX数据对象（ADO）程序，或是其他数据库驱动程序，该适配器非常有用。

本文的剩余部分将讨论的是，通过DCOM接口，或是应用程序对象，对WMI的使用问题。这两类函数都提供对WMI服务包的完全访问，而ODBC适配器当前只支持WMI功能的一部分。虽然并没有涉及到XML使用方面的内容，但它却是需要关注到重要特征之一。正如前面所提到的，初始的WEBM没有指定使用某项特定的技术来访问CIM对象。Microsoft选择使用DCOM接口，而其他的操作系统或硬件设备似乎无法使用此接口；然而，XML提供HTTP连接协议可以被用作接入WBEM系统的标准方式。实际上，DMTF系统已经起到了为实现WEBM系统创建XML/HTTP协议的作用。在今后推出的硬件设备和操作系统都将支持通过XML和HTTP。

名称空间

WMI系统支持将类的集合分为所谓的名称空间的逻辑单元。名称空间类似于驱动器中的文件夹，而分类定义就类似于文件夹中的文件。图4 显示了在SDK平台上如何使用WMI工具表示名称空间。每一台计算机在分级结构的顶层都有一个有明确定义的名称空间，即所谓的根名称空间。名称空间的所在用路径来描述，这类似于子目录（如rootcimv2或rootdirectoryLDAP）。每一个名称空间都包括自己的类和事例的集合。为唯一确定某一个类，名称空间也必须是唯一确定的（如，rootcimv2:Win32_Processor）。在一个名称空间之中，所有的类必须是唯一的（正如文件在目录中的情况类似），但是在不同的名称空间中，不相关的类可以有相同的名称。分级结构是CIM中的一个关键组成部分，并且存在一个限制，所有希哦那个一个基本类派生出来的类，必须在同一个名称空间中定义。换句话说就是，如果你想从Automobile派生出一个类Car，类Automobile必须是在同一个名称空间中定义的。

Figure 4Exploring namespace

如文章的前段已经提及过的，初始的WBEM系统的一个核心组件是支持在CIM模式中定义的类。在WMI系统中，这些类可以在rootcimv2 名称空间中被找到。CIM模式在不断的更新，每次发布的都用一个版本数来描述。rootv2cimv2 名称空间 的V2指的是CIM第二版模式。这些模式储存在其他名称空间中，诸如与WDM提供的信息相关的rootWDM，或是与Active Directory信息提供程序提供的信息相关的rootdirectoryLDAP。实际上，除非你通过派生已有的类来拓展一个模式，否则最好在自己的名称空间中创建新的类。

系统类和系统属性

每一个名称空间都包含有一组公用类，即所谓的系统类。所有的系统类都以双下划线为前缀（例如，__Provider）。在每一个名称空间中都有一个有趣的类，__namespace类；这个类有一个独立的属性，即名称属性。枚举这个类的事例，为查询子名称空间提供了一种机制。例如，根名称空间在名称属性中有一个为cimv2设置的事例，__namespace。其他的系统类用于相对复杂的WMI编程，诸如自定义信息提供程序注册程序等，在本文中没有提及。

除了系统类之外，每一个类也有一组标准系统属性；并且它们也是以双下划线为前缀，很容易确认。这些属性是由WMI系统自动生成的，并且是只读的。他们存在的主要目的是为了让用户程序动态的确定对象的标识。在MOF文件中描述类或事例的定义时，这些属性被忽略了。图5 显示了系统属性的一个列表。

文章来源于领测软件测试网 https://www.ltesting.net/