SCCM 收集的hardware inventory信息是基于 Central site server上的 安装目录\inboxes\clifiles.src\hinv 目录中的MOF文件，这点和SMS 2003 中相同。不同点在于 SMS 2003 中，只有一个 SMS_def.mof， SCCM 中有两个MOF文件： Configuration.mof 和 SMS_def.mof

1.       Configuration.mof

a. 用于定义Hardware inventory client agent需要收集哪些data classes。可以定制data classes 来inventory 已有的或者定制的 WMI repository 中的data classes或者客户机上的注册表键值。

b. 当SCCM client 按照正常的policy 查询间隔向MP请求Computer policy时，Configuration.mof 被attach到下载的Policy 中，并被client编译。也就是说，如果Configuration.mof 中的添加,修改或者删除了data classes, SCCM client会在下一次请求Computer policy时将请求的policy和新版本的Configuration.mof一起编译。这些动作都是自动完成的，客户端上不需要做任何动作。


2.       SMS_def.mof

a.  用于定义hardware inventory client agent使用的reporting classes，确定哪些数据类的信息应该report (被hinv agent收集)。Reporting Classes 是基于客户端上已经存在的WMI repository 数据类，这些数据类的属性，以及Configuration.mof 中增加的定制data classes

b.  SMS_def.mof 中的reporting classes的信息在客户端按照正常的policy 查询间隔向MP请求Computer policy时被转换为一个reporting policy提供给client. Client编译新的reporting policy后，将reporting policy信息存储在客户端的WMI repository 中的Root\CCM\Policy\Machine\InventoryDataItem类中。同样，这些对客户端也都是全自动的，不需要客户端做任何动作。

c.  不像Configuration.mof， SMS_del.mof 永远不会被直接发送给client。

 

补充：

这和SMS 2003 的工作机制不同，这实际是SCCM 对SMS 2003 的一个很大的改进。

·  SMS 2003 中只有一个SMS_def.mof，它包括了SCCM 中的Configuration.mof 和SMS_def.mof 的全部信息：哪些需要inventory，哪些需要report。

·  SMS 2003 中的SMS_def.mof 也是不会被自动发送给client的。如果扩展了SMS_def.mof，就需要分发这个新版本的SMS_def.mof到所有客户端，并编译之。

·  这当然很烦人，解决的方法是创建一个program用于编译SMS_def.mof。 将这个program和新版本的SMS_def.mof 做成一个SMS Package，通过SMS 的软件分发机制来分发。

·  这个Program很简单， 就是 mofcomp.exe <path>\SMS_def.mof. 再加一些判断条件提高可靠性，很多方法都能做，就不详细说明了。

·  Configuration.mof (SCCM) 或者 SMS_def.mof (SMS 2003) 中可以通过Standard Registry Provider定制收集注册表键值数据的Data classes，在编译后会在客户端生成新的WMI classes， 然后客户端上的hardware inventory client agent 再从WMI 中（和收集其它硬件信息一样）收集信息。

 

注:转自微软中文论坛