Scan problems

Software Scan Health widget

The Software Scan Health widget shows the health of scans that are running in your infrastructure. You can drill down to reports for specific computers with scan problems. For more details, check Software Scan Status.

Other scan problems

Long running scans caused by signatures using config.xml file to discover the IBM Clarity Data Collection

The signatures which were using config.xml to discover the IBM Clarity Data Collection 6.6 and 7.2, caused the scans to run longer. In BigFix Inventory version 10.0.5, the signatures have been removed from the LMT catalog.

The software scans cannot be initiated because the Initiate Software Scans task is not applicable

The software scans depend on the scanner catalogs that are used by the scanner to discover software. The scanner catalogs are created when you upload the software catalog to BigFix Inventory. If you cannot run the software scans, it might mean that the catalogs were not created. Before you update the scanner catalogs manually, complete the following steps to check the cause of this problem:

1. On the computer on which the task is not applicable, go to the <BES_Client>\LMT\CIT directory.
2. Check if the catalog.bz2 file exists. The file contains the scanner catalogs.
3. Log in to the BigFix console.
4. In the navigation bar, click Actions.
5. In the upper-right pane, locate the Catalog Download (Version version) action and select it.
6. Check the details of the action. You can check on which computer the action failed and investigate the failed steps. Try to determine the cause of the problem and fix it.

If you cannot determine the cause, update the catalogs manually. For more information, see: Troubleshooting scanner catalogs update.

In the Software Scan Status analysis, the status of a software scan is Failed and the value in the Is archive file size exceeded column is True

The problem occurs when the scan file is larger than the maximum archive file size that can be sent by the BigFix client. To solve the problem, perform the following steps:

1. Check the BigFix client log for information about the size of the file that exceeded the limit. By default, the log is in the following location.
   • /var/opt/BESClient/__BESData/__Global/Logs
   • C:\Program Files (x86)\BigFix Enterprise\BESClient\__BESData\__Global \Logs
2. Log in to the BigFix console.
3. In the left navigation, click Computers, right-click the computer on which the scan failed, and then click Edit Computer Settings.
4. Increase the value of the _BESClient_ArchiveManager_MaxArchiveSize parameter.

The software scan cannot be run on an LPAR because the Initiate Software Scan is not relevant on that computer

When a WPAR exists on an LPAR, all WPAR processes are visible on the level of the LPAR. When the software scan is running on the WPAR, the process is visible on the level of the LPAR and thus the Initiate Software Scan fixlet is not relevant on the LPAR. To run the software scan on the LPAR, wait for the scan to finish on the WPAR. Alternatively, perform the following steps:

1. Log in to the BigFix console.
2. Select the Initiate Software Scan fixlet and click Take Action.
3. On the Target tab, select Dynamically target by property.
4. Expand By Retrieved Properties and then expand By Computer Name.
5. Select the LPAR computer on which you want to run the software scan and click OK.

Upgrade of the scanner fails on a WPAR

When a WPAR exists on an LPAR, you must first upgrade the scanner on the LPAR, and then on the WPAR.

Software scans are failing. Computers where the scans are failing have the Low Disk Space status on the Deployment Health widget.

The problem might be caused by insufficient disk space for the scanner cache. To solve the problem, move the scanner cache folder to a different location or optimize the cache. For more information, see: Optimizing scanner cache configuration.

Software components that are installed in the /usr/lpp directory on AIX are not discovered

The problem occurs because the /usr/lpp directory is by default excluded from software scans. Starting from scanner version 2.8.0.5000, the directory is included in software scans, and components installed in this directory are discovered. Thus, to solve the problem, update the scanner to version 2.8.0.5000 or later, and wait for the next scheduled software scan. Alternatively, you can manually include the /usr/lpp directory in software scans.

After the update of the scanner, the number of software components discovered on AIX increased and some duplicates appeared

Previously, the /usr/lpp directory was excluded from software scans. However, components whose signatures existed only in this directory were not discovered. Thus, starting from scanner version 2.8.0.5000, the /usr/lpp directory was included in software scans. It caused that more components are discovered and displayed on the reports. However, components installed in the /usr/lpp might also be discovered in other directories. In such case, duplicate components appear on the reports. To solve the problem, suppress the duplicates. For more information, see: Excluding and suppressing software instances. You can also create a custom rule that suppresses components that are discovered in /usr/lpp and other directories. For more information, see: Creating and managing custom rules.

How to check the results of the Software Scan Status analysis

To check the status of the software scan, view the results of the Software Scan Status analysis.

1. Log in to the BigFix console.
2. In the navigation tree, go to Sites > External Sites > BigFix Scanner > Analyses.
3. Select the Software Scan Status analysis.
4. In the lower pane, open the Results tab.

New software titles were added to the catalog, a data import was run but the software is not visible in the BigFix Inventory web user interface

One of the reasons for the missing software titles in the BigFix Inventory UI is that non-standard file types were used as software signatures. If you added a rule with non-standard file extensions, you must either wait until all the steps in the catalog data flow complete or perform those steps yourself. To have accurate inventory data:

1. Run a data import to propagate the catalog to the endpoints.
2. Verify that the catalog was propagated successfully.
3. Upload the scan data to the BigFix Inventory server.
4. Run another data import.

The scanner cannot be updated on 32-bit Linux x86

The problem occurs on the 32-bit Linux x86 with the libstdc++.so.5 library for which the last available version of the scanner is 2.8.0.3000. To solve the problem, update the library to libstdc++.so.6 if available. Otherwise, the scanner cannot be updated.

Software Scan Health limitations on IBM i

The result of the file system scan is positive by default in the IBM i environment. The File System Scan Successful column is always set to yes.

After running a scan on a large system with high number of mount points or share drives, the log file contains multiple return codes related to insufficient memory

During file scan or software scan that is performed on large servers with high number of mount points or share drives, memory requirements for the scanner increase. If there is not enough memory available for the scanner to work, the log file might contain the following return codes:

• 125 which indicates memory allocation failure.
• 134 which translates into the operating system signal 6 - SIGABRT.
• 139 which translates into the operating system signal 11 - SIGSEGV.

For more information, see: Software scan return codes.

To check whether the issue is related to problems with memory, monitor the memory usage of the scanner and determine if it reaches the limits set on the system. Ensure that your limit allows scanner to work properly. For example, for the scanner on a sever with 20 000 mount points or share drive the required memory is about 500 MB of RAM. Thus, the ulimit for data seg size, or ulimit -d must be set to at least 500000. For more information, see: Ulimit command (on AIX).

When you scan large systems with high number of mount points or share drives, consider the following aspects:

• The scan can be slow.
• The scanner logging must be set to minimum, as it has significant impact on performance in such environments.
• Do not set a CPU threshold, or if required, ensure that the limit is not too low.

Optimized scan of shared disks does not complete on Windows

When you enable optimized scan of shared disk, the scan does not complete. In the BigFix console, when you go to Actions, the status of the Optimized Shared Disks Scan Update Resources List action is Pending Downloads and the following error is displayed in the Summary section.

HTTP Error 28: Timeout was reached: Connection timed out after 10000 milliseconds" 

The problem occurs on Windows systems with multiple interfaces. To solve the problem, see: Configuring servers in separate networks.