Customizing Systems Management Server

Management Information Format filescategorize SMS inventory listings

Microsoft Systems Management Server (SMS) provides a powerful set ofservices and tools for centrally managing Windows NT networks. Itssystems-management capabilities let you inventory software and hardwareconfigurations, distribute software, perform remote troubleshooting, and storemanagement information to a centralized database. In addition to using theseservices, you can customize and integrate SMS with your internal systems andprocesses. Management Information Format (MIF) files let you collect inventoryinformation and use SMS to work with it. You can customize SMS by modifyingthose files.

MIFs
An important SMS function is inventorying your network's hardware andsoftware. SMS collects your system inventory information in MIFs. These ASCIItext files, which you can read with any text editor, describe your inventory ina nested hierarchy of categories: components, groups within components, anddetailed attributes within groups. As part of SMS's standard processing, MIFscollect and describe personal computer inventory information and internalinformation such as SMS events, job location, job details, user groups, andSimple Network Management Protocol (SNMP) traps. In addition to providing thesestandard MIF types, SMS lets you custom-define MIFs to describe virtually anytype of system component, such as a router, hub, printer, person, or conceptualobject.

MIF Syntax
MIFs comply with the Desktop Management Task Force (DMTF) Desktop ManagementInterface (DMI) version 1.0 standard. (SMS uses a subset of the DMI MIF syntax.For information about the DMI standard for MIFs, see the sidebar, "SMS and Desktop Management Interface ," page 104.) The DMI syntax organizes MIF information into different definition blocks. Table 1 (page 99) lists anddefines the definition-block types this article discusses.

In a MIF, the keywords Start and End delimit the scope of a definitionblock. For example, Start Component and End Component delimit the scope of acomponent block, so they are usually the first and last lines, respectively, ina MIF. A MIF's component block contains all other MIF blocks, which contain thedetails about a component's groups, attributes, and tables.

A MIF component becomes an inventory object when you load it into the SMSdatabase. Suppose you want an inventory object that represents an employee. Youneed to create a MIF containing the necessary definition blocks to fullydescribe and define the employee. Listing 1 shows a sample MIF that describes anemployee (lines are indented for readability). The Start Component and EndComponent keywords delimit the Employee component block, as you see in Listing 1at A. The Employee component block contains several group blocks. A Start Groupand End Group keyword pair delimits each group, as you see in Listing 1 at B:Architecture, Identification, Employee Information, and Employee Location. Eachgroup contains group statements and one or more attribute blocks.

Architecture and Identification are special groups that SMS requires. AMIF's Architecture group defines a component's group and attribute structure; ittells SMS what data needs to be in this component. You must include anArchitecture group for each MIF. For example, a component that describes PChardware includes an Architecture group that specifies Personal Computer.Listing 2 shows the Architecture group for this type of MIF. Except for theValue and string length, all Architecture group elements must match those inListing 2.

SMS includes the following standard architectures:

*Personal Computer, which defines inventory for the standard set ofsupported SMS clients and servers (all Microsoft clients and servers, Macintosh,OS/2, and NetWare)

*SMSEvent, which defines SMS Events that record information about theoperational status of SMS processes and components such as SMS service error(you can view these events through the SMS Administrator's Events window)

*PackageLocation, which provides such information about a distributedsoftware package as site, distribution server, share name, and package type

*JobDetails, which collects detailed information about an SMS jobsuch as the information about the job request

*UserGroups, which lists domain global groups by site code (for assigninguser groups to program groups)

*SNMP Traps, which store SNMP trap data that the SNMP Trap Receiver (newfor SMS 1.2) logs to your site

SMS also requires MIFs to include an Identification group, which containsattributes that identify the instance of the component the MIF describes.Listing 3 shows the Identification group from a Personal Computer architectureMIF.

Defining Group Blocks
To define a group block, you have to assign each group an Integer ID(e.g., see Listing 1 at C) that is unique within the MIF. In SMS, you use thisInteger ID only in the context of the current MIF to identify the group when SMSparses the MIF. In Listing 1 at C, the Architecture group has an Integer ID of1.

You also have to assign each group a Class, as you see in Listing 1 at D.The Class identifies the group type and its associated attributes across allMIFs of the same architecture. By convention, you can construct the Class byconcatenating your company name with the group name and a version number. Youseparate each component with the pipe symbol (|). In Listing 1 the Class for theArchitecture group is microsoft|architecture|1.0.

This identifier is in contrast to the Group ID, which must be unique onlywithin the current MIF. The ID might change, for example, if you generate MIFswith a dynamically changing number of attributes or you do not know what value athird-party product used in a previously generated MIF.

Although this varying of IDs does not affect SMS, other DMI systems thatsupport the Component Interface (CI) can have problems when the CI functionsreference the ID to locate groups and attributes. Therefore, I strongly advisethat once you select an ID for a group, you use it consistently for alladditional MIFs for that architecture.

A Group's Key Statement
A group can contain a Key statement, as you see in Listing 1 at E. A group'sKey statement lists the ID values, separated by commas, of attributes within thegroup. Together these attributes form the logical key that distinguishes onegroup record from another. When the Key statement is in the Identificationgroup, it identifies one or more of the Identification group's attributes thatform the logical key for the entire component. This logical key distinguishesone instance (here, an instance is the actual record of an object rather thanthe abstract definition of an object type) of a component for the givenarchitecture from another SMS database object of the same architecture.So, for example, the Key statement in the Identification group in Listing 1references the attribute ID, which is 1. (This attribute ID can be any numberyou choose, so long as it is unique within the group.) This ID, in turn,references the group's Employee ID attribute block value, which is 9999999999.This value (9999999999) is the logical key for the Employee component and thusdistinguishes this employee record from other employee records in the SMSdatabase.

For the Personal Computer architecture, the Key statement differentiatesone workstation and its associated groups and attributes from those of anotherworkstation. The unique logical key SMS uses to identify workstations is acombination of the Name, NetCardID, and SMSID attributes. (If you add a customarchitecture, you will want to ensure that you use the Key statement to identifya unique set of Identification group attributes. Otherwise, SMS will use allattributes in the Identification Group as the key.)

The Start Attribute and End Attribute keywords delimit each attribute in agroup. For example, in the Identification group in Listing 1 at F, EmployeeID isthe name of an attribute block. Similar to the ID statement for group blocks,the attribute block contains an ID statement (see Listing 1 at G) that must be aunique integer within the group. Be consistent with the Attribute ID to ensureother DMI services can use your MIFs.

An attribute's Access statement (see Listing 1 at H) defines the type ofaccess an application can gain to that particular field. SMS currently onlyparses this statement but doesn't use its value.

The Storage statement you see in Listing 1 at I defines how you store anattribute's value. If the Storage value is COMMON, the attribute's Valuestatement specifies the attribute's value, and SMS stores this value in a commonSMS database reference table that all groups of this class share. For eachinstance of this group in the database, SMS stores a pointer to the value in thetable for each common attribute. If the Storage value is SPECIFIC, SMS storesthe attribute's value in the group record.

SMS stores three types of attributes: String, Integer, and Date. The Typestatement you see in Listing 1 at J specifies the data type for an attribute.

Finally, the attribute Value statement you see in Listing 1 at K containsthe value to be stored for the particular attribute. In the Employee componentexample, the EmployeeName attribute is a 30-character string that stores JohnDoe. Because names are usually unique, the Storage type is SPECIFIC.

Customizing SMS
SMS lets you add new groups to existing architectures and create newinventory architectures. For example, you can add a User Information group tothe Personal Computer architecture to associate workstation inventory with auser. Or, you can create an architecture to define a new inventory component.SMS categorizes a MIF as either a NOIDMIF or an IDMIF. You add or update groupsin existing architectures with NOIDMIFs and IDMIFs, and you create newarchitectures with IDMIFs.

Adding a Group with NOIDMIFs
NOIDMIFs let you add a group to the Personal Computer architecture. NOIDMIFscontain no Identification group and no Architecture group because SMS mergesNOIDMIFs with standard Personal Computer inventory MIFs that already includethese groups.

You can create a NOIDMIF with SMS's MIF Form Generator and MIF Entry tool.MIF Form Generator lets you define a simple entry form that the MIF Entry tooldisplays at a workstation. SMS saves your input to a NOIDMIF that SMS combineswith the workstation's Personal Computer inventory. Listing 4 shows the NOIDMIFuinfo.mif, which was generated with SMS's default User Information MIF EntryForm. This form lets you add the User Information group to the Personal Computerarchitecture.

You can also create NOIDMIFs with a custom application or by using theWindows Notepad to create NOIDMIFs manually. As long as a NOIDMIF does notinclude an Architecture or Identification group and conforms to MIF syntax, SMSaccepts it and merges it with the Personal Computer architecture MIF.

NOIDMIFs are useful but limited because they can add or update groups foronly the Personal Computer architecture. Another limitation is that you mustsave NOIDMIFs on the workstation whose inventory you want to extend with theNOIDMIF.

Adding a Group with IDMIFs
IDMIFs contain both an Identification and an Architecture group (the exampleMIF in Listing 1 is an IDMIF). IDMIFs let you add or update groups for existingarchitectures the same way you use NOIDMIFs to add or update a group for thePersonal Computer architecture. IDMIFs also let you create new architectures andadd them to the SMS database.

Processing MIFs
After you create a MIF, you forward it to SMS for processing. SMS acceptsNOIDMIFs only on the client workstation in the mssmsoidmifs directory. Youcan save IDMIFs on client workstations, SMS Logon servers, or SMS Site servers.To expedite processing, save an IDMIF on the SMS Site server if possible.Otherwise, save it on the Logon server if the file depends on informationaccessible only at the Logon server. Or save the IDMIF at the workstation if itrequires details that you can define only at the workstation. On the clientworkstation, save IDMIFs in the mssmsidmifs directory; on the Logon server,in smslogon.srvisvmif.box; and on the Site server, insmssite.srvisvmif.box.

After you forward the MIF to SMS, SMS moves the file to the Site server (ifyou saved it at the workstation or Logon server) and checks the MIF for errors.SMS then adds the file (i.e., inventory object) to the SMS database, where youcan access it like any other inventoried component.

Let's Do It!
Now that you understand the basics of MIFs, you can customize SMS. Let'slook at creating a custom printer architecture that describes a printer. Listing 5 shows the printer architecture MIF.

Although you must follow SMS conventions for the Identification andArchitecture groups, you can define as many groups and attributes as you want.This example includes four groups: Identification (a required SMS group; theattributes are up to you), Architecture (a required group; the value ofthe Name attribute is up to you), Printer Details (your choice), and PrinterFonts (your choice). (DMTF has approved a printer MIF template with standardgroups for printer inventory. This template is available from the DMTF Web site.Listing 5 is a simplified example of a printer MIF.)

MIF Table Syntax
As the Employee example in Listing 1 illustrates, you can report repeatinggroups by repeating the entire group for each instance. A Key statement in theIdentification group identifies the group's attributes that form the logical keyfor the entire component. In groups other than the Identification group,the Key statement identifies an attribute combination that forms the logical keyto identify instances of a repeating group. A repeating group, also known as atable or replicated group, consists of elements that canappear multiple times within one component instance.

For example, in Listing 1, the employee works in more than one location, soI've repeated the Employee Location group for each location instance. TheEmployee Location Key statement you see in Listing 1 at L specifies the LocationNumber (Key = 1, which is the ID value of the Location Number attribute) as theunique logical key to identify each location instance. Note that the ID valuefor each Employee Location group within the MIF must be unique for each instanceof the repeating group. Otherwise, SMS will think the repeating group blocksrefer to the same group instance and subsequent group values will simply updatethe previous ones.

A more compact way to report repeating groups is to use a table block.Notice the table block at the end of the printer MIF in Listing 5. A table blockis a convenient way to report repeating groups (such as printer fonts--a Printerobject can have multiple resident fonts) in a MIF. In Listing 5, the PrinterFonts table captures printer font information.

Notice that the Printer Fonts group block (not the table block) has no IDstatement. This group functions as a template for the Printer Fonts table, whichincludes Name and Class statements with the same values as the template. Eachset of braces ({ }) represents an instance of the repeating group and containsvalues for the attributes in that instance. When you list the attributes withinthe braces, you must separate attribute values with a comma and place them inthe order that matches the numeric order of the attribute IDs in the grouptemplate (e.g., font type, resident font). Default values fill missing valueswithin the braces. The group template specifies these defaults. For example, thelast instance in the Printer Fonts table lacks a value for the Resident Fontattribute. Because the template contains the value Arial Bold Italic for thisattribute, SMS plugs in that value in the table's third instance.

Submitting the Custom Architecture
To submit the Printer MIF to SMS for processing, you must name it (the nameis p1000000.mif in the example) and place it in smssite.srvisvmif.box toexpedite processing. You can use any file name that has an extension of .mif or.nhm (no history MIF--use .mif if you want to maintain inventory history for theobject the MIF describes; use .nhm if you don't want to maintain history). AfterSMS processes the first MIF for the new architecture, you must exit and restartSMS Administrator (if it was running when you created the architecture) so itcan display inventory for that architecture. Once you establish the newarchitecture within the SMS Administrator, you can use the refresh option todisplay new instances of the architecture.

You can easily display a new architecture, such as the printer, in the SMSAdministrator Sites window by including several attributes in the MIF'sIdentification group. These attributes, Name, Site, Domain, and SystemRole, arein the example printer Architecture you see in Listing 5. You can addSystemType, which gives you more bitmap and icon choices in SMS Administrator ifyou use custom bitmaps and icons. If these attributes aren't present, SMScollects the inventory but doesn't display it in the Sites window. However, youcan use SMS's Query facility to access the new Architecture. For example, theEmployee architecture in Listing 1 won't display in the Sites window because itlacks the required attributes in the Identification group.

Screen 1 shows the SMS Administrator Sites window. In SMS, a default bitmaprepresents the printer inventory object this example creates (HP Printer 1).Opening the Properties window for HP Printer 1 displays the Printer Propertieswindow, as you see in Screen 2. The printer groups (Printer Details and PrinterFonts) appear as a default SMS icon.

Coming Up Next
My next article will explain how to polish custom architectures by usingcustom bitmaps and icons for display in the SMS Administrator. Subsequentarticles will explain how to use MIFs and the SMS API to create new applicationsor to integrate existing apps with SMS, and how to access SMS information andfunctions through the Internet.