Home
Troubleshooting and support
Learn about solutions to common problems that might arise when you use 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.
Removing the server manually
If you encounter any problems with uninstalling the BigFix Inventory server, you can remove it manually.

Troubleshooting and support
Learn about solutions to common problems that might arise when you use 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.
- 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.
  - Incorrect software is displayed on reports due to incorrect bundling
    Automated bundling 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 automated bundling 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.
    - 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.
    - 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.
    - 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.
    - Updating scanner catalogs
      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.
    - 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.

Removing the server manually

If you encounter any problems with uninstalling the BigFix Inventory server, you can remove it manually.

Procedure

Run the following command to verify that the process associated with the server is running:
```
ps -ef | grep <installation dir>/cli | grep server1
```
Tip: The ID of the process is the number next to the user name.
End the process by running the following command:
```
kill -9 <process ID>
```
Remove the directory in which you installed BigFix Inventory:
```
rm -rf <installation dir>
```
For example:
```
rm -rf /opt/IBM/BFI
```
Edit the .com.zerog.registry.xml file that is in the /var directory. If you installed the server as a non-root user, the registry file is in $HOME/.
In the registry file, locate the entries that are related to BigFix Inventory. Remove the entries that represent the product and all the related components. You can recognize them by the product name and a common file path. If the registry file contains entries only for BigFix Inventory, you can delete the whole file.