Home
Troubleshooting and support
Learn about solutions to common problems that might arise when you use BigFix Inventory BigFix Inventory and how to find logs and trace files that help you troubleshoot those problems.
Troubleshooting software discovery
Problems with software discovery usually fall into one of three categories. The most common category is when the software is discovered but the components are assigned to an incorrect product. In this case, it is enough to reassign the component. The remaining categories include false-positive discovery, or no discovery due to the lack of the signature on the computer.
Logs and return codes
Find logs and interpret return codes to troubleshoot issues.
Return codes of capacity scans on virtualization hosts
If the capacity scan that is run by using the Run Capacity Scan on Virtualization Hosts task fails, an error code that indicates why the scan failed is returned. The code is presented in the results of the Status of Capacity Scan on Virtualization Hosts analysis. Check what is the possible cause of scan failure that is indicated by each code and how to solve the problem.

Troubleshooting and support
Learn about solutions to common problems that might arise when you use BigFix Inventory BigFix Inventory and how to find logs and trace files that help you troubleshoot those problems.
- Troubleshooting a problem
  Troubleshooting is a systematic approach to solving a problem. The goal of troubleshooting is to determine why something does not work as expected and explain how to resolve the problem.
- Duplicate UUIDs problem
  BigFix Inventory requires unique virtual machine UUID (Universally Unique Identifier) numbers to calculate the capacity for all virtual machines and to detect virtualization hierarchy. If there are computers with duplicated UUIDs, a message is displayed in the To Do list. The import log also shows a warning about duplicate UUIDs.
- Interrupting software scan
  BigFix Inventory scans run in the background. Fixlets, such as Initiate Software Scan and Initiate Software Scan on Shared Disks trigger the scan to run in the background.
- Troubleshooting software discovery
  Problems with software discovery usually fall into one of three categories. The most common category is when the software is discovered but the components are assigned to an incorrect product. In this case, it is enough to reassign the component. The remaining categories include false-positive discovery, or no discovery due to the lack of the signature on the computer.
  - Troubleshooting Oracle data issues
    This section provides information troubleshooting different issues faced during collecting Oracle data.
  - Incorrect software is displayed on reports due to incorrect bundling
    Bundling assistant assigns discovered software components to products based on bundling rules. The rules assess the probability with which a component is part of a particular product. Because bundling assistance takes into account all products that are available in the software catalog, not only products that you purchased, it might happen that the component is assigned to a product that you do not have. As a result, the product that you have is not displayed on the reports, and some other product is displayed instead. To solve the problem, reassign the discovered component to the correct product.
  - Software that you do not have is discovered due to false-positive discovery
    It might happen that an older version of the software is discovered after the upgrade or the software signature is not removed from the computer during the uninstallation. False-positive discovery can also be caused by backups of software directories or installation media that are stored on the endpoints and are reported as separate software instances.
  - Software that you have is not discovered
    It might happen that software that is installed is not discovered because the signature or the software ID tag does not exist on the computer where the software is installed.
  - Troubleshooting problems with computers
    When you encounter problems with scan results not being uploaded from a particular computer or you need to collect all logs from that computer, use the Computer Support Data panel. The panel is available in BigFix Inventory and is used to perform some troubleshooting actions without the need of using the BigFix console.
  - Disaster recovery
    To perform disaster recovery for your BigFix environment, you need to regularly back up the BigFix Inventory database and the BigFix platform server.
  - Common problems
    Learn how to solve some common problems with the server installation, configuration and administration.
  - Logs and return codes
    Find logs and interpret return codes to troubleshoot issues.
    - Database creation logs and return codes
      The log file is automatically generated when you create a database during the initial configuration of BigFix Inventory. The log file contains a return code that can help you check why database creation or validation failed. The file is in the /tmp directory and has a time stamp suffix, for example: /tmp/createdb_20131018-131841.
    - Server installation and upgrade logs
      Installation and upgrade log files are in the same directories, because those processes are completed by using the same installer. If you encounter any problems while installing or upgrading the server, refer to those log files for more information about any occurring errors.
    - Server installation and uninstallation return codes
      If the server installation or uninstallation fails, check the return code to learn about the reason of the problem and possible solutions.
    - Software scan return codes
      If the software scan fails, an error code that indicates why the scan failed is returned. Check what is the possible cause of scan failure that is indicated by each code and how to solve the problem.
    - Capacity scan return codes
      If the capacity scan fails, an error code that indicates why the scan failed is returned. Check what is the possible cause of scan failure that is indicated by each code and how to solve the problem.
    - Whitelisting scanner
      This section describes the methods to whitelist scanner services.
    - Return codes of capacity scans on virtualization hosts
      If the capacity scan that is run by using the Run Capacity Scan on Virtualization Hosts task fails, an error code that indicates why the scan failed is returned. The code is presented in the results of the Status of Capacity Scan on Virtualization Hosts analysis. Check what is the possible cause of scan failure that is indicated by each code and how to solve the problem.
    - Import logs
      Import logs contain information about the import of data from the BigFix server to BigFix Inventory. They list steps related to the import process and show their status. Each action in the log file is reported according to the UTC time zone, but the file also shows information about the local time zone of your server. The import log also shows a warning about duplicate UUIDs (universally unique identifier).
    - Server log file
      The server log file tema.log is in the installation_directory/wlp/usr/servers/server1/logs/ directory. The log file saves all actions related to the server and is the primary source of information for troubleshooting purposes. Each action in the log file is reported according to the UTC time zone, but the file also shows information about the local time zone of your server.
    - VM Manager tool return codes
      If you encounter any problems while configuring or managing the VM Manager tool, refer to the log files for more information about any occurring errors. The log files for the VM Manager tool are in the following directories:
    - Changing and analyzing scanner trace settings
      You can change the scanner trace settings to collect diagnostic data to help in investigating problems.
    - Checking why a fixlet or task is not relevant
      Available from 9.2.1. When a fixlet or task is not relevant on a particular endpoint, you can create an analysis that checks which part of the relevance expression is not matched. This way, you can identify the exact reason why the fixlet or task cannot be run on an endpoint and troubleshoot the problem.
    - Removing the server manually
      If you encounter any problems with uninstalling the BigFix Inventory server, you can remove it manually.
    - Checking the client installation date
      You can create a property on your BigFix server that enables the date when your endpoints first connected to the server.
    - Changing the PVU per core value
      Available from 9.2.3. The number of processor value units is assigned per processor core based on the information that is provided in the PVU table. It might happen that the value that is assigned to a processor in your environment is incorrect. In such case, manually change the PVU per core value to ensure that subcapacity licenses are properly calculated. When the problem that causes incorrect detection of the PVU value is solved, reset the PVU per core to the value that is specified in the PVU table.
    - Troubleshooting scanner catalogs update
      Scanner catalogs are used by the scanner to discover software on the endpoints. The catalogs are automatically updated after each import of the BigFix software catalog. Use this procedure only if the automatic update of the scanner catalogs fails or one of the Advanced Server Settings: enable_automatic_task_deployment or enable_automatic_catalog_download is set to false.
    - Preserving bundling when the BigFix client is reinstalled or reverted from a snapshot
      When the BigFix client is reinstalled or reverted from a snapshot, the next time it registers at the BigFix server, it receives a new Data Source Computer ID. The BigFix client with the old Data Source Computer ID becomes inactive because it does not report with the same Computer ID. As a result, the BigFix console shows duplicated entries for the same computer. Additionally, the affected computer loses bundling information for software that was discovered on this computer. To avoid this situation, store some registry keys data aside of the computer whose identity you want to preserve.
    - Setting the code page for double-byte languages
      Double-byte character corruption can occur in some environments because BigFix Inventory uses the code page to transcode data. For double-byte languages such as Korean, Japanese, and Chinese, set the code page to avoid character corruption.
    - Contacting Software Support
      HCL Support provides assistance with product defects.

Return codes of capacity scans on virtualization hosts

If the capacity scan that is run by using the Run Capacity Scan on Virtualization Hosts task fails, an error code that indicates why the scan failed is returned. The code is presented in the results of the Status of Capacity Scan on Virtualization Hosts analysis. Check what is the possible cause of scan failure that is indicated by each code and how to solve the problem.

Table 1. Return codes of capacity scans on virtualization hosts
Return code	Possible cause and solution
0	No errors.
20	Unsupported virtualization type. To solve the problem, perform the following steps: Verify that the computer on which you ran the task is a virtualization host. If it is not, you do not need to run the task on this computer. Verify that the computer runs on a supported virtualization. If the virtualization is a supported version of PowerKVM, KVM x86, Citrix Hypervisor (formerly XenServer), contact BigFix Support. If it is a different type of a supported virtualization, configure VM managers to collect capacity data from these hosts. For more information, see: Adding VM managers in central mode.
30	KVM virtualization architecture could not be recognized. KVM virtualization was detected, but testing the virsh command to determine whether the architecture is x86 or Power failed. Contact BigFix Support.
40	Determining the number of processor sockets or cores failed. The returned result is not a number. Contact BigFix Support.
50	No valid host UUID could be retrieved by using the xe, dmidecode, and xl command. Verify that the UUID of the computer is correctly returned by SMBIOS. If it is not correctly returned, contact the hardware vendor to solve the problem.
Other codes	If other codes are returned, check the run_vtech_scan.log log file to learn running which command returned the code. The log file is in the installation directory of the BigFix client, by default: var/opt/BESClient/BFI/vtech/run_vtech_scan.log.