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.

Three stages of 32-bit hardware inventory processing: Processing on client, CAP, then site server. File is then stored in 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 Size


The 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.