Stubborn Clients

Usage and Config Platform
1

I have a couple of clients that don’t seem to want to take any actions or commands from the sites they are subscribed but they post their report after the evaluation cycle has completed so it looks like the client is functioning as far as analyzing and sending results. If we restart the client it takes the actions that are open and continues normally for a time then after a while it stops taking actions again. Without having log in access to this device and without having to go to our SAs to restart the BESClient service, what is solution for this? The next chance I get I plan to implement the command polling setting but until it gets the newest version of the site, it won’t take the action to set it.

Any ideas?

1 Like
2

You should definitely enable command polling. I am enabling command polling for once every 6 hours for all clients and once an hour for all clients that are not receiving the UDP notifications. Command polling primarily impacts the Parent Relay of the client, which I am not concerned about putting more load on.

This does sound like the clients are not getting the UDP notifications from their parent relay, which should mean firewall/network related problems.

What is the “last command time” as found here: http://bigfix.me/analysis/details/2994765

What happens when you right click and send refresh and/or send client alert?

Are any power saving settings enabled on the client?

3

I’m not sure of any firewall issues. The image this server was built from doesn’t show the same issue with other servers built from the same image so there shouldn’t be any additional local rules rejecting the UDP commands.

I wouldn’t be able to implement this until it starts responding again

Nothing. The log doesn’t show it received the ping.

None that I’m aware of. No other servers of this OS/image have this issue that I can see.

4

Actually I implemented it from another thread you posted this in a few weeks ago. It actually reads none for this particular endpoint.

1 Like
5

If the last command time is none, then this client is not receiving UDP notifications from it’s parent relay.

You should set command polling to something like once an hour on a client like this: http://bigfix.me/fixlet/details/3798

  • ( this will work as a policy action applied to all clients, but you should test it. You might want to tweak some of the days of delay thresholds in the relevance, or have another task that automatically increases the command polling time if UDP commands start getting through. )

You should also investigate firewall issues of the client itself and any NAT or firewalls between it and it’s parent relay. In this case it is UDP traffic from the Relay to the Client that is not getting through.

Does the client have a public or private IP address? Is it behind a NAT? Is it behind a Hardware Firewall?

6

Private IP, not NAT’d, and it is behind the same firewalls of other servers responding on its subnet.

7

Then I would look at the OS firewall of the client itself. It needs to allow incoming UDP over 52311 (assuming you are using the default bigfix ports)

8

Just be aware it will show none if the client has just started. But if the client has been running a while and you have sent new sites or a Refresh then it definitely should show something if UDP is getting in

1 Like
9

I didn’t realize that relevance was reset by the client starting. I figured it would persist.

10

It’s less the relevance and more the statistics. They are stored client side and when a client is restarted, the statiistics wipe and report in with nothing.

11

Actually you’re right (I forgot I serialized that out)

What I was more meaning to mention is that you should always check the last command time against the last registration time to see if THAT relay can send you anything.

1 Like
12

Good to know. I was worried that I would have to fall back to parsing the logs when that relevance returns none like this:

http://bigfix.me/relevance/details/2996924

13

A bit of a long shot, but is it possible you have another application grabbing port 52311?

You’d see that in the results of netstat -anob

Depending on whether you’ve customized the ephemeral port range, you may need to reserve 52311 to prevent the OS from allocating that to applications randomly.

There’s a fixlet for that in the BES Support site.

1 Like
14

This can happen on DNS machines. There are fixlets in BES Support make the ephemeral ports not use the BigFix port for Windows.

15

jmaple,

Usually when I see clients that are responding, but not picking up actions, it can be one of the other causes already discussed or it can be that part of the site metadata on the client is corrupt. If the client takes an action from one site, but not another site, that is a good clue. Sometimes that actionsite itself on the client becomes corrupt.

Chkdsk sometimes resolves these. Sometimes stopping the client and moving (not copy or delete) the offending site to another part of the file system (make a folder outside of the client folder structure). Sometimes the site signature gets corrupt on the client. When content in the site is altered and a new signature is generated, that can also cause clients to suddenly start working again.

I’ve also seen similar issues on relays too.

1 Like
16

I’ve seen two kind of conditions causing this,

1.- Network related configurations, NATs and specially when the servers and IEM server don’t share same network.
2.- IEM relay issues.

So be sure you can send UDP packages from IEM server to IEM endpoint.

17

Hello jgstew

I would like to understand how I can upload “http://bigfix.me/fixlet/details/3798” BES file in my iLMT Server.
My ILMT Server is not connected to internet. I have downloaded the file "Configuration-BES_Client-Automatically_enable_Command_Polling-_Universal.bes"
I would like to know
1- how to upload this file to my ILMT 9.2 Windows Server ?
2- How to apply this Configuration to on limited Servers … Not in all Server.

Many Thanks

1 Like
18

The .BES file needs to be imported into your IEM Environment.

There are two possible ways to do this …

  1. Double Click the ,BES file from a computer with the Console installed.
  2. or from an open Console, open the File menu and select Import… and select the .BES file.

Once you have done one of the above activities, you will see a “Create Fixlet” dialog.

  1. Select the site where you want to save the Fixlet and click OK.
  2. The Console will save the new Fixlet.
    Since you have systems that are not receiving their UDP messages, it will take a while for them to discover the new Fixlet and report their status. If you want to force the process, restart the BESClient service on a few of the machines you want to test with. Otherwise it will take up to 24 hours for clients to report their Applicability.
  3. Once you have systems reporting as “Applicable” to the new Fixlet you can deploy an Action based on the Fixlet and select the Target Computers you want it to apply to, just like any other Fixlet content.
1 Like