Clients not reporting after a reboot

(imported topic written by MattBoyd)

All of our lab computers perform a nightly wake-and-reboot. We do this for several reasons, which I won’t list here. We would like the computers to report into BigFix after the reboot before re-entering standby (15 minutes). In fact, we would expect this to happen immediately since the client service is cycled during the reboot. However, this isn’t always the case. For whatever reason, the client does not report in before going into standby. The logs do not show any errors and it appears that the client is working fine. The clients will report in if I send a refresh.

I was under the impression that the client service would report in immediately upon startup. Is there any reason why this isn’t occurring on many of our computers? Is there any way to force the client service to report to BES immediately upon startup?

(imported comment written by BenKus)

Hey boyd,

I believe the agent will try to finish a loop processing all actions and all Fixlets before it reports after it is restarted… and in fact the initial loop will take the longest (since it hasn’t had a chance to cache/fingerprint many queries).

Can you up the CPU usage for the agent for that time of night (either through an external mechanism or through a dynamic BigFix setting?)

Ben

(imported comment written by MattBoyd)

I can certainly give that a try. When you say dynamic BigFix setting, are you referring to using a task to update the CPU usage settings depending on the time? One thing I’ve noticed with the CPU settings is that they don’t appear to apply until the service is restarted…

I have found that sending a forceRefresh from the console seems to force the client to check in regardless of whether it’s still processing actions. Is there any way to generate the “UDP Ping” packet on the local system and send it to port 52311 to force the refresh? I’ve looked at the packet with a network monitor, but I can’t figure out what’s contained in it…

(imported comment written by BenKus)

Here is some info on dynamic settings:

http://support.bigfix.com/cgi-bin/kbdirect.pl?id=281

The UDP packet tells the client to leave “workidle mode” and go into “worknormal mode”, which uses more CPU… it also will report before and after it does an evaluation loop.

I believe the CPU settings will take effect only when the agent starts its evaluation loop…

There is an application “NotifyClients.exe” on the BigFix Server that can be used to generate a UDP packet for the agents… but the packet will come from the server and not from the local agent.

Ben

Ben

(imported comment written by MattBoyd)

Ben Kus

Here is some info on dynamic settings:
http://support.bigfix.com/cgi-bin/kbdirect.pl?id=281

Thanks for the new knowledge, I didn’t realize it could be done that way. I’m assuming that the task used to deploy the dynamic setting must be set as a policy, correct?

Ben Kus

I believe the CPU settings will take effect only when the agent starts its evaluation loop…

So does that mean it probably won’t really have any effect? If the client is still in the evaluation loop when Windows re-enters standby…

Ben Kus

There is an application “NotifyClients.exe” on the BigFix Server that can be used to generate a UDP packet for the agents… but the packet will come from the server and not from the local agent.

So just to clarify, there is no way I could tell the client to refresh from the local computer? Is there something in the packet that cannot be reproduced client side? I am willing to write an application that builds and sends the packet locally to induce a forceRefresh…

(imported comment written by BenKus)

Hey Boyd,

Client settings actions do have a higher priority so they tend to be noticed faster by the agent, but you still can’t guarantee it…

Rather than trying to craft the UDP packet, I would recommend changing the CPU settings and restart the agent, if you give the agent full CPU access, it will tend to do everything very fast… You can make a policy action to restore the normal cpu settings when it is outside of the nightly window (which should take effect quickly because the agent will have more CPU to work with).

Ben