Hardware inventory problems

Find the solution to the issues that you have encountered while working with virtual machine managers and hardware inventory.

Update of the VM Manager tool fails
When you run the Update VM Manager Tool to version fixlet, the update fails. When you view the details of the action on a particular computer, the script can fail on various lines, for example:
waithidden cmd /c "rmdir "{parameter "homefolder"}" /s /q"
continue if {exit code of action = 0}
To solve the problem, perform the following steps:
  1. Go to the computer on which the update of the VM Manager tool failed and open the <BES_Client>/LMT folder.
  2. If the folder does not contain the VMMAN_copy folder, create it.
  3. Copy the config and keydb folders from the <BES_Client>/LMT/VMMAN folder to the <BES_Client>/LMT/VMMAN_copy folder.
  4. Remove the VMMAN folder.
  5. Run one of the following fixlets to complete the update. It might take some time before the fixlet becomes relevant.
    • Run the Install VM Manager Tool version number fixlet, if the update failed on the computer where the main instance of the VM Manager tool is installed.
    • Run the Install Additional VM Manager Tool (OPTIONAL) version number fixlet if the update failed on the computer where an additional instance of the VM Manager tool is installed.
Error message CODVM0005E is displayed when attempting to connect to the VM manager over SSL.
When trying to connect to the VM manager over SSL, an error message is displayed: CODVM0005E An error occurred when attempting to connect to the VM manager at the following address: hostName. To solve the problem, complete the following steps:
  1. Go to https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?source=jcesdk.
  2. Provide your BigFix ID and password and click Sign in. You might need to register with BigFix to download the files.
  3. Select Unrestricted SDK JCE Policy files for Java 5.0 SR16, Java 6 SR13, Java 7 SR4 and later versions and then click Continue.
  4. View the license agreement, select I Agree, and then click I confirm.
  5. Click Download Now.
  6. Extract the files and copy them to the following directory:
    <BES_Client>/LMT/VMMAN/java/jre/security
  7. Restart the server.
Server is running, but an exception in traces appears. The exception is related to the connection with the specified ESX with the following message: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
  1. Add the following lines to file /etc/vmware/hostd/config.xml:
    ..
        <ssl>
           <doVersionCheck> false </doVersionCheck>
           <handshakeTimeoutMs>30000</handshakeTimeoutMs>
        </ssl>
        <http>
            <readTimeoutMs>45000</readTimeoutMs>
            <writeTimeoutMs>45000</writeTimeoutMs>
            <blacklistPeriodMs>3000</blacklistPeriodMs>
        </http>
        <vmdb>
          ...
  2. Restart the hostd service using service mgmt-vmware restart.
  3. Verify that the exception does not occur.
Server is running, but an org.xml.sax.SAXParseException exception in traces appears. The exception is related to the connection with the specified ESX.
Make sure that you have the latest patches to your problematic ESX server installed.
Upgrade of vCenter server from v5.0 to v5.1 causing server connection failure.
The following message is displayed CODVM0003E The VM manager denied access because of invalid credentials. To solve this issue, perform the following steps:
  1. In vCenter, stop all sessions under a user name that is defined as a user credential in VM manager for specific vCenter.
  2. Remove this user name.
  3. From vCenter, add the user name back with read-only or propagation authorities.
  4. Redefine the VM manager entry for this specific vCenter using the same user name credential.
Specification of the domain for the user name for VM Managers is inconsistent.
Different definitions of users are used for each type of VM manager:
  • For Microsoft Hyper-V, you must use the Administrator account. The user is defined as user_name\domain or user_name@domain. For example: test\cluster.com or test@cluster.com.
  • For VMware, the user is defined as domain\user_name, for example: cluster.com\test.
  • For RHV-M, the user is defined as user_name@domain, for example: test@cluster.com.
  • 9.2.12 For Citrix Hypervisor (formerly XenServer), the user is defined as user_name, for example root.
  • 9.2.14 For Oracle VM Server for x86, the user is defined as user_name, for example: test.
  • 9.2.17 For Nutanix, the user is defined as user_name, for example: test.
Changes to the VM managers are not updated on the BigFix server.
Changes to the VM managers are not updated on the BigFix server and the following error message is displayed in the VM Managers panel: The last modification of VM managers was not processed correctly on the BigFix server. The data is not synchronized with the VM Manager Tool.
To solve the problem, make sure that the VM Manager tool is installed. You can also check the history of the Configure VM Manager Tool action in the BigFix console to investigate the failed step. Additional information can also be found in the BigFix console log files that are in one of the following directories:
  • /var/opt/BES Client/__BESData/__Global/Logs
  • C:\Program Files (x86)\BigFix Enterprise\BES Client\__BESData\__Global\Logs
The connection test does not finish.
See the solution for: Data from VM managers is not updated on the BigFix server.
Connection to Hyper-V fails with the following error: The RPC server is unavailable.
Ensure that port 135 as well as all Windows dynamic ports are open for communication.
Data from VM managers is not updated on the BigFix server.
If you run a connection test for a VM manager and it does not finish, it might indicate a problem with the BigFix client that is installed on the BigFix server. If the client is stopped, actions that you perform in BigFix Inventory are sent to the BigFix server but the status is marked as Not reported. To determine further actions, investigate the BigFix client that is installed on the BigFix server.

For the same reason, data from VM managers might not be uploaded to the BigFix server. Check the value in the Last Successful Operation column to verify if the data was recently sent to the server.

Actions that are performed in the VM Managers panel, such as testing the connection or adding a new VM manager, fail.
If actions that you perform in the VM Managers panel fail, you can log in to the BigFix console that is linked to your primary data source and check the history of recent actions, such as Configure VM Manager Tool or VM Manager Tool - connection test. By doing so, you can investigate details of the failed step and determine the solution. If you are not sure which data source to connect to, log in to BigFix Inventory and click Management > Data Sources.
To check the history of recent actions, complete the following steps:
  1. Log in to the BigFix console that is linked to your primary data source.
  2. In the navigation tree, click Computers.
  3. In the upper-right pane, select the computer that is defined as your primary data source.
  4. In the lower-right pane, click the Action History tab.
  5. Double-click on one of the recent actions that failed:
    • If the connection test was unsuccessful, check the VM Manager Tool - connection test action.
    • If modification of VM managers failed, check the Configure VM Manager Tool action.
  6. In the new window, click the Computers tab.
  7. Double-click on the action.
  8. Locate the failed step and check the details.
The VM Managers panel is blocked or contains error messages.
The VM Managers panel is either blocked completely, with no possibility of performing any actions, or it contains one of the error messages that instruct you to install the VM Manager tool or the BigFix services.
To solve the problem, complete the following steps:
  • Ensure that the BigFix server and client are installed on the target endpoint.
  • Install and start Web Reports on the BigFix server. For more information, see: Installing the Web Reports.
  • Subscribe the BigFix server to the BigFix Inventory site.
  • Make sure that the content of the BigFix Inventory site is up-to-date. If your computer does not have access to the Internet, see: Downloading files in an air-gapped environment.
  • Subscribe the target endpoint to the BigFix Inventory site.
  • Make sure that the VM Manager tool is installed. For more information, see: Installing the VM Manager tool.
CPU frequency that is displayed on the Hardware Inventory report equals zero
CPU frequency is an additional parameter. It is retrieved only from computers that are not managed by VM managers or from virtual machines that are not in the OK status. CPU frequency values do not influence PVU calculations.
Virtual machines that are managed by the VMware vCloud Director have duplicate BIOS UUIDs.
The problem occurs when virtual machines are deployed from catalog templates. To work around the problem, see: BIOS UUIDs in vCloud Director are not unique when virtual machines are deployed from catalog templates (2002506).
The Hardware Inventory report in BigFix Inventory displays No Scan Data after capacity scans were run on VMware guest operating systems.
The import log contains multiple occurrences of the following errors.
Some error occurred during importing the capacity scan from file :
capacity_scan_file_name.xml for endpoint : 
endpoint_number.
getNodeInfo Error: VMware VirtualMachine UUID (06XZXA0) do not match with the UUID pattern!
In the scan files uploaded by the clients, the UUID tag contains the hosts serial number instead of the virtual machine UUID. Example:
<VirtualMachineGuest version="1">
           <UUID>06CZFCV</UUID>
           <HypervisorType>VMware</HypervisorType>
</VirtualMachineGuest>   
BigFix Inventory requires unique virtual machine UUID numbers to properly calculate the capacity for all virtual machines. This error might be caused by the host serial number appearing in the place where virtual machine UUID is normally recorded. If you install an operating system with the so-called Reseller Option Kit (ROK) media, some data might be obtained from the server BIOS, instead of from the virtual machine.
To enable the correct retrieval of UUID data from operating systems installed with the ROK media, edit the virtual machine's .vmx file and set the reflectHost parameter to false. Example:
SMBIOS.reflectHost = "false"
If the problem persists, force the upload of capacity scan data. To do this, perform the following steps.
  1. Log in to the BigFix console.
  2. In the navigation tree, go to Fixlets and Tasks and select the Run Capacity Scan and Upload Results fixlet.
  3. In the lower pane, click Take Action, and choose Click here to run a single capacity scan and force upload of results.
  4. Open the Target tab and select the computers that you want to scan. Then, click OK.
  5. Wait for the scheduled import, or run it manually.
Data on the Hardware Inventory report is outdated.
The problem might occur when the import of capacity scan data fails. To solve the problem, perform the following steps:
  1. Log in to the BigFix console.
  2. In the navigation tree, go to Fixlets and Tasks and select the Run Capacity Scan and Upload Results fixlet.
  3. In the lower pane, click Take Action, and choose Click here to run a single capacity scan and force upload of results.
  4. Open the Target tab and select the computers that you want to scan. Then, click OK.
  5. Wait for the scheduled import, or run it manually.
When the scan finishes, its results are uploaded to the BigFix server. After the data is imported to BigFix Inventory, the Hardware Inventory report should be up-to-date.
The Hardware Inventory report displays no Processor Brand String data.
The problem might occur after the migration, or upgrade. To see the Processor Brand String data on the report, force the upload of capacity data by completing the following steps.
  1. Log in to the BigFix console.
  2. In the navigation tree, go to Fixlets and Tasks and select the Run Capacity Scan and Upload Results fixlet.
  3. In the lower pane, click Take Action, and choose Click here to run a single capacity scan and force upload of results.
  4. Open the Target tab and select the computers that you want to scan. Then, click OK.
  5. Wait for the scheduled import, or run it manually.
Computers have the No Scan Data status because results of the capacity scan were removed from the BigFix Inventory server
Results of the capacity scan are stored in a folder on the computer where the BigFix Inventory server is installed. If the folder is removed, the status of computers on the BigFix Capacity Completeness widget changes to No Scan Data. If the results of the next capacity scan differ from the results that currently exist on the scanned computers, they are uploaded to the BigFix Inventory server. Then, the status of computers changes from No Scan Data to OK. However, if the results of the next capacity scan are the same as the results that exist on the scanned computer, they are not uploaded and the computers remain in the No Scan Data status. To solve the problem, perform the following steps.
  1. Log in to the BigFix console.
  2. In the navigation tree, go to Fixlets and Tasks and select the Run Capacity Scan and Upload Results fixlet.
  3. In the lower pane, click Take Action, and choose Click here to run a single capacity scan and force upload of results.
  4. Open the Target tab and select the computers that you want to scan. Then, click OK.
  5. Wait for the scheduled import, or run it manually.