管理
使用 SMS 的高级客户端清单
Wes Dobry
概览:
- 使用 SMS 2003 硬件清单代理
- 使用 MIF 文件扩展清单
- 动态 MOF 文件与静态 MOF 文件对比
下载这篇文章的代码: DobrySMSInventory2007_04.exe (152KB)
每个管理员都经常遇到这样的情形：上司需要一些信息，而这些信息不经过艰巨的努力就无法收集到。但是，作为一名工作积极主动的管理员，
如果您已经收集这些数据，就可以立即为上司提供信息，从而避免不必要的停工时间和加班时间，甚至可能为公司节省一大笔开支。您可以成为公司的英雄。
现成的 Microsoft® Systems Management Server ( SMS ) 2003 就可以收集大量的信息。但不是所有的信息。例如，在默认情况下，SMS 2003 不报告本地组及其成员信息，或者本地用户及其属性信息。缺少这方面的信息可能会产生问题。比如说，当一名技术人员正将域用户或（甚至更糟的是）将每个用户名输入到他们工作的每个系统的本地管理员组中，这时麻烦就来了。或者，假设一家公司无法知道其公司反病毒/反间谍软件解决方案的排除列表中应该包括哪些本地文件和文件夹。这看起来可能不是一个大问题 — 直到有 IT 人员发现用户在排除列表中输入 c:\*.*。
凭借脚本、Windows® Management Instrumentation (WMI) 和 SMS 知识的正确组合，您可以扩展 SMS 清单，从而包含几乎所有的详细信息。通过使用 MIF（管理信息格式）和 MOF（管理对象格式）文件即可实现这一点。
盘查
凭借 SMS，各组织可以进行自定义部署、监控目标以及维护部署的系统。通过扩展 SMS 清单，您可以创建和管理自定义程度高得多的目标。例如，您可以通过对系统（用户修改其策略）部署安全策略来强制执行公司本地安全策略。也可以禁用未经授权的本地用户帐户，并删除无关的本地管理员。
当然，各组织也依赖 SMS 及时获得有关客户端系统的详细信息。扩展清单允许您创建报告，报告中包含完整的自定义信息，仅依靠默认清单不容易获得。而且这些信息可以非常详细。例如，您可能会创建一个报告，内容包含拥有某特定注册表项指向某一特定服务器场的系统数。这样管理员就可以估计在任意指定时间每个服务器场大约有多少客户端在指向它。类似地，安全团队就能够检查网络上哪些系统运行着已知为间谍软件的特定进程。
MIF 和 MOF 文件的价值在于只需要很少的转换就能够从几乎任何来源输入信息。只要信息是基于文本的，就可以使用 MOF 文件处理信息并将其置入 WMI 中，或以 MIF 文件的格式进行收集，并在下一个硬件清单周期发送。实现清单扩展需要 VBScript 或 JScript® 方面的知识，同时也需要了解关于要收集的信息的知识。考虑到可收集的信息非常广泛，所以需要具备从 WMI 到高级 SQL 等各方面的知识。当然，由于报告收集的数据时需要 SQL 方面的知识，所以无论要收集什么类型的信息，都必须了解 SQL。
清单工作原理
SMS 包含两类清单进程：硬件和软件。软件清单进程只包括与文件有关的信息，如文件的位置、版本、大小及其他文件属性。不过，软件清单进程还允许您收集文件并将其存储在站点服务器上。
硬件清单扩展很容易实现，因为硬件清单包含有关系统信息的最大阵列。硬件清单中的信息主要来自 WMI、注册表和系统 BIOS。
硬件清单按计划表收集信息，计划表在 SMS 2003 的硬件清单代理站点设置中进行设置。收集的频率可以设置为频繁至每分钟一次，也可以不频繁至每几个月一次。通常要在两者之间取得平衡：根据管理的需要以最快的速率收集信息，同时不使网络、站点服务器、管理点或客户端负担过重。
当第一次安装硬件清单代理时，会编译 sms_def.mof 文件。此文件包含 SMS 最初收集的所有信息。当编译此文件时，硬件清单列表代理所需的所有 SMS 命名空间和相关的类都在 WMI 中创建。这些大部分位于 \\.\root\CIMv2\SMS 命名空间。安装后，硬件清单代理遍历大多数类建立相关信息。然后，这些信息会发送到管理点，并最终发送到站点数据库。
MIF 文件
除了从这些 WMI 类中提取信息，硬件清单代理会在 NOIDMIF 和 IDMIF 收藏文件夹中寻找 MIF 文件。代理在这些位置找到的任何 MIF 文件经过处理会进入下一个硬件清单中。
MIF 文件提供最简单的方法来扩展 SMS 硬件清单。有两种类型的 MIF 文件 — NOIDMIF 和 IDMIF 文件。这些文件是静态的、类似 XML 的文件，它们包含几乎所有用户可能想要输入 SMS 数据库的信息。可以用创建普通文本文件的任意一种方式创建 MIF 文件。因此，这些文件可以用大多数脚本语言创建，或者仅仅手动创建。
通常，MIF 文件用于信息未包含在注册表或 WMI 中的情况，或者信息需要手动输入时。例如，当硬件部署团队提供了一个新系统时，就可以创建这些文件。部署技术人员可以导航至系统上的 HTML 应用程序，并输入所有用于更新资产管理数据库的资产信息。然后该应用程序动态创建一个 NOIDMIF 文件，并允许技术人员下载该文件到 NOIDMIF 文件的收藏文件夹中。此 NOIDMIF 文件可包含所有技术人员输入的信息，并且融进 SMS 数据库中。
NOIDMIF 文件和 IDMIF 文件只有少许不同。IDMIF 文件包含一个唯一的标头，用于提供体系结构信息和唯一的 ID。IDMIF 文件可用于将非系统设备合并到 SMS 中作为其自己的实体。例如，脚本可用于创建 SMS 中实际上是打印机的系统，并将关于它们的信息写入 SMS 数据库中。
NOIDMIF 和 IDMIF 文件均存储于标准位置，这些位置由注册表项规定。在大多数情况下，假定 SMS 代理安装于默认位置，那么它们应位于 %SYSTEMROOT%\system32\ccm\Inventory\NOIDMIF 和 ...\IDMIF。如果代理安装于自定义位置，那么 MIF 目录应位于 %CCMAGENTINSTALLDIR%\Inventory\NOIDMIF 和 ...\IDMIF。如果对这些目录的位置有什么疑问，可以到列出的以下注册表项中查找位置：
HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\
Client\Configuration\Client Properties\NOIDMIF Directory
HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\
Client\Configuration\Client Properties\IDMIF Directory
无论收集的是什么信息，MIF 文件始终保持相同的格式。请参阅图 1 中所示 MIF 文件，该文件由一个单独的组件组成，该组件包含多个组，每个组有一个单独的属性。虽然您可能只需要一个组或一个属性条目，但是所有的组和属性都是必需的。您可以将 MIF 文件中的每一组看作硬件清单中命名部分数据中的一行，组中的每个属性是该行中的一列。
Figure 1 LocalAdmins.mif
Start Component
Name = “WORKSTATION”
Start Group
Name = “Local Admins”
ID = 1
Class = “Microsoft|LocalAdminsMIF|1.0”
Start Attribute
Name = “Account”
ID = 1
ACCESS = READ-ONLY
Storage = Specific
Type = String(100)
Value = “Win32_UserAccount.Domain=’Contoso’,Name=’Domain Admins’”
End Attribute
End Group
Start Group
Name = “Local Admins”
ID = 2
Class = “Microsoft|LocalAdminsMIF”
Start Attribute
Name = “Account”
ID = 1
ACCESS = READ-ONLY
Storage = Specific
Type = String(100)
Value = “Win32_UserAccount.Domain=’Contoso’,Name=’Technicians’”
End Attribute
End Group
Start Group
Name = “Local Admins”
ID = 3
Class = “Microsoft|LocalAdminsMIF”
Start Attribute
Name = “Account”
ID = 1
ACCESS = READ-ONLY
Storage = Specific
Type = String(100)
Value = “Win32_UserAccount.Domain=’Example-PC’,Name=’Administrator’”
End Attribute
End Group
Start Group
Name = “Local Admins”
ID = 4
Class = “Microsoft|LocalAdminsMIF”
Start Attribute
Name = “Account”
ID = 1
ACCESS = READ-ONLY
Storage = Specific
Type = String(100)
Value = “Win32_UserAccount.Domain=’Example-PC’,Name=’RandomUser’”
End Attribute
End Group
End Component
图 2 所示的示例 LocalAdmin.vbs 是一个非常简单的 VBScript。它查找 NOIDMIF 目录，如果存在临时的 MIF 文件则删除它，并创建新的临时 MIF 文件，通过一个简单的 WMI 递归查询搜集信息并写入到该文件中，删除 NOIDMIF 收藏文件夹中现有的 MIF 文件，最终将临时 NOIDMIF 移动到 NOIDMIF 收藏文件夹中。
Figure 2 LocalAdmin.vbs
On Error Resume Next
Const ForAppending = 8
Set objWshShell = CreateObject(“WScript.Shell”)
Set objFSO = CreateObject(“Scripting.FileSystemObject”)
strTempDir = objWshShell.ExpandEnvironmentStrings(“%TEMP%”)
strWinDir = objWshShell.ExpandEnvironmentStrings(“%WINDIR%”)
strComputerName = objWshShell.ExpandEnvironmentStrings(“%COMPUTERNAME%”)
strNoIDMifRegLocation = “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Client\Configuration\Client “ _
& “Properties\NOIDMIF Directory”
strNoIDMifDirectory = objWshShell.RegRead(strNoIDMifRegLocation)
strMifFileName = “\LocalAdmins.mif”
strClassID = “Microsoft|LocalAdminsMIF|1.0”
If objFSO.FileExists(strTempDir & strMifFile) Then
objFSO.DeleteFile(strTempDir & strMifFile)
End If
Set objMifFile = objFSO.OpenTextFile(strTempDir & strMifFileName, ForAppending, True)
objMifFile.Writeline “Start Component”
objMifFile.Writeline “ Name = “ & Chr(34) & “WORKSTATION” & Chr(34)
strWBEMQuery = “SELECT partcomponent FROM win32_groupuser WHERE groupcomponent = “ & Chr(34) _
& “\\\\” & strComputerName & “\\root\\cimv2:Win32_Group.Domain=\” & Chr(34) & strComputerName _
& “\” & Chr(34) & “,Name=\” & Chr(34) & “Administrators\” & Chr(34) & Chr(34)
Set objWBEM = CreateObject(“WbemScripting.SWbemLocator”)
Set objWBEMServer = objWBEM.ConnectServer(, “root\cimv2”)
Set colResults = objWBEMServer.ExecQuery(strWBEMQuery)
i = 1
For Each objItem in colResults
objMifFile.Writeline “ Start Group”
objMifFile.Writeline “ Name = “ & Chr(34) & “Local Admins” & Chr(34)
objMifFile.Writeline “ ID = “ & i
objMifFile.Writeline “ Class = “ & Chr(34) & strClassID & Chr(34)
objMifFile.Writeline “ Start Attribute”
objMifFile.Writeline “ Name = “ & Chr(34) & “Account” & Chr(34)
objMifFile.Writeline “ ID = 1”
objMifFile.Writeline “ ACCESS = READ-ONLY”
objMifFile.Writeline “ Storage = Specific”
objMifFile.Writeline “ Type = String(100)”
strUserName = objItem.PartComponent
strUserName = mid(strUserName, instr(1, strUserName, chr(58)) + 1)
If Instr(1, strUserName, Chr(92), 1) > 0 Then
strUserName = Replace(strUserName, Chr(92), Chr(92) & Chr(92), 1, -1, 1)
End If
If Instr(1, strUserName, Chr(34), 1) > 0 Then
strUserName = Replace(strUserName, Chr(34), Chr(39), 1, -1, 1)
End If
objMifFile.Writeline “ Value = “ & Chr(34) & strUserName & Chr(34)
objMifFile.Writeline “ End Attribute”
objMifFile.Writeline “ End Group”
i = i + 1
Next
objMifFile.Writeline “End Component”
objMifFile.Close
If objFSO.FileExists(strNoIDMifDir & strMifFileName) Then
objFSO.DeleteFile(strNoIDMifDir & strMifFileName)
End If
objFSO.MoveFile strTempDir & strMifFileName, strNoIDMifDir & strMifFileName
尽管 MIF 文件提供了最简单的方法来扩展 SMS 硬件清单，但是在使用它们时还有一些问题需要考虑。在每个硬件清单周期中都会处理 MIF 文件。但是既然这些文件被创建、收集、分析并最终放入清单中，那么 MIF 中包含的信息在清单中的显示可以最多推迟一个硬件清单周期。这意味着如果一家公司的硬件清单周期是一天，则站点数据库中的数据最多可能滞后两天。因此，您必须认真考虑创建 MIF 文件的程序何时得到通告，硬件清单周期何时运行。
假设一家名为 Contoso 的公司的清单周期是一天，并且在每天午夜运行。在星期一凌晨 1:00 运行 VBScript，创建一个包含 Rootkit 扫描程序输出的 NOIDMIF 文件。此输出结果在午夜收集并报告给管理点。接下来，Contoso 公司的 SMS 管理员在星期三晚上大约 10:00 查看这些信息，发现这些信息晚了 45 个小时。这是由于 SMS 管理员没有考虑应该在什么时间通告程序创建 NOIDMIF 文件。
MOF 文件
MOF 文件比 MIF 文件复杂的多。它们比 MIF 文件有优势，因为 MOF 文件直接向 WMI 中输入信息，并且使自己成为硬件清单代理的标准数据收集过程的一部分。因此，您不必反复通告 VBscript 来收集信息，这样既节省时间，又避免麻烦。相反每台计算机只需要通告 MOF 一次即可编译 MOF 文件。
MOF 文件还有一个优势就是其信息与硬件清单中的其他信息一样都是尽可能最新的。每次硬件清单代理经历其周期时，会要求类和提供程序详查 MOF 文件并迅速返回信息。当您需要迅速得到信息时，可以执行包含 MOF 文件和 VBScript 的程序包，从而启动一个硬件清单。接下来，很快就能获得您需要的信息，所花费的时间与通告程序政策周期一样短。
MOF 文件分为三类：用于现有的 WMI 类和命名空间的 MOF 文件、用于现有 WMI 提供程序的其他类的 MOF 文件以及用于没有 WMI 提供程序的其他类的 MOF 文件。
MOF 文件包含两部分。第一部分是命名空间定义部分。在这里标识 WMI 提供程序的信息。第二部分包含 SMS 报告属性。此部分告知硬件清单代理查找并处理上述 WMI 类中包含信息的位置。由于 MOF 文件直接处理 WMI，如果您打算使用这些文件，我们建议您花一些时间研究一下 Microsoft WMI 软件开发工具包 ( SDK )（请参阅 go.microsoft.com/fwlink/?LinkID=83121 以获得更多信息）。
上述每一类 MOF 文件可以是静态的，也可以是动态的。例如，如果把公司的构建过程编译成 MOF 文件（包括谁构建该系统、使用的服务器版本、最初的构建版本是什么、计算机构建的日期等），将会得到一个静态的 MOF 文件。这些信息从不需要更新，因此可以直接输入到 MOF 文件中，并通过使用 mofcomp.exe 编译到 WMI 中。完成这些后，通过向站点服务器的 sms_def.mof 文件中加入组和类信息，使硬件清单代理寻找的范围扩大。
动态 MOF 文件与静态 MOF 文件类似，除了它通过 WMI 提供程序来收集信息，而不是直接把收集到的信息写入 WMI 中。WMI 提供程序是一种插件，允许应用程序或服务直接输入信息到 WMI 中。此提供程序允许动态访问 WMI 和系统的其他区域，例如注册表、文件位置和 Windows Installer 信息。
关于使用 MOF 文件，增强硬件清单最简单的方法就是让清单目录显示更多的信息，而这些信息已经存在于 WMI 中。通过扩展 sms_def.mof 文件，或开启其他当前禁用的报告类，就可以实现上述功能。sms_def.mof 文件位于 \\siteserver\SMS_<sitecode>\inboxes\clifiles.src\hinv 文件夹。公司的所有设备都将在其下一个计算机策略周期引入新的 sms_def.mof 文件，并开始收集和报告信息。
另一方面，考虑到困难因素，使用现有的 WMI 提供程序，而不是创建一个新类。这种方法的一个示例如图 3 所示。在本例中，通过使用内置的注册表提供程序，在本地设备上创建类 CU_Desktop 和一个查询 HKEY_CURRENT_USER\Control Panel\Desktop\Wallpaper 的动态属性。此 MOF 文件在客户端编译后，SMS_Def_Extension.mof 中包含的信息（请参阅图 4）需要添加到 sms_def.mof 中。文件包含下列内容：SMS 是否应该报告该信息、组名、类 ID、硬件清单代理应该在 WMI 中查找哪些类从而找到要报告的信息以及（最后）实际值。
Figure 4 SMS_Def_Extentions.mof
#pragma namespace ("\\\\.\\root\\CIMv2\\sms")
[ SMS_Report (TRUE),
SMS_Group_Name ("Current User Desktop"),
SMS_Class_ID ("MICROSOFT|CU_Desktop|1.0") ]
class Power_Mgmt : SMS_Class_Template
{
[SMS_Report(TRUE),key]
string index;
[SMS_Report(TRUE)]
sint32 CurrentUserDesktop;
};
Figure 3 CurrentUserDesktop.mof
#pragma namespace(“\\\\.\\root\\CIMv2”)
// Registry property provider
instance of __Win32Provider as $PropProv
{
Name =”RegPropProv” ;
ClsID = “{72967901-68EC-11d0-B729-00AA0062CBB7}”;
ImpersonationLevel = 1;
PerUserInitialization = “FALSE”;
};
instance of __PropertyProviderRegistration
{
Provider =$PropProv;
SupportsPut =TRUE;
SupportsGet =TRUE;
};
[DYNPROPS]
class CU_Desktop
{
[key]
string index = “current”;
sint32 CurrentUserDesktop;
};
[DYNPROPS]
instance of CU_Desktop
{
[PropertyContext(“local|HKEY_CURRENT_USER\\Control Panel\\Desktop|Wallpaper”),
Dynamic, Provider(“RegPropProv”)]
CurrentUserDesktop;
};
MOF 文件也能够访问 WMI 提供程序所提供的信息，而在系统默认状态下未包含这些信息。为了使用这些提供程序，在客户端编译 MOF 文件和扩展 sms_def.mof 文件前，必须首先分发和安装 WMI 提供程序。
总结
MIF 和 MOF 文件是快速收集实质性信息的强大工具。这些文件格式提供了框架，不必直接修改表格，即可轻松地向 SMS 数据库引入信息。只要想象得到的，几乎所有信息都可以盘查并报告。更为可喜的是，管理员能够积极主动的收集重要信息，避免出现问题。
了解 MIF 和 MOF 文件需要花一些时间。不过，我们会提供有帮助的资源，帮助您学习如何使用这些文件。对于初学者，请参阅 WMI 文档和 SDK，以及 Systems Management Server 2003 操作指南。只要您付出努力了解这些概念，您从扩展的 SMS 清单中的获益将远远物超所值。
Wes Dobry 住在佛罗里达州的奥兰多市。他为那里的一家大型医疗保健公司工作，职务是顾问兼网络管理员。他的联系方式是 wesdobry@wesdobry.com。
© 2008 Microsoft Corporation 与 CMP Media, LLC.保留所有权利；不得对全文或部分内容进行复制.