Chapter 20 - Hardware and Software Inventory Flowcharts

This chapter documents the process flows for the Systems Management Server (SMS) inventory operations performed on the site server. Inventory Data Loader processes hardware inventory information as it arrives at the site server from the clients. When a child site is first attached to its parent site, Inventory Data Loader extracts all client hardware inventory information from the SMS site database, generates MIF files, and passes those MIF files to the parent site server.

Hardware and software inventory resynchronization takes place when bad hardware or software inventory data is received from a client or a child site. This chapter documents the following inventory flowcharts:

• Inventory Data Loader: Normal MIF Processing 

• Software Inventory Resync 

• Hardware Inventory Resync 

• Inventory Data Loader: Attach Site to Parent Site 

Before you use the tips and flowcharts in this chapter, you should be familiar with the information presented in these chapters of the SMS 2.0 Administrator's Guide:

• Chapter 1, "Introducing Systems Management Server 2.0" 

• Chapter 10, "Collecting Hardware and Software Inventory" 

Before you use the tips and flowcharts in this chapter, you should read the flowchart introductory material in Chapter 16, "Introducing the SMS 2.0 Flowcharts."

Inventory Data Loader: Normal MIF Processing

When hardware or software inventory is enabled on a site server, inventory is periodically collected at the client. Client agents prepare no-history MIF files (*.nhm) and MIF files (*.mif) that contain the most recent changes to inventory, and they write these files to the client access point (CAP). From the CAP, they are sent to the site server. This flowchart documents the actions on the site server after the files arrive.

Tracing Information

You can trace the activity described in this flowchart by studying the status messages and optional log files for the server components listed in the following table.

For server components, you can view status messages, or you can enable the log files. You can then study the log files and status messages associated with these components to trace the activity that is actually occurring on your SMS system and compare it to the activity described in the flowchart. For more information about how to access status messages for a specific component and how to enable logging, see "Status Messages Versus Logging" in Chapter 16, "Introducing the SMS 2.0 Flowcharts."

Table 20.1 Status Message Components and Log Files for Inventory Data Loader: Normal MIF Processing 

Troubleshooting Tips

If a backlog of MIF files accumulates at the site server (that is, if MIF files are not being processed): 

• Inventory Data Loader might be busy sending inventory to the parent site or trying to parse bad MIF files. To read about the flow of inventory to a parent site, see "Inventory Data Loader: Site Attached to Parent Site" later in this chapter. 

  To determine whether Inventory Data Loader successfully parsed the MIF files that were placed in the SMS\Inboxes\Dataldr.box\Process directory, examine the \Badmifs directory. If there are a large number of recent files in \Badmifs, then the clients are generating bad MIF files, and Inventory Data Loader is busy trying to parse them. 

• Inventory Data Loader might be receiving MIF files from clients whose discovery data records (DDRs) are not yet in the SMS site database.

  To determine whether the clients that are sending the MIF files have been discovered by this site server and have been reported to the SMS site database, examine the \Orphans directory. Inventory Data Loader moves a MIF file to \Orphans if the client that sent the file is not yet in the SMS site database. Inventory Data Loader creates a DDR for Discovery Data Manager to process, so that the discovery data can be added to the SMS site database. If there are many files in \Orphans, Inventory Data Loader might be busy creating DDRs. Inventory Data Loader attempts to process MIF files in the \Orphans directory every 10 minutes. 

• Examine the Inventory Data Loader status messages or the Dataldr.log file to determine whether the Inventory Data Loader has been able to connect to the SMS site database server. Inventory Data Loader might be unable to write a discovered client's MIF to the database. 

  If the Inventory Data Loader is unable to connect to the SMS site database server, it holds the MIF file in a queue and tries again after ten minutes. If there are many MIF files waiting to be processed, this queue can grow quickly. 

If the MIF files are not being processed on the site server: 

• Verify that Inventory Data Loader successfully parsed the MIF file by checking Inventory Data Loader status messages or the Dataldr.log file. If the MIF file cannot be processed, it will be transferred to the \Badmifs directory. 

• Verify that the MIF file is not larger than the "Maximum MIF Size" which defaults to 5,000,000 bytes (about 4.7MB). If the MIF file is larger than the size indicated in the site server's registry key, it will be rejected and placed in the \Badmifs directory. 

  The "Maximum MIF Size" can be increased by editing the registry on the site server. The registry key is \HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \SMS \Components \SMS_Inventory_Dataloader \Max MIF Size. 

Verify that the problems are not being caused by SQL connectivity errors: 

• Check the immediately preceding status messages from this component about SQL Server errors. 

• Verify that this computer can reach the SMS site database server (SQL Server computer). 

• Verify that SQL Server services are running. 

• Verify that SMS can access the SMS site database. 

• Verify that the SMS site database, transaction log, and tempdb are not full. 

• Verify that there are at least 50 SQL Server user connections, plus 5 for each SMS Administrator console. 

• If the problem persists, check the SQL Server error logs. 

Software Inventory Resync

Software Inventory Resync is initiated by the Software Inventory Processor on the site server when a bad *.sic file is discovered during the software inventory process. Software Inventory Processor adds a resync request to the client computer's *.cfg file and writes it to the CAP. On the client computer, Client Component Installation Manager (CCIM) periodically checks the CAP for configuration changes and picks up the new *.cfg file. This flowchart documents the actions on the site server, the CAP, and the client computer when a bad *.sic or *.sid file is discovered.

Tracing Information

You can trace the activity described in this flowchart by studying the status messages and optional log files for the server components listed in the following table.

For server components, you can view status messages, or you can enable the log files. You can then study the log files and status messages associated with these components to trace the activity that is actually occurring on your SMS system and compare it to the activity described in the flowchart. For more information about how to access status messages for a specific component and how to enable logging, see "Status Messages Versus Logging" in Chapter 16, "Introducing the SMS 2.0 Flowcharts."

Table 20.2 Status Message Components and Log Files for Software Inventory Resync 

Troubleshooting Tips

If the Software Inventory Resync is not being requested when necessary: 

• Verify that Software Inventory Processor is creating or updating the *.cfg or *.lkp files. 

• Verify that all *.cfg and *.lkp files were properly replicated to all CAPs. Make sure that the contents match by viewing the client.lkp for the client in question and finding the associated *.cfg file. 

• Verify that CCIM is making the local registry change on the client. 

• Force CCIM to update client configuration by double-clicking the Systems Management icon in Control Panel. Click the Sites tab, then click Update Configuration. 

• Repair the Software Inventory Agent installation by double-clicking the Systems Management icon in Control Panel. Click the Components tab, click Software Inventory Agent, and then click Repair Installation. Verify that the Software Inventory Agent is running on the client. 

• Verify that the client service has appropriate permissions to the CAP. 

Hardware Inventory Resync

Hardware Inventory Resync is initiated by Inventory Data Loader on the site server when a bad *.mif file is discovered or when Inventory Processor discovers that it is trying to process a *.mif file that will update a nonexistent row in the SMS site database. Inventory Data Loader adds a resync request to the client computer's *.cfg file and writes it to the CAP. On the client computer, Client Configuration Installation Manager (CCIM) periodically checks the CAP for configuration changes and picks up the new *.cfg file. The Hardware Inventory Agent then begins a hardware inventory cycle. This flowchart documents the actions on the site server, the CAP, and the client computer when a bad *.mif file is discovered.

Tracing Information

You can trace the activity described in this flowchart by studying the status messages and optional log files for the server components listed in the following table.

For server components, you can view status messages, or you can enable the log files. You can then study the log files and status messages associated with these components to trace the activity that is actually occurring on your SMS system and compare it to the activity described in the flowchart. For more information about how to access status messages for a specific component and how to enable logging, see "Status Messages Versus Logging" in Chapter 16, "Introducing the SMS 2.0 Flowcharts."

Table 20.3 Status Message Components and Log Files for Hardware Inventory Resync 

Troubleshooting Tips

If the Hardware Inventory Resync is not being requested when necessary: 

• Verify that Hardware Inventory Processor is creating or updating the *.cfg or *.lkp files. 

• Verify that all *.cfg and *.lkp files were properly replicated to all CAPs. Make sure that the contents match by viewing the client.lkp file for the client in question and finding the associated *.cfg file. 

• Verify that CCIM is making the local registry change on the client. 

• Force CCIM to update client configuration by double-clicking the Systems Management icon in Control Panel. Select the Sites tab and then click Update Configuration. 

• Repair the Hardware Inventory Agent installation by double-clicking the Systems Management icon in Control Panel. Select the Components tab, click Hardware Inventory Agent, and then click Repair Installation. Verify that the Hardware Inventory Agent is running on the client. 

• Verify that the client service has appropriate permissions to the CAP. 

Inventory Data Loader: Attach Site to Parent Site

The effect of the actions in this flowchart is to report all inventory data in a primary site's database to the new parent site. All of the activity in this flowchart takes place on the child site's site server.

Tracing Information

You can trace the activity described in this flowchart by studying the status messages and optional log files for the server components listed in the following table.

For server components, you can view status messages, or you can enable the log files. You can then study the log files and status messages associated with these components to trace the activity that is actually occurring on your SMS system and compare it to the activity described in the flowchart. For more information about how to access status messages for a specific component and how to enable logging, see "Status Messages Versus Logging" in Chapter 16, "Introducing the SMS 2.0 Flowcharts."

Table 20.4 Status Message Components and Log Files for Inventory Data Loader: Attach Site to Parent Site 

Troubleshooting Tips

If inventory from clients is not being reported to a new parent site: 

• Examine the Ddm.log file to verify that Inventory Data Loader at the child site is aware that there is a new parent site. There should be an entry in the Ddm.log file stating that Discovery Data Manager created a <SiteCode>.sha file in the SMS\Inboxes\Dataldr.box directory. 

• Examine the Dataldr.log file to verify that Inventory Data Loader has read the *.sha file, stopped all new MIF file processing, and is creating MIF files for each client's data in the site database to forward to the parent site. 

• Examine the Replmgr.log file at the child site to verify that Replication Manager has forwarded the MIF files to the new parent site. Then, examine the Despool.log file at the parent to verify that the MIF files have been received at the parent site, forwarded to Data Loader for processing, and then added to the site database. (The processing from this point on is the same as the processing that occurs when a MIF file received from a client.)

• Verify connectivity from the child site to the parent site, using the SMSservice account.

• Verify that sufficient space is available on the parent site server's SMS drive so that Replication Manager can send the MIF files to the parent site. 

Verify that the problems are not being caused by SQL connectivity errors: 

• Check the immediately preceding status messages from this component about SQL Server errors. 

• Verify that this computer can reach the SMS site database server. 

• Verify that SQL Server services are running. 

• Verify that SMS can access the SMS site database. 

• Verify that the SMS site database, transaction log, and tempdb are not full. 

• Verify that there are at least 50 SQL Server user connections, plus 5 for each SMS Administrator console. 

• If the problem persists, check the SQL Server error logs. 

If the problem does not appear to be in this flowchart, use the Hardware Inventory flowchart to troubleshoot MIF file processing at the new parent site.