Today's script provides administrators with a method for isolating System Management Server (SMS) 2003 custom hardware...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
inventory reporting classes and custom data classes. If you subscribe to the notion of isolating the two classes, then you should keep custom reporting classes in the SMS_Def.mof along with the original SMS 2003 setup configuration. Remove all custom data classes from the SMS_Def.mof; they can be managed with a script. See more about this concept in my other article, SMS 2003 hardware customization: A better way. This approach supports using two files plus one MOF file for each custom data class that is created.
- SMS_Def.mof -- the file responsible for filtering out unnecessary hardware information and allowing what is required. A change to this file affects the data that is gathered on the client and viewed in the SMS console or in SMS Web reports. To gather data from a client, the Windows Management Instrumentation (WMI) class referenced must already exist, otherwise you have to create it.
- Custom MOF files -- one for each WMI data class that must be created.
- CompClasses.vbs -- a VBS script that checks for all custom WMI classes for Saudi Aramco and creates the ones that are missing. The program has intelligent error-checking built in. It includes a local log file and the creation of software delivery status MIF (management information format) files to offer custom installation status messages within the SMS console and with SMS Web Reports.
Working with Managed Object Formats
Basically, you will need to cut and paste all of the custom data classes from your SMS_Def.mof into individual MOFs (only for the custom data classes). The new MOFs must have the same file name as the custom class that is being created, including case sensitivity. Place the new MOFs into the same folder as CompClasses.vbs. Generally, custom classes are added to the end of the SMS_Def.mof so start looking there. You can find custom data classes easily by looking for lines that are similar to the following example:
// Extended AddRemovePrograms Data Class #pragma namespace("\\\\. \\root\\CIMV2")
ClassContext("local\HKEY_LOCAL_MACHINE\ \Software\ \Microsoft\\Windows\\CurrentVersion\ \Uninstall")]
In this case, you would cut from the beginning of this section from the SMS_Def.mof and paste it into the new
// Extended AddRemovePrograms Reporting Class #pragma namespace("\\\\. \\root\ \cimv2\ \SMS")
[SMS_Report(TRUE), SMS_Group_Name("Add Remove Programs"),
class Win32Reg_ExtAddRemovePrograms : SMS_Class_Template
The foundation script for CompClasses.vbs came from Robert Mahle. His script queried WMI, compiled a custom data class, used a log file and ran hardware inventory. I decided to create a new process at my organization to more safely and efficiently customize hardware inventory. To support the new process, I added some additional functionality to the script, such as first checking the connection to WMI, looping through a list of custom data classes from an input file, creating a software inventory status MIF and adding more error checking.
This script does the following:
- Creates a log file in %win%\ms\smswork\compclasses.log.
- Checks for ismifcom.dll. If it's missing, the script copies it to the Windows folder and then registers it.
- Creates a custom installation status MIF with value of Failed. This is changed to Success at the end of the script.
- Tests the connection to WMI. The script tries to read the root/cimv2/Win32_WMISetting class as a test.
- Reads the input file for the first custom class in the list. The file classes.txt contains these classes.
- Queries WMI for the class.
- If the class is found, it logs the action and skips to the next class in the list.
- If the class is missing, the script runs MOFComp to compile the proper MOF, which results in the creation of only the missing class.
- If MOFComp was run, it re-queries WMI for the missing class.
- If the missing class was not created after running MOFComp, the script creates a Failure status MIF and a failure log entry, and then it exits.
- If successful at creating the class, it goes to the next class in the list.
- If MOFComp was run and when done reading the input file, hardware inventory is cycled.
The script accesses the files from the folder where it is called, looking for the custom MOF files, Classes.txt and Ismifcom.dll. This allows the source folder to be imported into an SMS package and delivered to a client. For best results, configure the advertisement to have the client download the files from a distribution point.
Edit every instance of the following line adding a new MIF file name, package name and package version:
This file simply lists the custom classes exactly as they appear in Wbemtest, including case sensitivity. Class names should appear in a single column at the left of the file.
Creating custom classes on standalone systems
A delay occurs between the time when a new system comes on the network and the time when custom data is sent to the management point (MP). Several processes must occur: The client may need to be installed, it must download a policy that contains the SMS_Def.mof customizations, and then it must initiate hardware inventory. To more quickly gather data from newly imaged systems, run the script manually immediately after the image process completes but before the Advanced Client begins to communicate with the management point for the first time. After the client is able to download the first set of policies from the MP, force a hardware inventory.
Here is the download link for the script. It includes three files: Complclasses.vbs, Classes.txt and a custom MOF. You must download Ismifcom.dll from the SMS 2003 software development kit (SDK): http://www.microsoft.com/downloads/details.aspx?FamilyID=6150fb42-03d7-400c-92fd-a2fe3be997d1&DisplayLang=en. Good luck!
Dana Daugherty is a systems analyst with Saudi Aramco, the largest oil producing company in the world. He is a member of the Windows System Management group and is responsible for providing solutions to other IT groups for managing Windows operating systems. Daugherty can be reached at DanaDaugherty@yahoo.com.