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. By sorting the columns of a report, you can quickly understand which computers are failing which specific software scan types.

Packages with long attribute names are not collected in the package scan

If the name or the path of an attribute is too long, causing the whole package scan line to exceed 1000 characters, the path attribute is removed and the description column shows "BFI_Truncated". If the package scan result line is still too long, the entire line is removed.

You can check the missing lines in the package scan log:

(entry per OS/source)

• C:\Program Files (x86)\BigFix Enterprise\BES Client\LMT\CIT\packageData.log
• /var/opt/BESClient/LMT/CIT/RPM/*_packages.log
• Disconnected Scanner Directory/work/*_packages.log

Failed Scan: The catalog-based scan did not complete successfully.

This problem might occur because the computer is out of space, is misconfigured, or the scan was stopped.

Failed Scan: At least one type of software scan (catalog-based, file system, package data, or software tags) did not complete successfully.

This problem might occur because the computer is out of space, is misconfigured, or the scan was stopped.

Missing Scan: The last attempt to initiate the catalog-based scan was more than 30 days ago.

This problem might occur because the computer is out of space, is misconfigured, or the scan was stopped.

Missing Scan: The last attempt to initiate at least one type of software scan (catalog-based, file system, package data, or software tags) was more than 30 days ago.

This problem might occur because the computer is out of space, is misconfigured, or the scan was stopped.

Outdated Catalog: The version of the catalog on the agent is older than the version that is available on the server.

When you upload a software catalog to BigFix InventoryLicense Metric Tool or edit your custom catalog, the status of the catalog is pending until you run an import. During the import, endpoint catalogs are created and the version of the catalog that is displayed on the Software Catalog widget is updated. Endpoint catalogs are then distributed to the computers in your infrastructure.

The time when the endpoint catalog reaches the computers depends, for example, on the computer connection status. When the endpoint catalog is updated on the computer, information about the new version of the catalog is gathered by the Software Scan Status analysis. After the next import, information about the version of the catalog that is available on the computer is updated in BigFix InventoryLicense Metric Tool.

Because this entire flow might take some time, it can happen that a computer has the Outdated Catalog status even thought there are no problems. To verify whether any action is needed, perform the following steps:

1. On the Software Catalog widget, check the date when the catalog was last edited.
2. On the Software Scan Health widget, click Outdated Catalog to view the list of affected computers and check the date in the Last Software Change column.
   • If the last scan import was before the date when the catalog was last edited, wait for the next scan and the subsequent import. As described above, distribution of the endpoint catalog to the computers and reporting its version from the computers to BigFix InventoryLicense Metric Tool might take some time.
   • If the last scan import was after the date when the catalog was last edited, force the distribution of the software catalog to the computers. For more information, see: Updating scanner catalogs.

Scan Not Uploaded: Results of the catalog-based scan or file system scan were not uploaded to the BigFix server.

This problem might occur because the computer or a relay is offline, there is a network outage, or the last scan attempt was more than 30 days ago. Check whether each computer listed in the report is running and that the scan results are uploaded to the server on a regular basis. You can check the time of last scan attempt for all types of the software scan in the Software Scan Status analysis.

If the problem persists, it might indicate that the initial download of the catalog to the endpoints failed. To solve the problem, upload the latest catalog to the agent. For more information, see: Updating scanner catalogs.

IBM i computer scans are excluded from the Scan Not Uploaded check.

Unscanned Shared Disks: A remote shared disk is not scanned by the agent.

License usage for IBM software that is installed on an unscanned shared disk might be under-reported. To solve the problem, enable scans of remote shared disks.

The status is based on scanning shared disks by using the basic mode. Starting from application update 9.2.12, you can discover software that is installed on shared disks by using the optimized mode. This mode allows for reducing the load that scans produce on shared disks. For more information, see: Discovering software on shared disks.

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 InventoryLicense Metric Tool. 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: Updating scanner catalogs.

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. For more information, see: Including the excluded directories back in 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 Inventory v10 > 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.