Microsoft Systems Management Server (SMS) provides a powerful set of services and tools for centrally managing Windows NT networks. Its systems-management capabilities let you inventory software and hardware configurations, distribute software, perform remote troubleshooting, and store management information to a centralized database. In addition to using these services, you can customize and integrate SMS with your internal systems and processes. Management Information Format (MIF) files let you collect inventory information and use SMS to work with it. You can customize SMS by modifying those files.
MIFs
An important SMS function is inventorying your network's hardware and
software. SMS collects your system inventory information in MIFs. These ASCII
text files, which you can read with any text editor, describe your inventory in
a nested hierarchy of categories: components, groups within components, and
detailed attributes within groups. As part of SMS's standard processing, MIFs
collect and describe personal computer inventory information and internal
information such as SMS events, job location, job details, user groups, and
Simple Network Management Protocol (SNMP) traps. In addition to providing these
standard MIF types, SMS lets you custom-define MIFs to describe virtually any
type of system component, such as a router, hub, printer, person, or conceptual
object.
MIF Syntax
MIFs comply with the Desktop Management Task Force (DMTF) Desktop Management
Interface (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 and
defines the definition-block types this article discusses.
In a MIF, the keywords Start and End delimit the scope of a definition block. For example, Start Component and End Component delimit the scope of a component block, so they are usually the first and last lines, respectively, in a MIF. A MIF's component block contains all other MIF blocks, which contain the details about a component's groups, attributes, and tables.
A MIF component becomes an inventory object when you load it into the SMS database. Suppose you want an inventory object that represents an employee. You need to create a MIF containing the necessary definition blocks to fully describe and define the employee. Listing 1 shows a sample MIF that describes an employee (lines are indented for readability). The Start Component and End Component keywords delimit the Employee component block, as you see in Listing 1 at A. The Employee component block contains several group blocks. A Start Group and End Group keyword pair delimits each group, as you see in Listing 1 at B: Architecture, Identification, Employee Information, and Employee Location. Each group contains group statements and one or more attribute blocks.
Architecture and Identification are special groups that SMS requires. A MIF's Architecture group defines a component's group and attribute structure; it tells SMS what data needs to be in this component. You must include an Architecture group for each MIF. For example, a component that describes PC hardware includes an Architecture group that specifies Personal Computer. Listing 2 shows the Architecture group for this type of MIF. Except for the Value and string length, all Architecture group elements must match those in Listing 2.
SMS includes the following standard architectures:
* Personal Computer, which defines inventory for the standard set of supported SMS clients and servers (all Microsoft clients and servers, Macintosh, OS/2, and NetWare)
* SMSEvent, which defines SMS Events that record information about the operational 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 distributed software package as site, distribution server, share name, and package type
* JobDetails, which collects detailed information about an SMS job such as the information about the job request
* UserGroups, which lists domain global groups by site code (for assigning user groups to program groups)
* SNMP Traps, which store SNMP trap data that the SNMP Trap Receiver (new for SMS 1.2) logs to your site
SMS also requires MIFs to include an Identification group, which contains attributes that identify the instance of the component the MIF describes. Listing 3 shows the Identification group from a Personal Computer architecture MIF.
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 this
Integer ID only in the context of the current MIF to identify the group when SMS
parses the MIF. In Listing 1 at C, the Architecture group has an Integer ID of
1.
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 all MIFs of the same architecture. By convention, you can construct the Class by concatenating your company name with the group name and a version number. You separate each component with the pipe symbol (|). In Listing 1 the Class for the Architecture group is microsoft|architecture|1.0.
This identifier is in contrast to the Group ID, which must be unique only within the current MIF. The ID might change, for example, if you generate MIFs with a dynamically changing number of attributes or you do not know what value a third-party product used in a previously generated MIF.
Although this varying of IDs does not affect SMS, other DMI systems that support the Component Interface (CI) can have problems when the CI functions reference the ID to locate groups and attributes. Therefore, I strongly advise that once you select an ID for a group, you use it consistently for all additional 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's
Key statement lists the ID values, separated by commas, of attributes within the
group. Together these attributes form the logical key that distinguishes one
group record from another. When the Key statement is in the Identification
group, it identifies one or more of the Identification group's attributes that
form the logical key for the entire component. This logical key distinguishes
one instance (here, an instance is the actual record of an object rather than
the abstract definition of an object type) of a component for the given
architecture from another SMS database object of the same architecture.
So, for example, the Key statement in the Identification group in Listing 1
references the attribute ID, which is 1. (This attribute ID can be any number
you 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 thus
distinguishes this employee record from other employee records in the SMS
database.
For the Personal Computer architecture, the Key statement differentiates one workstation and its associated groups and attributes from those of another workstation. The unique logical key SMS uses to identify workstations is a combination of the Name, NetCardID, and SMSID attributes. (If you add a custom architecture, you will want to ensure that you use the Key statement to identify a unique set of Identification group attributes. Otherwise, SMS will use all attributes in the Identification Group as the key.)
The Start Attribute and End Attribute keywords delimit each attribute in a group. For example, in the Identification group in Listing 1 at F, EmployeeID is the 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 a unique integer within the group. Be consistent with the Attribute ID to ensure other DMI services can use your MIFs.
An attribute's Access statement (see Listing 1 at H) defines the type of access an application can gain to that particular field. SMS currently only parses this statement but doesn't use its value.
The Storage statement you see in Listing 1 at I defines how you store an attribute's value. If the Storage value is COMMON, the attribute's Value statement specifies the attribute's value, and SMS stores this value in a common SMS database reference table that all groups of this class share. For each instance of this group in the database, SMS stores a pointer to the value in the table for each common attribute. If the Storage value is SPECIFIC, SMS stores the attribute's value in the group record.
SMS stores three types of attributes: String, Integer, and Date. The Type statement 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 contains the value to be stored for the particular attribute. In the Employee component example, the EmployeeName attribute is a 30-character string that stores John Doe. Because names are usually unique, the Storage type is SPECIFIC.
Customizing SMS
SMS lets you add new groups to existing architectures and create new
inventory architectures. For example, you can add a User Information group to
the Personal Computer architecture to associate workstation inventory with a
user. 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 groups
in existing architectures with NOIDMIFs and IDMIFs, and you create new
architectures with IDMIFs.
Adding a Group with NOIDMIFs
NOIDMIFs let you add a group to the Personal Computer architecture. NOIDMIFs
contain no Identification group and no Architecture group because SMS merges
NOIDMIFs with standard Personal Computer inventory MIFs that already include
these 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 tool displays at a workstation. SMS saves your input to a NOIDMIF that SMS combines with the workstation's Personal Computer inventory. Listing 4 shows the NOIDMIF uinfo.mif, which was generated with SMS's default User Information MIF Entry Form. This form lets you add the User Information group to the Personal Computer architecture.
You can also create NOIDMIFs with a custom application or by using the Windows Notepad to create NOIDMIFs manually. As long as a NOIDMIF does not include an Architecture or Identification group and conforms to MIF syntax, SMS accepts it and merges it with the Personal Computer architecture MIF.
NOIDMIFs are useful but limited because they can add or update groups for only the Personal Computer architecture. Another limitation is that you must save NOIDMIFs on the workstation whose inventory you want to extend with the NOIDMIF.
Adding a Group with IDMIFs
IDMIFs contain both an Identification and an Architecture group (the example
MIF in Listing 1 is an IDMIF). IDMIFs let you add or update groups for existing
architectures the same way you use NOIDMIFs to add or update a group for the
Personal Computer architecture. IDMIFs also let you create new architectures and
add them to the SMS database.
Processing MIFs
After you create a MIF, you forward it to SMS for processing. SMS accepts
NOIDMIFs only on the client workstation in the \ms\sms\noidmifs directory. You
can 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 information
accessible only at the Logon server. Or save the IDMIF at the workstation if it
requires details that you can define only at the workstation. On the client
workstation, save IDMIFs in the \ms\sms\idmifs directory; on the Logon server,
in \sms\logon.srv\isvmif.box; and on the Site server, in
\sms\site.srv\isvmif.box.
After you forward the MIF to SMS, SMS moves the file to the Site server (if you 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 you can access it like any other inventoried component.
Let's Do It!
Now that you understand the basics of MIFs, you can customize SMS. Let's
look 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 and Architecture groups, you can define as many groups and attributes as you want. This example includes four groups: Identification (a required SMS group; the attributes are up to you), Architecture (a required group; the value of the Name attribute is up to you), Printer Details (your choice), and Printer Fonts (your choice). (DMTF has approved a printer MIF template with standard groups 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 repeating
groups by repeating the entire group for each instance. A Key statement in the
Identification group identifies the group's attributes that form the logical key
for the entire component. In groups other than the Identification group,
the Key statement identifies an attribute combination that forms the logical key
to identify instances of a repeating group. A repeating group, also known as a
table or replicated group, consists of elements that can
appear multiple times within one component instance.
For example, in Listing 1, the employee works in more than one location, so I've repeated the Employee Location group for each location instance. The Employee Location Key statement you see in Listing 1 at L specifies the Location Number (Key = 1, which is the ID value of the Location Number attribute) as the unique logical key to identify each location instance. Note that the ID value for each Employee Location group within the MIF must be unique for each instance of the repeating group. Otherwise, SMS will think the repeating group blocks refer to the same group instance and subsequent group values will simply update the 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 block is a convenient way to report repeating groups (such as printer fonts--a Printer object can have multiple resident fonts) in a MIF. In Listing 5, the Printer Fonts table captures printer font information.
Notice that the Printer Fonts group block (not the table block) has no ID statement. This group functions as a template for the Printer Fonts table, which includes Name and Class statements with the same values as the template. Each set of braces (\{ \}) represents an instance of the repeating group and contains values for the attributes in that instance. When you list the attributes within the braces, you must separate attribute values with a comma and place them in the order that matches the numeric order of the attribute IDs in the group template (e.g., font type, resident font). Default values fill missing values within the braces. The group template specifies these defaults. For example, the last instance in the Printer Fonts table lacks a value for the Resident Font attribute. Because the template contains the value Arial Bold Italic for this attribute, 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 name
is p1000000.mif in the example) and place it in sms\site.srv\isvmif.box to
expedite 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 the
object the MIF describes; use .nhm if you don't want to maintain history). After
SMS processes the first MIF for the new architecture, you must exit and restart
SMS Administrator (if it was running when you created the architecture) so it
can display inventory for that architecture. Once you establish the new
architecture within the SMS Administrator, you can use the refresh option to
display new instances of the architecture.
You can easily display a new architecture, such as the printer, in the SMS Administrator Sites window by including several attributes in the MIF's Identification group. These attributes, Name, Site, Domain, and SystemRole, are in the example printer Architecture you see in Listing 5. You can add SystemType, which gives you more bitmap and icon choices in SMS Administrator if you use custom bitmaps and icons. If these attributes aren't present, SMS collects the inventory but doesn't display it in the Sites window. However, you can use SMS's Query facility to access the new Architecture. For example, the Employee architecture in Listing 1 won't display in the Sites window because it lacks the required attributes in the Identification group.
Screen 1 shows the SMS Administrator Sites window. In SMS, a default bitmap represents the printer inventory object this example creates (HP Printer 1). Opening the Properties window for HP Printer 1 displays the Printer Properties window, as you see in Screen 2. The printer groups (Printer Details and Printer Fonts) appear as a default SMS icon.
Coming Up Next
My next article will explain how to polish custom architectures by using
custom bitmaps and icons for display in the SMS Administrator. Subsequent
articles will explain how to use MIFs and the SMS API to create new applications
or to integrate existing apps with SMS, and how to access SMS information and
functions through the Internet.
| TABLE 1: MIF Block Types | ||
| Definition- Block Type |
Within | Description |
|
| ||
| Component | MIF | Defines a component. All other blocks exist within this scope. Each MIF usually has only one component definition. |
| Group | Component | Defines a collection of attributes, sometimes used as a template row for a table. SMS requires two special groups for each MIF: Architecture and Identification. |
| Attribute | Group | Defines a unit of managed data. All attributes exist within the scope of a group definition. A group must have at least one attribute. |
| Table | Component | Defines one or more instances of a group using a previously defined group template. Optional. |
