Please Help! BESClients Not Reporting

Hi There, Hopefully someone can help please.

We installed BigFix 9.5.15.71, BesClients to our servers and ILMT 9.2.21.

All was reporting in correctly. We ran the fixlet to upgrade to 10.0.1.41 which was successful and installed BigFix console 10.0.1.41. When trying to log into the console we got an error but it stated in the upgrade Fixlet to run

/opt/BESServer/bin/BESAdmin.sh -syncmastheadandlicense

We did this and could then login to BigFix console OK. All servers with BESClients started reporting in and it all looked good.

The problem we have though is that when issuing commands via the fixlets (eg: Run capacity scan, run software scan etc) just state not reporting, nothing seems to happen. This was working fine on 9.5.15.71 prior to us upgrading.

Can anyone give some support or advice please? Saw somewhere that running hte “rotateserversigningkey” command might help but dont want to cause any issues.

Thanks in advance!

@gb38, did you tail the daily yyyyMMdd BESClient log on a targeted endpoint and grep/highlight for the action ID in question? Need more details in order to help.

If this is a critical issue, you may want to open a support case with L2.

No matter what Fixlet I run against these servers, they all just sit there stating “Not Reported”. When running 9.5.15.71 they responded in minutes and tasl completed quickly.

Nothing has changed besides upgrading to 10.0.1.41.

By tailing, do you mean checking the log file on the clients in /var/opt/BESClient/__BESData/__Global/Logs

Correct. So you can do this on your root BES server as the syncmastheadandlicense command in your 1st post referenced the Bash script under /opt/BESServer.

tail -f /var/opt/BESClient/__BESData/__Global/Logs/20201104.log | grep ACTION_ID

However, I would run this on one of the endpoints you’re working to troubleshoot.

You can also enable the Relay Diagnostic to validate that the infrastructure is working as expected.

Thanks for your help.

I will try run this on an endpoint.
tail -f /var/opt/BESClient/__BESData/__Global/Logs/20201104.log | grep ACTION_ID

I just tried to enable the relay diagnostic but as no fixlets work its just sitting there as (Not Reported)

Is this possibly an issue of UDP messages blocked ? You might select 2 or 3 clients in the console and ‘Send Refresh’ to them. Now check if the UDP message were received by the clients.
[root@bfrh77a ~]# grep Force /var/opt/BESClient/__BESData/__Global/Logs/202010*.log
/var/opt/BESClient/__BESData/__Global/Logs/20201030.log: ForceRefresh command received. Version difference, gathering action site.
If not, maybe add ‘command poll’ settings ?

1 Like

Please remember that ACTION_ID must be changed for the actual Action ID from the BES console.

Thanks.

I only have one fixlet trying to run at present, Run Capacity Scan.

How to do know what the ID is for this?

Just add the ID column in the Actions view of the BES console as shown in the screenshot below.

Interestingly, I just deployed manually the 10.0.1.43 agent to a few servers that were running 9.5.15.71. These are now working and responding to fixlets. I thought that BESClients running a version lower than the BESServer were backward compatibile?

Down-level BESClients should have no issues communicating with BFv10.x infrastructure.

Thats what I would have thought as per previous versions. Very strange. Bug maybe? Will upgrade all to 10.0.1.43 then see if all our issues are resolved.

Sorry, need some more help please. Ended up restarting the BESClient on our servers. After this the capacity scans started to all run and were successful. I was thinking we had solved it but then we then ran the initiate software scan fixlet across All Computers. Only 4 servers in the list run the task. When I setup a relevance check for Initiate Software Scans, the same 4 servers are the only ones that show “results” in the tab.

Anyone have any idea whats wrong here, this thing is doing my head in! :slight_smile:

@gb38, given the details provided thus far, I’m highly recommending that you open a support case with L2 so that appropriate logs and configuration details can be collected from your environment and if necessary raised to L3 for further analysis.

Thanks. Will do now.