The Data Collection and Storage Process
This strategy tacks on additional information to the Personal Computer inventory through an external process after the standard inventory process creates the record in the SMS database. The standard inventory process continues to periodically collect inventory for each workstation and update the SMS database to reflect any changes that might occur. You need to consider how this collection process might affect any additional groups that you add through the IDMIF.
When SMS's standard inventory process collects inventory, it always creates a MIF containing the complete inventory of the workstation. SMS maintains a history file, which contains the last version of the standard inventory MIF that SMS collected. SMS's Maintenance Manager eventually transfers the new MIF to the SMS Site Server, where the Inventory Processor compares the new MIF to the old one and creates a Delta-MIF containing only the net changes in inventory. This process results in several possibilities:
- If a previously recorded group is not present in the new MIF, SMS assumes you have deleted the group. The Delta-MIF contains instructions that delete the group from the workstation's current inventory. The group icon will remain in the Personal Computer Properties window because the history for the group is present but all the current attributes will be null.
- If a new group is present in the new MIF, the Delta-MIF adds that group to the workstation's inventory.
- If a new attribute is present for an existing group, the Delta-MIF appends that attribute to the group in the database.
- If a previously recorded group attribute is not present in the current MIF, SMS assumes the missing attribute is null.
Consider that your IDMIF contains the Architecture, Identification, and Employee Information groups, but none of the other groups (e.g., Network Card) that are usually present. If the Inven-tory Processor compares your current IDMIF to the previous standard inventory MIF, the Delta-MIF will delete the original groups, causing null values to appear in the Personal Computer Properties window for these groups. The opposite occurs when the Inventory Processor compares a new update of the standard inventory MIF to a previous IDMIF. Null values will appear for the Architecture, Identification, and Employee Information groups.
A History Lesson
To overcome the problem of null values, you need to understand how SMS stores the histories of prior MIFs. As mentioned previously, the Inventory Processor maintains a record of the last MIF received for each client workstation. SMS stores this history in the sms_install_drive:\sms\site.srv\inventry.box\history subdirectory on the SMS Site Server.
Listing 1 shows an example directory listing of the history subdirectory. Let's examine how the history process works. This history subdirectory has not only a Personal Computer architecture, but a Printer architecture. Specifically, it contains the Personal Computer architecture that you created for the Excel distribution, plus a Printer architecture that two previous SMS articles discussed (Mark Eddins, "Customizing Systems Management Servers," January 1997, and Mark Eddins, "Customizing Graphics for SMS Custom Inventory Objects," March 1997). Listing 2 contains an excerpt from the Personal Computer architecture, and Listing 3 contains an excerpt from the Printer architecture.
If SMS uses a *.raw binary file (which Microsoft clients use) to collect a history for a standard inventory MIF (i.e., if SMS uses a *.raw MIF), SMS maintains the history in a *.hms file. This file will have the name workstation_smsid.hms, where workstation_smsid is the unique SMSID from the identification group. (When you install the SMS client software, it assigns each workstation an SMSID, which is a unique ID number.) For example, one history file in Listing 1 has the name S0001000.hms.
SMS maintains the history for an IDMIF in two related files. First, SMS creates a *.smh file, which contains all the groups in the MIF except the Architecture and Identification groups. SMS generates a unique 8-digit sequential number for the name of the history file and adds the extension .smh. The filename 00000001.smh in Listing 1 is an example of this type of file.
Then, SMS creates a history.map file, a shared file that contains only the Architecture and Identification groups. This file contains a record for each unique MIF component. (SMS determines uniqueness by the Identification group entries.) SMS segregates the entries by architecture.
For example, the following is an excerpt from the history.map file for the IDMIFs:
[Printer]
Printer ID:P1000000|=00000000.smh
[Personal Computer]
Name:USNE01W01|NetCardID: 00:40:05:1a:4f:11|SMSID:S0001000|=00000001.smh
In this instance, SMS lists two distinct architectures: the Printer architecture and the Personal Computer architecture. The single record in the Printer architecture listing tells you that SMS collected inventory through an IDMIF for only one printer. This record shows that SMS collected information keyed on the Identification group attribute of Printer ID, which had the value P1000000. The pointer (represented by =) tells you that SMS has stored the history information for the other groups in the 00000000.smh file.
The single record in the Personal Computer architecture listing specifies that SMS collected inventory through an IDMIF for only one personal computer. The record shows that SMS collected information keyed on the Identification group attributes of Name (value of USNE01W01), NetCardID (value of 00:40:05:1a:4f:11), and SMSID (value of S0001000). These are the standard key attributes for the Personal Computer architecture provided by SMS. The pointer tells you that SMS has stored the history information for the other groups in the 00000001.smh file.
When SMS collects a new IDMIF, it compares the newly collected Identification group key attributes to those in the records within the history.map file. This comparison lets SMS determine whether the IDMIF includes a new inventory component or is updating an existing one.
Technically speaking, you can consider a *.raw file as an IDMIF because the file includes Architecture and Identification groups. For simplicity, the IDMIFs mentioned here are referring to ASCII MIF files for Macintosh and OS/2 clients.
Why These Custom IDMIFs Work with Microsoft Clients, but Not Others
Because SMS compares a new IDMIF file to the *.smh and history.map files and because SMS compares a new *.raw MIF file to the *.hms file, the Delta-MIF process does not compare the IDMIF file's and *.raw MIF file's unique groups with each other. So when SMS compares a new *.raw MIF to the *.hms file, the comparison doesn't affect the Employee Information group because that group isn't in the *.HMS history file.
Similarly, when SMS compares a new IDMIF file to the *.smh and history.map files, the comparison doesn't affect the standard inventory Personal Computer groups. As a result, you don't get any null values when using IDMIFs with MS-DOS, Windows 3.x, Win95, and NT client workstations.
For Macintosh and OS/2 clients, SMS does not use *.raw files. Rather SMS creates IDMIFs and places them on the ISVMIF.BOX on the Logon Server. From this point, SMS processes them as IDMIFs, complete with *.smh and history.map files.
So when SMS compares your custom IDMIF to the *.smh and history.map files created through standard inventory, you'll get null values for all groups except the Identification and Employee Information groups. If you then have SMS compare a new standard inventory file to the *.smh and history.map files, you'll get a null value for the Employee Information group, but display values for all the other groups.
Fortunately, you can fix this problem in Macintosh and OS/2 clients. If you change the file extension for the IDMIF file to *.nhm, SMS will skip the delta processing for the MIF and immediately update the current inventory record in the SMS database with the data in the IDMIF.
This solution has one drawback. When you use a *.nhm MIF for the custom IDMIF, SMS will not maintain a history for the Employee Information group. However, all standard inventory groups will continue to have a history.
A Special Delivery
You are now ready for your special delivery. You have integrated HR data into the SMS database so that it includes employee ID numbers. You have queried the updated SMS database to get the information you need to distribute the Excel program to the intended 50,000 accountants. And you have fixed the file extension for the custom IDMIFs for those employees on Macintosh and OS/2 client workstations. Now all you have to do is sit back and relax while 50,000 accountants automatically receive their Excel software.
End of Article
Prev. page
1
[2]
next page -->
