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.