Chapter 10 - Customizing Hardware Inventory

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Customizing hardware inventory means changing the default set of classes and properties that Systems Management Server (SMS) version 2.0 collects from every SMS client during hardware inventory. Typically, you direct SMS to collect properties and classes that are important to your organization, but are not part of the default hardware inventory process. Or, you can eliminate properties and classes that are part of the default inventory process, but are not important for your organization.

Besides using hardware inventory to collect hardware information, you can customize it to create entirely new architectures. Such architectures can be used to monitor assets, such as vehicles and other equipment, using the SMS site database.

Before you customize hardware inventory, you should become familiar with Windows Management Instrumentation (WMI) and the 32-bit hardware inventory process as described in the "WMI and the Hardware Inventory Process" section of this chapter. Note that the 16-bit SMS 2.0 hardware inventory feature cannot take advantage of the WMI services, and so uses a different process. This process is described in "Details of the 16-Bit Hardware Inventory Process" later in this chapter.

After you understand the hardware inventory process, you can customize this process in one of the following ways, as explained later in this chapter:

• Customizing the SMS_def.mof file 

• Customizing with NOIDMIF files 

• Customizing with IDMIF files 

This chapter also contains the following sections:

• Associated Users with Their Computers 

• Customizing More Than One Client 

• Using Information from IDMIF Files and NOIDMIF Files 

This chapter assumes that you have a basic understanding of SMS in general, and SMS hardware inventory in particular. For more information about SMS hardware inventory, see Chapter 10, "Collecting Hardware and Software Inventory," in the SMS 2.0 Administrator's Guide.

WMI and the Hardware Inventory Process

The hardware inventory process uses the WMI service to collect hardware information from each client within an SMS site hierarchy and to pass this information to the central site server for inclusion in the SMS site database.

To customize hardware inventory, you should first become familiar with the hardware inventory process and the role of the WMI service in 32-bit hardware inventory. This section describes the following :

• WMI and 32-bit hardware inventory 

• Details of the 32-bit hardware inventory process 

WMI and 32-Bit Hardware Inventory

The 32-bit SMS 2.0 hardware inventory feature provides its functions through the Common Information Model (CIM) Object Manager, which is part of the WMI service. WMI is one of several Windows management services.

Note As mentioned earlier, the 16-bit SMS 2.0 hardware inventory feature cannot take advantage of the WMI services. For this reason, it uses a different process for hardware inventory, which is described in "Details of the 16-Bit Hardware Inventory Process."

Windows management services are extensible services that, when extended in lieu of writing custom features, lower the total cost of ownership of Windows and increase the manageability of the environment. SMS is built upon Windows management services.

As shown in Figure 10.1, Windows management services consist of the following:

• The Microsoft Management Console (MMC) 

• The Windows 2000 Active Directory service 

• The Windows Script Host (WSH) 

• The WMI service 

 

Figure 10.1 Windows Management services 

WMI is the Microsoft implementation of the Desktop Management Task Force (DMTF) Web-Based Enterprise Management (WBEM) initiative. WMI provides a single point of access through which consumer application components, such as the SMS hardware inventory process, can interact with managed entities, such as client computers and servers. This interaction consists of changing the attributes and attribute classes associated with these entities that are located in the SMS site database. Thus, WMI provides a consolidated interface for inventory and instrumentation of the operating environment. As a result, applications such as the SMS Administrator console can take advantage of WMI's central access point for accessing all their data.

Note The terms "property" and "attribute" as used in this chapter are synonymous. Generally, the term "property" is more common when referring to user interfaces, and the term "attribute" is more common when referring to database entries.

To understand WMI, you should be thoroughly familiar with the following elements:

CIM Repository 

A data store where WMI stores schema and provider information from a number of sources.

These sources can include the registry, the Win32 API, or databases such as the SMS site database. This design makes it possible to provide single point of access for all the management information for a specific system.

CIM Object Manager 

The coordinator of information exchange among client applications, the CIM Repository, and the providers.

The CIM Object Manager supports services such as event notification, remote access, and query processing, and it grants WMI consumer applications access to the CIM Repository.

Providers 

Suppliers of information about managed objects within their domains for WMI consumer applications through the CIM Object Manager.

The CIM Object Manager receives the following types of requests from a consumer application:

• Data that is unavailable from the CIM Repository 

• Notification of an event that the CIM Object Manager does not support 

When a request is received from a consumer application, it is forwarded to a provider. Providers supply data about and notifications for managed objects in the provider's particular domain. Although providers can be executable files or dynamic-link libraries (DLL) files, the providers that are used with SMS are DLLs that are loaded into the WMI service (WinMgmt.exe) when the service is started.

Consumer applications 

Applications that request and receive information from one or more managed objects through WMI.

To obtain needed information, a consumer application makes a request for information from the CIM Object Manager. The CIM Object Manager forwards the request to the correct provider, and the information is returned from that provider. For example, applications such as the SMS Administrator console and the SMS hardware inventory process are consumer applications.

With WMI technology, consumer applications can perform a wide range of tasks, such as producing network inventory reports, displaying system information, responding to events, and starting or stopping system services.

As shown in Figure 10.2, the CIM Object Manager can be thought of as a translation program that takes requests from a number of consumer applications such as the SMS hardware inventory process and the SMS Administrator console, and then fills those requests by obtaining the information from one of a series of providers.

 

Figure 10.2 Consumer Applications, Providers, and the CIM Object Manager 

The SMS hardware inventory process uses two providers within the WMI service: the Win32 Provider and the SMS Provider. The Win32 Provider is part of the basic WMI service, while the SMS Provider is an SMS add-on.

The hardware inventory component uses the Win32 Provider to access hardware properties when collecting inventory. When the inventory file reaches the primary site server, these properties are stored in the SMS site database as SMS Provider properties. The SMS Provider includes a corresponding property for each Win32 Provider property that is collected by hardware inventory. During the processing of Management Information Format (MIF) files at the primary site server, Win32 Provider properties are translated into SMS Provider properties before they are stored in the SMS site database.

Details of the 32-Bit Hardware Inventory Process

In the SMS 2.0 Administrator's Guide, the 32-bit hardware inventory process is described at a high level. As mentioned earlier, you should be familiar with that information before you read this chapter. To customize hardware inventory, you need to be familiar with the process at a much more detailed level, as described in this section. This section describe the SMS components that perform hardware inventory and lists the directories and files that you should be familiar with.

When you enable the hardware inventory feature in the SMS Administrator console, SMS installs the Hardware Inventory Client Agent (Hinv32.exe) on each client, and the client agent directs the Mofcomp.exe program to compile a file called SMS_def.mof (located in the %Windir%\MS\SMS\Sitefile\<SiteCode>\Hinv directory on the client) into the CIM Repository to set the default values for hardware inventory.

32-Bit Processing on the Client

Hardware inventory is configured for the entire site on the site server, but it is collected on the client. When initial hardware inventory begins, Hinv32 queries the CIM Object Manager for the inventory values to collect. The CIM Object Manager starts the appropriate provider for each class, retrieves the current value, and then passes it to the Hardware Inventory Client Agent.

Note In this chapter, path names are expressed using SMS share names and environment variables, because the exact path names depend on where you install the software. The following share names will be used to indicate the top-level directories of the SMS installation:

Site server: \\<ServerName>\SMS_<SiteCode>

Client: %Windir%

Client access point (CAP): \\<ServerName>\CAP_<SiteCode>

As shown in Figure 10.3, the hardware inventory process includes three stages. First, inventory is taken and the file is created and checked on the SMS client computer. Second, the file is transferred to the CAP, where it awaits transfer to the site server. At the site server, the file is again checked, then the information is stored in the SMS site database.

 

Figure 10.3 32-Bit Processing on the client 

NOIDMIF file processing

Next, Hinv32 checks the following directory on the client for the existence of any NOIDMIF files (NOIDMIF files are custom MIF files that the Hardware Inventory Client Agent processes on the client to extend the hardware inventory classes of that client):

%Windir%\MS\SMS\Noidmifs

Any file in this directory that has the .mif extension is checked in the following two ways:

The file is checked for size. 

Hinv32 reads each file and first verifies that the file is smaller than or equal to the maximum size for a third-party MIF file on the client. A third-party MIF file is a custom MIF file not created by SMS. The default value for the maximum size is 250 KB. The maximum file size is held in the following registry key:\HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \SMS \Client \Sites \System<SiteCode>\Client Components\Hardware Inventory Agent\Maximum 3rd Party MIF Size

Hinv32 attempts to parse the file. 

If the file passes the test for size, Hinv32 attempts to parse the file. If the file can be parsed successfully, Hinv32 writes the contents of the file to the CIM Object Manager.

If the file passes both of these tests, it is included with the inventory.

If the NOIDMIF file fails either of these tests, Hinv32 writes the file to the following directory on the client:

%Windir%\MS\SMS\Noidmifs\Badmifs

Next, Hinv32 enumerates hardware inventory instances in the CIM Object Manager and writes these instances and the instances from any valid NOIDMIF files to a temporary file, either a *.hic file or a *.hid file.

Hic files 

If this is the first time hardware inventory has been run, Hinv32 enumerates all of the hardware inventory instances and NOIDMIF file instances and writes them to a temporary file. Then, Hinv32 renames the temporary file to a unique name with the .hic extension. This file is called a complete hardware inventory file. Next, Hinv32 stores the file as a temporary file (the temporary files are deleted when the hardware inventory process is completed on the client) in the following location:%Windir%\MS\SMS\Clicomp\Hinv\*.hic

Hid files 

If hardware inventory has been run before, Hinv32 enumerates the instances that have changed since the last hardware inventory and adds the changed information from any NOIDMIF files. Hinv32 writes the information to a temporary file, and renames the temporary file to a unique name with the .hid extension. This file is called a delta hardware inventory file, and it is stored in the following location: %Windir%\MS\SMS\Clicomp\Hinv\*.hid

Note The *.hic, *.hid, and *.inv files only exist for seconds on a client computer. Typically, you will not see these files on the client.

Hinv32 renames the .hic or .hid filename extension to a *.inv filename extension because Copy Queue Manager requires it. Then, it copies the file as a temporary file to the following directory:

%Windir%\MS\SMS\Clicomp\Hinv\Outbox\*.inv

IDMIF file processing

At this time Hinv32 checks the following directory for IDMIF (*.mif) files:

%Windir%\MS\SMS\Idmifs

IDMIF files are custom MIF files that you can use to create entire new architectures or to update existing architectures in the SMS site database. IDMIF files are given the following checks on the client:

The file is checked for size. 

If an IDMIF file resides in the Idmifs directory, Hinv32 reads the file and verifies that the file is smaller than or equal to the maximum size for a third-party MIF file on the client. The default value for the maximum size is 250 MB. The maximum file size is held in the following registry key:\HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \SMS \Client \Sites \System<SiteCode>\Client Components\ Hardware Inventory Agent\Maximum 3rd Party MIF Size

Hinv32 attempts to parse the file. 

If the file passes the test for size, Hinv32 attempts to parse the file.

The file is checked for database integrity problems. 

In order to be valid, the custom MIF file must not add, delete, or update any instance of the System architecture (SMS 2.0 System Resources) or the Personal Computer architecture (SMS 1.2 computer architectures) in the SMS site database. Instead, use NOIDMIF files to modify the System architecture. This rule is enforced to prevent unauthorized users from modifying hardware information in the SMS site database.

If the IDMIF file fails any of these tests, it is sent to the following directory:

%Windir%\MS\SMS\Idmifs\Badmifs

Further processing for inventory files

Hinv32 renames all 32-bit MIF files that are returned from hardware inventory on a 32-bit client to no history MIF (*.nhm) files. The IDMIF files are not renamed and remain *.mif files.

In 32-bit hardware inventory, history is kept on the client, and the files are renamed so that history will not be retaken on the server. On the server, history is kept on any file with the .mif extension.

32-Bit Processing on the CAP

The role of the CAP in 32-bit hardware inventory processing is simply that of a mailbox that receives hardware inventory files and then stores them until they are transferred to the site server. Components on the client and the site server perform the processing.

The Copy Queue Manager on the client computer (Cqmgr32.dll) moves *.inv files to the following directory on the CAP:

\\<ServerName>\CAP_<SiteCode>\Inventry.box

At system-defined intervals, Inbox Manager Assistant on the site server moves the *.nhm and *.mif files from the CAP to the following directory on the site server:

\\<ServerName>\SMS_<SiteCode>\Inboxes\Inventry.box

32-Bit Processing on the Site Server

At the site server, the Inventory Processor receives the *.nhm files and *.mif files from the CAP and collects history on any .mif files. Then, the Inventory Processor renames the no history MIF filename extension (*.nhm) to the *.mif filename and moves the *.mif files to the following directory:

\\<ServerName>\SMS_<SiteCode>\Inboxes\Dataldr.box

From this point, the processing of IDMIF files is identical to the processing for hardware inventory files.

Inventory Data Loader is started any time files are waiting in the Dataldr.box directory. The Inventory Data Loader component immediately moves the files to the following directory on the site server:

\\<ServerName>\SMS_<SiteCode>\Inboxes\Dataldr.box\Process

Inventory Data Loader then performs the following checks on the MIF files:

The files are checked for size. 

On the site server, the aggregate size of MIF files for a single client cannot exceed the value found in the following registry key:\HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \SMS \Components \SMS_INVENTORY_DATA_LOADER \Max MIF SizeThe default value for the maximum size is 5 MB.

Inventory Data Loader attempts to parse the files. 

If the file passes the test for size, Inventory Data Loader attempts to parse the files.

If either of these tests fails, Inventory Data Loader moves the MIF files to the following directory:

\\<ServerName>\SMS_<SiteCode>\Inboxes\Dataldr.box\Badmifs

Note By default, MIF files in the Badmifs directory are deleted after 14 days. You can change this default value. The value is held in the following registry key:

\HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \SMS \Components \SMS_INVENTORY_DATA_LOADER \Delete Bad MIFs Older Than (Days) 

Then, if the MIF files have passed the Inventory Data Loader checks, Inventory Data Loader writes the MIF files to the SMS site database. If the write is not successful, Inventory Data Loader checks whether the client exists in the SMS site database. If it does, Inventory Data Loader checks whether the discovery data record file (*.ddr) has been processed by Discovery Data Manager for this client. If not, or if the client does not exist in the SMS site database, Inventory Data Loader creates a DDR for the client and moves the MIF file to the following directory to wait for the DDR:

\\<ServerName>\SMS_<SiteCode>\Inboxes\Dataldr.box\Orphans

If the file passes the syntax check but has not yet been written to the SMS site database, Inventory Data Loader tries again every 10 minutes.

After Inventory Data Loader updates the SMS site database statistics, processing at the primary site is completed. If the primary site is not the central site, Replication Manager forwards the MIF files to the following directory on the parent site:

\\<ServerName>\SMS_<SiteCode>\Inboxes\Dataldr.box

The files are processed and stored in the same way at each primary site server between the local primary site and the central site.

After hardware inventory runs for the first time, it runs again on a schedule that you configure. The default schedule is to run seven days from the initial inventory, and every seven days thereafter. You can change this default schedule in the SMS Administrator console by changing the properties of the Hardware Inventory Client Agent. You can choose a simple schedule of running at hourly, daily, or weekly intervals, or you can use a full schedule to choose a specific date and time.

Under the full schedule, every client within the site reports inventory at approximately the same time. Under the simple schedule, inventory reporting is staggered because clients are usually installed at intervals. You can use the simple schedule to stagger network traffic, or use the full schedule to run simultaneous inventories at off-peak hours.

SMS keeps historical hardware inventory records for the number of days that you specified in the Delete Aged History database maintenance task. For information about maintaining historical hardware inventory records, see Chapter 19, "Maintaining SMS Systems," in the SMS 2.0 Administrator's Guide.

Details of the 16-Bit Hardware Inventory Process

Hardware inventory configuration is generally the same for 16-bit and 32-bit clients; however, the 16-bit clients are more limited in features. The processing is also the same, except for the differences noted in this section. For more information about hardware inventory, see Chapter 10, "Collecting Hardware and Software Inventory," in the SMS 2.0 Administrator's Guide and Chapter 20, "Hardware and Software Inventory Flowcharts" in this Resource Guide.

You cannot use the WMI technology to run hardware inventory on 16-bit clients. Also, 16-bit clients do not support IDMIF file processing. You can use NOIDMIF files with 16-bit clients, but there is no syntax checking on the client. If you have a 16-bit NOIDMIF file with a class that has more than one instance, you must include at least one key property within that class to avoid having subsequent instances overwrite the previous instance. The process provides these keys for 32-bit NOIDMIF files but not for 16-bit NOIDMIF files.

Inventory files for 16-bit clients are submitted as *.raw files. History for 16-bit clients is maintained at the site server. The *.raw files processed for 16-bit clients are reformatted into MIF file format and renamed to *.mif files at the site server. These files are appended in text format to the SMS site database record for that client.

Customizing the SMS_def.mof File

The default SMS_def.mof file provided by SMS contains an extensive list of hardware classes that you can either enable or disable by modifying this file. This file enables you to collect the most common properties for hardware inventory (for example, memory, disk, video, and processor, and so on). You can customize this file so that you collect only the set of attributes you need for your installation.

Using MOF Manager to Customize the SMS_def.mof File

By using MOF Manager to modify the SMS_def.mof file, you can:

• Collect any of the classes and properties that exist in the SMS_def.mof file but are not being collected by default. 

• Stop collecting any class or property that you do not need.

• Enable or disable each class. If a class is deactivated, none of its properties are collected. If a class is activated, the key properties of the class are collected, as well as the properties that are enabled (SMS_Report flag is equal to TRUE). 

Note If you do modify the SMS_def.mof file or create custom MIF files to add information to the client inventory, consider the performance effects. Adding certain information (for example, adding the Win32_LogEvent class and the Win32_Directory class) can slow system performance appreciably.

Whenever you change the SMS_def.mof file, you must replace the current file with the new file in the following directory on the site server:

\\<ServerName>\SMS_<SiteCode>\Inboxes\Clifiles.src\Hinv

The next hardware inventory will be collected according to your instructions. Do not place custom SMS_def.mof files on the client or the CAP. If you do so, they will be overwritten and only used temporarily. At each inventory cycle, the SMS_def.mof on the server is compared with the copy on the client, and if these copies are different, the copy on the server is replicated to the client and overwrites any custom Management Object Format (MOF) file found there.

The MOF Manager is an easy-to-use tool with an intuitive user interface. This tool is provided in the following directory on the Microsoft BackOffice 4.5 Resource Kit CD-ROM:

%BORK%\SMS\<Platform>\MOFman

To install MOF Manager on a site server 

• Run the Setup program. 

• When you first open MOF Manager, you must choose a file to modify.

  For best results, modify the SMS_def.mof file on the site server by opening the copy from the following directory: 

  \\<ServerName>\SMS_<SiteCode>\Inboxes\Clifiles.src\Hinv 

Copies of the SMS_def.mof file also exist on the client, but do not modify them. These copies get overwritten each time inventory runs.

To run MOF Manager 

1. On the Start menu, point to Programs Resource Kit and then click Tools Management Console. 

2. Navigate to Microsoft Resource Kits\Systems Management Server\Discovery and Inventory Tools\MOF Manager Tool. 

3. Double-click the Mofman icon. 

MOF Manager has a graphical user interface that displays all the attribute classes in the Class List pane and all the individual attributes in the Property List pane. Attributes that are currently set to TRUE (being collected by hardware inventory) appear in green. Attributes that are currently set to FALSE appear in red.

To change the status and color of any entry in the Property List pane 

• Double-click the entry you want to change.

To enable reporting for an attribute class 

• Click the class in the Class List pane and then click Yes for the Report option.

  When the attribute class is reported, only the properties where the Key value is True are reported, unless you enable the other properties manually. 

To open a MOF file 

 

• Click the Open button, and then navigate to the MOF file you want to open. The SMS_def.mof file resides on the site server in the following directory: 

  \\<ServerName>\SMS_<SiteCode>\Inboxes\Clifiles.src\Hinv 

  Save the new MOF file only on the site server. As mentioned earlier, MOF files placed anywhere else will be overwritten whenever hardware inventory is run. 

To save the new MOF file 

 

• Click the Save button.

  Save the file as SMS_def.mof in the following directory, or save it elsewhere and then move it to this location when you want to use it for inventory: 

  \\<ServerName>\SMS_<SiteCode>\Inboxes\Clifiles.src\Hinv 

To enable or disable all the classes or properties within a class 

 

To change an attribute value 

• Double-click the attribute. 

To change a class value 

• Double-click the class in the Class List pane, and then double-click each attribute you want to change in the Property List pane.

To collect all the attributes 

• Click Option, click the class, point to Property, and then click Report All. 

To quit MOF Manager 

 

• Click the Exit button. 

For information about the specific attribute classes and properties in the SMS_def.mof file, see Appendix C, "Hardware Inventory Classes." You can also find additional information about the SMS_def.mof file in the SMS 2.0 Toolkit.

Other Ways to Customize the SMS_def.mof File

Using MOF Manager is the most common way to customize the SMS_def.mof file. However, you can also change this file by doing the following:

• Using any text editor to change the SMS_Report flags. 

• Using any third-party tool. 

Each attribute has a property called the SMS_Report flag. To collect a property or class, set the SMS_Report flag to TRUE. To end the collection of a property or class, set the SMS_Report flag to FALSE. For more information, see Chapter 10, "Collecting Hardware and Software Inventory," in the SMS 2.0 Administrator's Guide.

Customizing with NOIDMIF Files

As mentioned earlier, NOIDMIF files are custom MIF files that the Hardware Inventory Client Agent processes on the client to extend the hardware inventory classes of that client. Often, these files are part of a third-party application, but an administrator can also prepare these files. The administrator or the application moves these files to a target directory on the client:

%Windir%\MS\SMS\Noidmifs

On the client, Hinv32 processes NOIDMIF files during the hardware inventory cycle, and then adds information to the inventory file that is forwarded to the primary site server.

If the classes do not already exist on the primary site server, Inventory Data Loader creates the new classes on the existing architectures. After that, inventory for that client will include the new classes by processing the NOIDMIF file each time inventory is run. For example, if a NOIDMIF file creates a class called Asset Number, that custom MIF file causes Inventory Data Loader to create that class. Each time inventory is run, the Hardware Inventory Client Agent processes the NOIDMIF file again and replaces any values that have changed. If the NOIDMIF file is removed from the target directory, all the classes and attributes will be deleted by the next hardware inventory.

NOIDMIF files are always associated with a single client. You always place NOIDMIF files in the Noidmifs directory on the client.

To customize a single client by using a NOIDMIF file 

1. Place the NOIDMIF file in the client's %Windir%\MS\SMS\Noidmifs directory. For example:

   copy test.mif c:Windows\MS\SMS\Noidmifs
   

The next time hardware inventory runs, the NOIDMIF file will be included in the process and the new attributes and classes will be added to the SMS site database. 

Creating an Attribute by Using a NOIDMIF File

The most common way to use a NOIDMIF file is to create a new attribute that cannot be collected with inventory, and then store it in the SMS site database. For example, before SMS 2.0 was installed on their network, Wide World Importers catalogued each computer in the organization by using a company-assigned asset number. These numbers were assigned and collected by hand. With SMS, administrators from Wide World Importers can use a NOIDMIF file to add the asset number for each client computer to its other information within the SMS site database, so that it can be available for queries and asset management. Because the asset number can then be associated with collected inventory properties, much more information is always available to administrators. The following sample NOIDMIF file, whose format (created by Wide World Importers to add a class called Wide World Asset Numbers to the record for a client) is similar to the format of a NOIDMIF file that adds a single attribute, illustrates this process:

Start Component
Name = "System Information"
Start Group
Name = "Wide World Asset Numbers"
ID = 1
Class = "wideWorldAssetNumbers"
Key = 1
Start Attribute
Name = "Computer Asset Number"
ID = 1
Type = String(10)
Value = "414207"
End Attribute
End Group
End Component

Note The value is stored as a string because commas are automatically inserted in values with the integer data type. If it were stored as an integer, the asset number's value would change.

You can create NOIDMIF files by using the MIFgen tool provided on the Microsoft BackOffice 4.5 Resource Kit CD-ROM, or you can create them by using any text editor. For more information about MIFgen, see Chapter 13, "Using SMS 2.0 Tools — Part 1," and Chapter 14, "Using SMS 2.0 Tools — Part 2."

To create such a NOIDMIF file, use the following procedure.

To create a NOIDMIF file to add the Wide World Asset Numbers class 

1. Type the following line to begin the NOIDMIF file: 

   Start Component
   

You must always add a component and name the component when you create a NOIDMIF file. 

2. Type the following line to name the component: 

   Name = "System Information"
   

By using a general name such as **System Information**, you make this component more flexible. You can then use it to add any information you want to maintain for this client by adding new groups to the existing NOIDMIF file. 

3. Type the following line to add the Display Name for the new Wide World Asset Numbers class: 

   Start Group
   

Name = "Wide World Asset Numbers"

The **Name** attribute is the string that administrators will see in Resource Explorer to refer to this class. Wide World Asset Numbers is a DMTF group class. When the SMS Provider sees this group, it creates a WMI class called SMS\_g\_wide\_world\_asset\_numbers. 

After you add attributes, even if you add only a single attribute, you need to add a group to contain your new attributes. 

4. Type the following line to give the Wide World Asset Numbers class a group ID number: 

   ID = 1
   

You can use any method to determine the ID number for each group and attribute, so long as the number is unique for groups within this component. 

5. Type the following line to add the wideWorldAssetNumbers class: 

   Class = "wideWorldAssetNumbers"
   

The **Class** information is used for processing and is never seen by administrators. 

6. Type the following line to add the key attribute: 

   Key = 1
   

This entry indicates that the first attribute listed is the key. Key attributes are unique attributes that identify instances of a certain class. Whenever you have more than one instance of a class, you must include at least one key attribute, or the subsequent instances of the class will overwrite the previous instances. If no key attributes are defined for a NOIDMIF file on a 32-bit system, all the attributes will be designated as key by the inventory process. This does not occur for IDMIF files or for 16-bit NOIDMIF files.

7. Type the following lines to add the first attribute: 

   Start Attribute
   

Name = "Wide World Asset Number" ID = 1 Type = String(10) Value = "414207" End Attribute

You must set an ID number for this attribute, name the attribute, and then specify a data type. The ID number you choose must be unique within the group. Only three data types are recognized by the system: integer, string, and specially formatted datetime string. (For more information about data types, see Appendix C, "Hardware Inventory Classes.") You must also specify a valid value for the data type you selected. 

When you use a NOIDMIF file to define a new class, the class is inventoried at the next cycle, because the NOIDMIF file is processed on the client.

When you customize hardware inventory by using NOIDMIF files, you must leave the NOIDMIF in the target directory on the client. The custom MIF file is used at each hardware inventory cycle when the extended classes and attributes are collected. If the NOIDMIF file is not found on the client during hardware inventory, the extended classes and attributes are deleted and you must submit the NOIDMIF file again by replacing it in the Noidmifs directory on the client.

Because the NOIDMIF file creates classes and attributes that are not part of discovery, they cannot be automatically updated by inventory. When you need to update an attribute that was created with a NOIDMIF file, you can do so by updating the existing NOIDMIF file with a different value for the attribute.

After Wide World Importers created their NOIDMIF file to add the asset number to a client, the next step is to extend the procedure to every client within the organization. For more information, see "Customizing More Than One Client" later in this chapter.

Adding a Group to an Existing NOIDMIF File

If you want to collect an attribute that has not been previously collected, you can create a second NOIDMIF file or you can extend the original one.

For example, Wide World Importers' network planners want to keep information about the geographical location of each hardware item in the SMS site database. This information will assist their administrators with troubleshooting, especially when they need to directly access the computer.

They considered adding this information as a second group in the System Information component (which was created in steps 1 and 2 of the procedure in the previous section of this chapter). When they realized that information about the computers located in each office might be useful for asset management and space allocation, they decided to create an IDMIF file instead for each office in their location. (A sample of such an IDMIF file is provided in "Customizing with IDMIF Files" later in this chapter.)

At this point, Wide World Importers' planners still need to link each SMS client with the office in which it is located, so they create a second group in the System Information component. This group is called Office Location. After they create records for all the offices in their organization, the planners can link each computer's record in the SMS site database to the correct Office structure. After they do so, they can determine the physical location of each computer from its SMS site database record whenever they need to directly access the computer, and the office information is also available for other purposes.

The NOIDMIF file that Wide World Importers created is as follows:

Start Component
Name = "System Information"
Start Group
Name = "Wide World Asset Numbers"
ID = 1
Class = "wideWorldAssetNumbers"
Start Attribute
Name = "Computer Asset Number"
ID = 1
Type = String(10)
Value = "414207"
End Attribute
End Group

Start Group
Name = "Office Location
ID = 2
Class = "officeLocation"
Start Attribute
Name = "Current Location"
ID = 1
Type = String(50)
Value = "Bldg 3 Floor 2 Office 2131"
End Attribute
End Group
End Component

Whenever Wide World Importers administrators decide to collect an attribute for the first time and associate it with each client, they can use this method to extend the existing custom MIF file.

To add the Office Location group to the System Information component 

1. Type the following line to add the new Office Location group: 

   Start Group
   

Name = "Office Location"

The **Name** is the display name, which will be seen by administrators within Resource Explorer. As mentioned earlier, when you add attributes, even if you only add a single attribute, add a group to contain your new attributes. 

2. Type the following line to assign the Office Location class a group ID number: 

   ID = 2
   

You can use any method to determine the ID number for each group, so long as the ID number is unique within the component. 

3. Type the following line to add the officeLocation class: 

   Class = "officeLocation"
   

The **Class** information represents processing information, while the **Name** information becomes the display name for the group. 

4. Type the following lines to add the first attribute: 

   Start Attribute
   

Name = "Current Location" ID = 1 Type = String(50) Value = "Bldg 3 Floor 2 Office 2131" End Attribute

Set an ID for this attribute that is unique within this group, name the attribute, and give a data type. Only three data types are recognized by the system: integer, string, and a specially formatted datetime string. (For more information about data types, see Appendix C, "Hardware Inventory Classes.") You must also specify a valid value for the data type you selected. 

5. Replace the file in the following directory: 

   %Windir%\MS\SMS\Noidmifs 

   The file will be processed at the next hardware inventory. 

After Wide World Importers administrators add the office location to the custom NOIDMIF file on a client, they must extend the procedure to every client within the organization. For more information, see "Customizing More than One Client" later in this chapter.

Changing a Value in a NOIDMIF File

Sometimes you need to use a NOIDMIF file to change the value of an attribute you created. To do so, simply change the value in the existing NOIDMIF file and replace the file in the target directory on the client.

For example, when an employee changes offices at Wide World Importers, the computers are usually moved as well, and the Office Location attribute for that employee's computers must be updated. To change this attribute, use the following procedure.

To change the Current Location attribute within the System Information component 

1. Change the value of the attribute within the existing NOIDMIF file by changing the Value field: 

   Start Attribute
   

Name = "Current Location" ID = 1 Type = String(50) Value = "Bldg 3 Floor 1 Office 1511" End Attribute

All the other fields within the NOIDMIF file remain the same. The previous value is maintained by SMS within Resource Explorer in the Hardware History folder. 

2. Replace the file in the following directory on the client: 

   %Windir%\MS\SMS\Noidmifs 

   The file will be included as part of the next hardware inventory. 

Removing a Group from a NOIDMIF File

Sometimes information becomes obsolete or is redundant within the SMS site database. In such cases, you can remove groups from an existing NOIDMIF file.

For example, Wide World Importers purchased an asset inventory program that creates its own custom MIF files that become part of the SMS site database. Because the Asset Number group is now redundant, the company's administrators want to remove this group from all the existing clients. To do so, they edit the NOIDMIF file and remove this group. The resulting NOIDMIF file is as follows:

Start Component
Name = "System Information"
Start Group
Name = "Office Location
ID = 2
Class = "officeLocation"
Start Attribute
Name = "Current Location"
ID = 1
Type = String(50)
Value = "Bldg 3 Floor 1 Office 1511"
End Attribute
End Group
End Component

This NOIDMIF file is replaced within the target directory, and the Asset Number class is no longer collected for this client.

After Wide World Importers removes the group from the NOIDMIF file for a single client, they must extend the procedure to every client within the organization. For more information, see "Customizing More than One Client" later in this chapter.

Customizing with IDMIF Files

You can use IDMIF files to create entire new architectures in the SMS site database, or to update existing architectures. They can also be used to add stand-alone computers to the SMS site database. IDMIF files are also frequently used to inventory non-system items.

For example, Wide World Importers' network planners want to keep information about the geographical location of each computer within the SMS site database, so that administrators can easily find the computer when hands-on maintenance is required. To do so, they add a new architecture called Office to the SMS site database, that includes all the information about the location of the office. They decide to include other information about the office that might be useful when moves are planned or for keeping track of space within the organization.

After they add the Office architecture to the SMS site database, Wide World Importers' administrators create an instance of this architecture for each office within the organization. Then they add a new class to the SMS site database record for each computer and call it Office Location (this class is described in "Adding a Group to an Existing NOIDMIF File" earlier in this chapter.) The Current Location attribute holds the identifier for some instance of the Office architecture. After these structures are created and populated, whenever administrators discover some hardware problem remotely, they can easily retrieve information about where to find the hardware with the problem. An added benefit is that they can use SMS queries and reports to gather information about the organization's space, as well as the hardware and software deployed in each office.

Following is an example of a custom IDMIF file created by Wide World Importers to catalog their office space. This IDMIF file creates an architecture called Office.

/AgentID<Admin John>
//Architecture<Office> 
//UniqueID<Bldg26Floor26Room2626>

Start Component
Name = "Office"
Start Group
Name = "Office"
ID = 1
Class = "Office" 
Key = 1 
Start Attribute
Name = "Office Address"
ID = 1
Type = String(50)
Value = "2626 3rd St., Redmond, WA"
End Attribute
Start Attribute
Name = "Directions"
ID = 2
Type = String(200)
Value = "From Interstate 90, take exit 26, turn right at the light, turn into docking bay 26"
End Attribute
End Group

Start Group 
Name = "Dimensions"
ID = 2
Class = "Dimensions"
Start Attribute
Name = "Length in Feet"
ID = 1
Type = Integer
Value = 300
End Attribute
Start Attribute
Name = "Width in Feet"
ID = 2
Type = Integer
Value = 400
End Attribute
Start Attribute
Name = "Front Window"
ID = 3
Type = String(32)
Value = "No"
End Attribute
Start Attribute
Name = "Number of Computers"
ID = 4
Type = Integer
Value = 26
End Attribute
End Group 

Start Group 
Name = "Computer1"
ID = 3
Class = "Equipment" 
Key = 1
Start Attribute
Name = "GUID"
ID = 1
Type = String(50)
Value = "GUID:JJJ-26-27543-TKPLKD"
End Attribute
Start Attribute
Name = "NETBIOS Name"
ID = 2
Type = String(32)
Value = "PrintServer26"
End Attribute
Start Attribute
Name = "Serial Number"
ID = 3
Type = String(50)
Value = "AAA-885764-DGTFSR"
End Attribute
End Group
Start Group
Name = "Computer2"
ID = 4
Class = "Equipment"
Key = 1
Start Attribute
Name = "Computer2"
ID = 1
Type = String(45)
Value = "GUID:CCC-26-34573-EDSRFD"
End Attribute
Start Attribute
Name = "NETBIOS Name"
ID = 2
Type = String(32)
Value = "FileServer26"
End Attribute
Start Attribute
Name = "Serial Number"
ID = 3
Type = String(50)
Value = "BBB-467588-XYZYTW"
End Attribute
End Group 
End Component

IDMIF files are identical to NOIDMIF files in most ways, with the following exceptions:

• IDMIF files must have an added delta header that provides agent, unique ID, and resynchronization information (NOIDMIF files are given a similar header by the system during processing on the client). 

• IDMIF files must include a top-level group with the same name as the architecture being added or changed, and they must include at least one attribute. 

• IDMIF files can have key attributes that must be unique. Any class that has more than one instance must have at least one key attribute defined, or subsequent instances will overwrite previous instances. 

After you create an IDMIF file, you must place the IDMIF file in the IDMIF target directory on the client:

%Windir%\MS\SMS\Idmifs

On clients, the Hardware Inventory Client Agent copies IDMIF files directly, unchanged, through the CAP to the primary site server on the next scheduled inventory cycle. When you customize hardware inventory by using an IDMIF file, the information is entered into the SMS site database immediately.

You can create, modify, and delete IDMIF files by using the procedures described in "Customizing with NOIDMIF Files" earlier in this chapter. Then, make sure that you have a top-level group and add the required IDMIF file header as described in the following section.

After you create IDMIF files, note that they are processed differently than NOIDMIF files. While NOIDMIF files must be left in the target directory on the client in order to remain in the SMS site database, data from IDMIF files persists after they are created. You can add an IDMIF file instance by creating the MIF file (as described in "Creating an Attribute by Using a NOIDMIF File" earlier in this chapter), adding a delta header, and then placing the file in the following directory on the client:

%Windir%\MS\SMS\Idmifs

Requirements of IDMIF Files

Two delta header comments are required for an IDMIF file; the other comments are optional. The comments you must include are:

• The name of the architecture you want to create or modify: 

  //Architecture<ArchitectureName>
  

• A unique ID for this instance: 

  //UniqueId<UniqueID>
  

The unique ID can be any unique ID, such as a social security number for a person or a vehicle identification number for a vehicle. Each architecture has one or more instances within the SMS site database. The unique ID is the key for this specific instance.

In addition, although it is not required, you should use the agent name, especially with a large or complicated custom MIF file that might be updated by more than one agent, or when you extend the System architecture.

//AgentID<AgentName>

If you do not include this attribute, hardware inventory might overwrite the information your IDMIF file places in the SMS site database.

The agent name enables you to independently create and modify the System architecture. Others who modify the architecture can use a different agent name. They can then remove or modify the parts of the architecture that are associated with that agent, independently of the modifications of other agents.

There is another requirement of any IDMIF file: Whenever you create an IDMIF file, you must include a group within the IDMIF file with the same class name as the architecture you are creating or modifying. This group is known as the top-level group.

Also, if you create any class that has more than one instance, you must include at least one key value within the class, to avoid having each instance overwrite previous instances. For more information, see "Creating an Attribute by Using a NOIDMIF File."

Table 10.1 IDMIF File Header Comments 

IDMIF file headercomment	Required	Function
//AgentID <Agent Name>	No	The name of the agent that produced the custom MIF file. You can use your name or the name of an application that produced the custom MIF file. This field is most useful when more than one agent is expected to change an architecture. You must specify this value for the ResyncAgent header comment, or if the ResyncClass value is set to 1.
//FullResync<0>	No	A value of 1 causes a full resynchronization of this architecture for this instance (this Unique ID). A value of 0 causes a delta resynchronization (changing this architecture for this instance). This field is most useful for completely replacing an instance of an IDMIF file or for erasing any information that remains in the SMS site database after an IDMIF file is no longer being used.
//ResyncAgent<0>	No	A value of 1 causes an agent resynchronization (replacing all of the values added by this agent to this architecture in the SMS site database with the results of this IDMIF file). This field is most useful for large or complicated IDMIF files.
//ResyncClass <ClassName><1>	No	A value of 1 causes an agent resynchronization of the specified attribute class in the SMS site database (completely replacing all elements of this attribute class created by this agent with the contents of this IDMIF file). A value of 0 completely replaces the class with the contents of the MIF file. This field is most useful for 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 <UniqueID>	Yes	The single value that uniquely identifies this instance in the SMS site database. This value can be the globally unique identifier (GUID) or SMSID of a specific client or some other unique number, such as a social security number for a person or a vehicle identification number for a vehicle.

Note The inventory process adds a header to NOIDMIF files during processing that is very similar to the delta header you add to IDMIF files.

To create custom IDMIF files 

1. Prepare the IDMIF file by following the procedures in "Creating an Attribute by Using a NOIDMIF File" earlier in this chapter.

2. Add the architecture name by adding the following statement to the beginning of the IDMIF file: 

   //Architecture<ArchitectureName>
   

3. Add a unique ID in the following format: 

   //UniqueId<UniqueID>
   

4. Add an agent ID if this is required or desirable for your IDMIF file. Use your name or another identifier for the agent ID. 

   //AgentID<AgentName>
   

You should always consider using agent IDs when you create an IDMIF file. When you extend the **System** architecture, agent IDs are required so that hardware inventory resynchronizations do not overwrite the data. As mentioned earlier, they are most useful for large or complicated IDMIF files, especially when parts of the file might be changed by different agents. 

5. Copy the IDMIF file to the client's target directory. For example:

   Copy test.mif %Windir%\MS\SMS\Idmifs
   

The IDMIF file will be processed by Inventory Data Loader and included in the SMS site database. You can update the values by using additional IDMIF files. 

After you submit an IDMIF file, you do not need to resubmit it or maintain it within the SMS site hierarchy unless you want to change it.

Changing IDMIF Files with Resynchronizations and Pragma Statements

You can add, change, or delete any part of an IDMIF file in any of the following ways:

• Replace the entire MIF file with a new one by using the full resync parameter: 

  //FullResync<1>
  

• Use an agent resynchronization to replace all MIF file parts that were created by a certain agent.

  //ResyncAgent<1>
  

• Replace the given class within the MIF (if a value of 0 is specified). Or, if the value is 1, replace the values that were created by the agent within the given class. 

  //ResyncClass<ClassName><1>
  

• When you use no history IDMIF files (*.nhm), you can also add, delete, and change groups within the IDMIF file by using pragma statements. 

Pragma statements are messages to Inventory Data Loader that can be inserted into SMS IDMIF files. You can use pragma statements to direct Inventory Data Loader to add new groups, change groups, or delete groups within IDMIF files.

Pragma statements are used only with no history MIF files (*.nhm), not with MIF files (*.mif).

You might find the following three pragma statements especially useful when you use no history MIF files within SMS:

• Add pragma 

  This statement adds a group to an existing instance of an architecture within the SMS site database. Other instances of the architecture are not affected unless an IDMIF file is submitted for them. 

  Pragma = "sms:add"
  

• Update pragma 

  This statement replaces the information currently stored about a group in a certain instance of an architecture with the information in the current IDMIF file. This pragma statement appears as follows: 

  Pragma = "sms:update"
  

**Note** If you use the Update pragma statement, the group must exist within the instance of the architecture you specify with the SMS site database. Otherwise, the entire architecture is resynchronized. 

• Delete pragma 

  This statement deletes the group from this instance of the architecture. Deleting the top-level group causes the entire architecture to be deleted. This pragma statement appears as follows: 

  Pragma = "sms:delete"
  

**Note** No spaces should be placed between the elements of the pragma statements or the delta header statements. 

The following pragma statement is sometimes found in SMS 2.0 MIFs, but it is not necessary with the SMS site database and is not typically used in SMS:

Pragma = "sms:lookup"

Pragma statements can apply to any group within the MIF file. You insert them in the following location within any group:

Start Group 
Name = "Equipment"
ID = 1
Class = "Equipment"
Key = 3,5
<pragma statement inserted here>
Start Attribute

The following table provides strategies for the three most common tasks you will perform when working with custom MIF files.

Table 10.2 Strategies for Common IDMIF File Tasks 

IDMIF file type	Adding a new group	Updating a group	Deleting a group	Agent ID
NHM file for custom architecture or stand-alone computer	Add the new group and include the "sms:add" pragma statement.	Make updates and change the pragma statement to "sms:update".	Change the pragma statement to "sms:delete".	Agent optional
MIF file for custom architecture or stand-alone computer	Add the new group to the MIF file.	Make updates to the MIF file to reflect the changes.	Delete the group from the MIF file.	Agent optional

You can change or delete groups within an IDMIF file instance by modifying the MIF file as described in the following procedure. After you modify the MIF file, place it in the target directory on the client:

%Windir%\MS\SMS\Idmifs

To replace a value in an IDMIF file 

1. Prepare an IDMIF file that includes the change you want. Use your name or another identifier as the agent ID. You can modify the IDMIF file that originally created the value, or you can create a new IDMIF file that changes whatever values you want modified. 

2. In the IDMIF file, add a Resync or a pragma statement. If you want to replace the entire architecture, use the following comment: 

   //FullResync<1>
   

To replace an attribute class, use the following comment: 

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">//ResyncClass&lt;ClassName&gt;&lt;1&gt;

To replace everything in the architecture for the unique ID that was added by this agent, use the following comment: 

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">//ResyncAgent&lt;1&gt;

Or, you can use a pragma statement for no history MIF files, as described earlier. 

3. Place the IDMIF file in the target directory on the client: 

   %Windir%\MS\SMS\Idmifs 

   For example: 

   copy test.mif c:\%Windir%\MS\SMS\Idmifs 

Creating an IDMIF File for a Stand-alone Computer

As a rule, instances of the System architecture represent networked computers. However, in some cases, you might want to track computers that are not networked. To track stand-alone computers, make them instances of a custom architecture. Note that you must use a custom architecture to describe stand-alone computers, because the hardware inventory process disallows any IDMIF file that changes the System architecture.

For example, you might want to maintain records in the SMS site database for a stand-alone computer so that it can be included when you use the SMS site database to create queries or manage assets. To do so, create an IDMIF file for the computer and place that file in the Idmifs directory on any client:

%Windir%\MS\SMS\Idmifs

The IDMIF file need not collect all of the attributes you are collecting with hardware inventory — it can consist of any set of attributes you want.

Following is a sample custom MIF file that you can use to add a stand-alone computer as a custom architecture to the SMS site database. After you create a custom MIF file, you can create queries for and collections of your stand-alone systems.

//AgentID<Admin John>
//Architecture<Standalone System>
//UniqueID<GUID:BBB85C40-F65A-11D1-8FAC-00AA0038c067> 

Start Component
Name = "System Test RAID Machine"

Start Group
Name = "Standalone System"
ID = 1
Class = "Standalone System"
Key = 1 
Pragma = "SMS:Add"

Start Attribute
Name = "System Name"
ID = 1
Type = String(30)
Value = "STANDALONE 1"
End Attribute
End Group

Start Group
Name = "Screen Saver"
ID = 2
Class = "Screen Saver"

Start Attribute
Name = "Size"
ID = 1
Type = Integer
Value = 17
End Attribute

Start Attribute
Name = "Make"
ID = 2
Type = String(20)
Value = "Fellowers"
End Attribute
End Group

Start Group
Name = "Computer Box"
ID = 3
Class = "Computer Box"

Start Attribute
Name = "Type"
ID = 2
Type = String(15)
Value = "Mini Tower"
End Attribute

Start Attribute
Name = "Color"
ID = 4
Type = String(15)
Value = "Gray"
End Attribute
End Group

End Component

Associating Users with Their Computers

In the NOIDMIF file examples in this chapter, Wide World Importers used a NOIDMIF file to associate each computer in the organization with its geographical location. Another reason for customizing NOIDMIF files is to associate users and members of user groups with their computers.

In SMS 2.0, collections can be composed of groups of similar computers or groups of users. Typically user groups represent a logical grouping that correspond to the way your company is organized.

For example, Wide World Importers created user groups that correspond to the divisions of the company, including a Finance group, a Personnel group, and an IS group. The company's system administrators want to distribute software to these groups, but they want to do so when the users are not logged on to their computers.

To accomplish this task, the administrators considered using a NOIDMIF file to record the principal user of each computer and all the user groups that user belongs to. After doing this, they could create a collection of all the computers for members of the Personnel user group.

Instead, for greater security, they decided to create an IDMIF file for each user group within the organization. They used NOIDMIF files to record only the principal user of each computer. By using the IDMIF file that is controlled by the administrator, they eliminated the possibility that unauthorized users might create a NOIDMIF file, thereby adding themselves to user groups where they do not belong.

Note When you use an IDMIF file to create a record of user groups within your organization, you must update the IDMIF file whenever users are added or removed from these groups.

Wide World Importers' administrators added a NOIDMIF file to each computer on the network that serves as the principal computer for a member of a user group. The format for this file is similar to the following:

Start Component
Name = "User Information"
Start Group
Name = "Primary User"
ID = 1
Key = 1
Class = "Users"
Start Attribute
ID = 1
Name = "Primary User Name"
Type = String(80)
Value = "Linda Mitchell"
End Attribute
End Group
End Component

Then, for each user group, the administrators added an IDMIF file similar to the following:

//AgentID<Admin John>
//Architecture<Personnel User Group>
//UniqueID<Personnel Division>

Start Component
Name = "Personnel User Group"
Start Group
Name = "Personnel"
ID = 1
Class = "Personnel User Group" 
Key = 1 
Start Attribute
Name = "Name"
ID = 1
Type = String(50)
Value = "Personnel"
End Attribute
End Group
Start Group
Name = "Members"
ID = 1
Class = "personnelMember" 
Start Attribute
Name = "Member1"
ID = 1
Type = String(50)
Value = "Linda Mitchell"
End Attribute
Start Attribute
Name = "Member2"
ID = 1
Type = String(50)
Value = "Julia Moseley"
End Attribute
End Group
End Component

Customizing More Than One Client

IDMIF files and NOIDMIF files are specific to a single client. To customize hardware inventory for more than one client, you must create a MIF file for each client. To do so, place an IDMIF file with a delta header that includes the architecture, unique ID, and agent ID in the following directory of any client:

%Windir%\MS\SMS\Idmifs

You must submit an IDMIF file for each instance of any architecture you want to customize.

When you use NOIDMIF files, you can establish the same new classes and attributes on each client by placing identical MIF files in the NOIDMIF directory on each client. You can use the software distribution feature to accomplish this task.

When you use IDMIF files, you must create an IDMIF file for each instance identified by a unique ID for that instance. There are several ways to create such a set of MIF files.

• Use a tool to create a MIF file, and then place it in the target directory of a client. 

• Create a simple program to create a MIF file and to extend a single MIF file to multiple instances.

• Use any text editor to create the first MIF file, and then change instance information to create additional MIF files. 

• Create a form that can be completed for each instance, and then attach it to a program that automatically creates a MIF file and places it in the target directory of a client. 

The MIFgen tool that was first released with SMS 1.2 is updated and available for SMS 2.0. As mentioned earlier, this tool is provided on the Microsoft BackOffice 4.5 Resource Kit CD-ROM. MIFgen produces a form that is completed by the user at each client computer. After the user completes the form, the tool creates a NOIDMIF file in the Noidmifs directory on that client. This tool is useful if you can gather information from the user at each client, and if the form addresses the information you want to collect.

If the MIFgen tool does not meet your needs, you can create and use a similar tool that creates a NOIDMIF file in the Idmifs directory of each client computer, or a tool that creates an IDMIF file for each instance of a custom architecture and then places it in the target directory on an SMS client. For more information about creating such applications, see the SMS 2.0 Toolkit.

Using Information from IDMIF Files and NOIDMIF Files

You can query new architectures that are created with IDMIF files and new classes and attributes created with IDMIF files and NOIDMIF files in the same way as any other architecture. Classes that extend the System architecture (which you created by using NOIDMIF files) appear in Resource Explorer, just as any other class or attribute.

You cannot use information about the new classes and attributes in IDMIF files to create packages, but you can use this information from NOIDMIF files.

Information that you add by using NOIDMIF files is not part of discovery, so hardware inventory cannot automatically record changes in such information. Instead, you must add any changes you want to make to the SMS site database. To do so, change the current NOIDMIF file on each client.

Custom architectures that you create by using NOIDMIF files cannot be displayed in Resource Explorer. To access these classes and attributes, you must instead create a query by using the Query Builder. After you create the query, you can use it to examine the data that is included with the new architecture. For more information, see Chapter 13, "Managing Collections and Queries" in the SMS 2.0 Administrator's Guide.