How can we restart BES client services on machines not reporting to BES console

How can we restart BES client services on machines not reporting to BES console?

manually one machine re-mediated by BES client services re-start and it’s started reporting in console. I wanted to apply the same work around on machines which are not reporting online in console.

Almost few years now I am not in touch with BigFix and due to that can’t recall the process how to action on it.

Thanks.

There are fixlets on BES Support to restart the client service; of course, if the server won’t receive a good report from the client for days, the restart action will expire.

If some of your clients are not reporting, you should investigate the issue (firewall/proxy misconfiguration, corrupted reports, connection issues, performance issues on FillDB, etc.).

If your clients are crashing for some reason, for Windows systems the BES Client Helper is available. Even in this case, an investigation about the reason of the crash is recommended.

Yes, I did check and found it’s one of relay server decommissioned from round robin DNS.
and my doubt is the client are not trying to register the same relay and getting registration failed. I found this on one of the machine and rectified manually.
Now trying apply the same relay settings on multiple machines which are not report since 10 days and want to do this job automate from console. Manually it is time taken task.
Finding the solution :slight_smile:

If you shut off the Relay service on the decommissioned relay, its clients should choose another during their next relay selection.

All of the above.

And we also have a similar issue with our Linux clients where they appear to be reporting in (or some just go offline in the console for hours at a time) but will not respond to refreshes or commands sent to them via BF. Our work around is running a script from a centralized server to ssh to the Lx machines to restart the clients…

that’s not happening. machines are not connecting secondary relay.

finding the root cause.

If they are not responding to commands, they likely have a host-based firewall active and you’ll need to enable udp/52311 inbound. Have a look at firewall-cmd.

Hmmm good one. Let me check.