The only change to the format of IDMIF and NOIDMIF files from SMS 1.2 to SMS 2.0 is the addition of a delta header to IDMIF files. A delta header is a set of comments that identify the custom MIF within the system and cause certain behavior within the SMS site database, as described later in this chapter in “Adding Delta Headers to SMS 1.2 IDMIF Files.”
To use hardware inventory customization data created for SMS 1.2 with SMS 2.0, complete the tasks described in these sections:
SMS 2.0 hardware inventory collects much more information than SMS 1.2 hardware inventory. As a result, some of the properties you collected using custom MIF files for SMS 1.2 might be collected by the default hardware inventory process in SMS 2.0, or you might be able to modify SMS_def.mof to collect these properties rather than creating and using custom MIF files. Compare the properties in your SMS 1.2 custom MIF files to a list of the properties that can be collected in SMS 2.0 and remove duplicate properties from the custom MIF.
To view a list of currently collected properties, as well as a list of properties that you can collect, open the SMS_def.mof file within the MOF Manager tool described in Chapter 10, “Customizing Hardware Inventory.” Compare the properties currently being collected (shown in green) with existing IDMIF and NOIDMIF files and then delete any duplicate properties and classes from the MIF files. Review the unselected properties that can be collected (shown in red) and compare them with your existing custom MIF files. Activate any properties you want to collect and then delete them from the custom MIF files.
If there are any properties that are still not being collected, you can upgrade your custom MIF files from SMS 1.2 to SMS 2.0, as described in the following sections.
When you upgrade SMS 1.2 IDMIF files to SMS 2.0, you must add a delta header. The SMS system uses this set of comments placed at the top of the file to make changes in the SMS site database.
An IDMIF file has three required properties; the others are optional. You must include the name of the architecture you want to create or modify, the agent name that is modifying or creating the architecture, and a unique identifier. The unique identifier can be any unique identifier, such as a social security number (SSN) for a person or a vehicle identification number (VIN) for a vehicle.
If you want to define an entirely new architecture, you must include a name for the new architecture, a unique identifier, and the agent name, which can be your name if you are creating the architecture.
The limitations are shown in Table 6.1.
Table 6.1 IDMIF Header Comments
| MIF header comment | Required | Function |
|---|---|---|
| //AgentID <agent name> | No | The name of the agent that produced the custom MIF file. You can specify your name or the name of an application that produced the custom MIF. AgentID is most useful when more than one agent is expected to change an architecture. AgentID must be set if either the ResyncAgent or ResyncClass header comments are set to 1. |
| //FullResync<0> | No | A value of 1 causes a full resynchronization of this architecture for this instance (this UniqueID). A value of 0 allows a delta (a change of this architecture for this instance). This field is most useful for completely replacing an instance of an IDMIF or for erasing any information that might remain in the database after you have stopped using a particular IDMIF. |
| //ResyncAgent<0> | No | A value of 1 causes an agent resynchronization, a replacement of all the values added by this agent to this architecture in the database with the results of this IDMIF. ResyncAgent field is most useful with large or complicated IDMIF files. |
| //ResyncClass <class name><1> | No | A value of 1 causes an agent resynchronization of the specified attribute class in the database, which completely replaces all elements of this attribute class created by this agent with the contents of this IDMIF. A value of 0 represents the complete replacement of the class with the contents of the MIF. ResyncClass is most useful with large or complicated IDMIF files. |
| //Architecture <architecture name> | Yes | The name of the architecture. When you create a new architecture, the architecture is created within the SMS site database with the name you provide. |
| //UniqueID <unique value> | Yes | The single value that uniquely identifies this instance in the SMS site database. This value can be the GUID or SMSID of a specific client or some other unique number, such as a SSN for a person or a VIN for a vehicle. |
NOIDMIF files are always associated with a single client. You always place NOIDMIF files in a directory on the client.
%Windir%\MS\SMS\Noidmifs
IDMIF files are usually not associated with a client, but represent some non-client entity in the database. Place IDMIF files in the following directory on the client:
%Windir%\MS\SMS\Idmifs
For information about using IDMIF and NOIDMIF files, see Chapter 10, “Customizing Hardware Inventory.”