Management Information Format files
categorize SMS inventory listings
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.