Troubleshooting

This section helps you troubleshoot some common issues or limitations.

Unexpected error in InspectorDataJSONCallback" message in plugin portal log
Description: After installing a cloud plugin, no discovered resources show up in the BigFix Console, and the log of the plugin portal contains the following error message:
Mon, 30 Mar 2020 18:31:56 +0200 - 28965245 - Unexpected error in InspectorDataJSONCallback 
No suitable servers found: `serverSelectionTimeoutMS` expired: [connection refused calling ismaster 
on 'localhost:27017'] .
This issue can occur up to BigFix Version 10.0.8.
Reason: This error message might be due to the MongoDB being stopped.
Solution: Start the MongoDB. On Windows this may be done from the Windows Services tool, on Linux by issuing the systemctl start mongod command.
BESPluginPortal not running after installing a cloud plugin
Description: After installing a cloud plugin, the BESPluginPortal process is not running.
Reason: This behavior is unexpected and might be due to unpredictable reasons that need to be investigated.
Solution:
  • On Windows:
    • Try restarting the BESPluginPortal process from the Windows Services tool.
    • If the BESPluginPortal is still not running, verify the presence of errors related to the BESPluginPortal process in the Windows Event Viewer.
  • On non-Windows:
    • Try restarting the BESPluginPortal process by issuing the /etc/init.d/bespluginportal start command.
    • If the BESPluginPortal is still not running, verify the presence of error messages related to the BESPluginPortal process in /var/log/messages.
AWS plugin cannot discover resources due to authentication failure (status code: 401)
Description: The AWS cloud plugin fails to perform a resource discovery and logs the following error message:
2020/03/30 15:50:22 - [error] Got error calling DescribeRegions: AuthFailure: 
AWS was not able to validate the provided access credentials
status code: 401, request id: 1879798f-b446-4ar1-acdc-w35a1ut3y0u
Reason: The error message may be displayed in the following use cases:
  1. The specified Access Key ID / Secret Access Key pair is either wrong or inactive.
  2. The specified Access Key ID / Secret Access Key pair is associated to a SessionToken as part of a temporary credential set created by assuming a IAM Role.
  3. Date and time of the computer on which the AWS plugin is installed is not accurate.
Solution: Depending on the use case, the solution differs as follows:
  1. Verify that the specified Access Key ID / Secret Access Key pair is correct and that its status is active.
  2. Temporary credentials associated to a Session Token are not supported. Replace the credentials with an Access Key ID / Secret Access Key pair associated to a IAM User.
  3. Adjust the clock (date, time and timezone) of the computer where the AWS plugin is installed (+/- 5minutes should be the maximum deviation tolerated by AWS). For more information about signing incoming requests, refer to the AWS documentation.
Correlation computers not included in automatic computer groups
Description: When creating an automatic computer group with inclusion criteria that refer to the IDs of correlation computers, neither the correlation computers nor any of the correlated representations are included in the group.
Reason: Correlation computers represent logical entities that are only known to the BigFix Server, therefore no BigFix Agent answers for the ID of a correlation computer.
Solution: None. This is the expected behavior.
Distinct VMware computers correlated with each other
Description: Two distinct proxied computers of VMware type are correlated under the same correlation computer.
Reason: By design, the BigFix Server correlates VMware computers that are reporting the same value for the "BIOS UUID" property of the "VMware Resources" analysis. Although this value is generally expected to be unique in VMware, there are documented cases that might lead to having duplicated values, like converting a VM using the VMware converter or cloning a VM (not a template). For further information about the BIOS UUID duplication, refer to the VMware Knowledge Base.
Solution: To eliminate a duplicate BIOS UUID, refer to the official VMware documentation (for example: Editing a virtual machine with a duplicate UUID.bios). At the next discovery of the VMware plugin, after removing the BIOS UUID duplication, the unexpected correlation should be removed automatically.
VMware plugin does not discover some resources
Description: Some devices are not discovered by the VMware plugin. In the example, two instances are discarded:
2022/01/12 12:18:31 +0100 - [info] Refresh all: Discovery returned 8 unique devices
2022/01/12 12:18:31 +0100 - [debug] Refresh all: Reported instances: 10 - Unique instances: 8 - 
Terminated instances: 0 - Null instances: 0 - Other errors: 0
Reason: The VMware plugin uses the vm.uuid as the unique key during its discovery. A device discovered that has not this key will not be considered by the plugin.
Solution: None. This is the expected behavior.
Cloud computers often displayed as offline
Description: The BigFix Console often shows proxied computers, discovered by the cloud plugins, offline.
Reason: By default, the cloud plugins have a discovery frequency of 120 minutes. This time interval is bigger than the default value for the "Mark as offline after" preference of the BigFix Console, which is 45 minutes. As a consequence, 45 minutes after the latest discovery performed by the cloud plugins, the proxied computers start displaying as offline on the BigFix Console, until the next discovery occurs.
Solution: This is the expected behavior when using the default values for the discovery frequency of the cloud plugins and for the "Mark as offline after" preference of the BigFix Console.