We have a time-sensitive server automation custom application Planman.exe. This application is scheduled to start a server automation plan at 04:30 am and send instructs the BigFix server to refresh the client using http://192.168.11.111:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=NotifyClient&Body=ForceRefresh&ComputerID=5691271. I understand BigFix servers send UDP packet to refresh client. If the client does not receive the UDP packet, the client does not check with the BigFix server. Then, our server automation application at the BigFix server fails timeout.
What are other ways of guaranteed client refresh via script? Appreciate your advises.
What problem are you trying to solve here? You shouldn’t have to send a ‘ForceRefresh’ command to clients for them to ‘check in’. In fact, sending the Client a refresh can slow other tasks/operations down as it pauses them to process the refresh request.
Thanks for the response. I noted your comments on good practices.
Our current setup is like that. Every day at 04:30 am, the Server Automation Plan starts in the BigFix Server. The SA application then sends the force refresh to clients to check in and execute the new BigFix tasks. We have the log that shows that the SA application did send a force refresh. But the client side is not received. The problem is that if the client doesn’t execute the BigFix task of the SA plan within 5 minutes, then the SA Plan is considered to fail, and our application requires manual intervention.
How to troubleshoot the ForceRefresh related issues?
The links @vk.khurava posted are the place to start. UDP, Persistent Connections, and Command Polling should help.
Your Force Refresh would not help though, sadly. If your endpoint receives the action notification, it will execute the action; but if it doesn’t receive the action notification, it won’t receive the Force refresh message either.
Thank you for the information. We also noticed when the Force Refresh was not received, and the client also did not receive the other action notifications for nearly 10 to 15 minutes. We thought the reason could be UDP packet loss.
Our application is time-sensitive. The first business process should start at 04:30 am with 5 minute timeout.
Does enabling the persistent connection setting on each client ( _BESClient_PersistentConnection_Enabled) guarantee the ForceRefresh command is received? Does this setting use TCP instead of UDP?
Enabling the persistent connection setting on client does not directly guarantee that the ForceRefresh command will be received similar to any other thing out there, each setting is designed to help with something but there are other aspect also involved with it hence saying it will give guarantee will not be right.
The persistent connection feature in the BigFix is designed to improve the reliability and efficiency of client-server communication This can help ensure that commands are delivered promptly and that clients receive updates in a timely manner.
Once you enable persistent connection, it will give BESClient a additional power, which is to check if UDP communication available or not, if not it will check if BESClient directly connected to root or relay, BESClient may not switch to persistent connection (you can validate this by enabling it, I have seen it), if nothing found it will open TCP connection.
I would suggest what Jason already mentioned, issuing the action earlier will avoid the udp notification limitation as the client would kick the action off when the start time arrives.
We usually do that as we also give the endpoints time to pre-cache packages when needed.
We have various types of actions. For most of the individual action fixlets, we schedule them with an action-strat time. Those kinds of actions are not having any problem.
The problem is only for the actions grouped under Plan. This is our custom application, “Planman,” and this custom Planman application should start at the scheduled time. When the application starts, it creates actions and then notifies clients with ForceRefresht to clients to check in back with the server. This is where the issue occurred. The Planman application has logged that ForceRefresh was sent, but the client did not check-in.
Ok so planman is kind of your automation tool to push scheduled jobs in BigFix but Repeatedly sending Force Refresh commands to clients, regardless of conditions, can lead to significant issues over time,
Force Refresh command instructs the BigFix client on endpoints to immediately re-evaluate its relevance, re-send its current status to the BigFix server, and reapply relevant actions. Issuing Force Refresh commands to a large number of clients simultaneously can lead to several problems like network spikes, server overload, client performance impact, interference with normal client operations.
You must coordinate with the administrator of your Planman tool and request that they schedule the actions ahead of the maintenance window, maintaining the start and end times in accordance with the actual deployment window.
I’m not sure what strategy Planman is using, but if they are using XML Push to schedule an action, they must update the fields below before using XML Push.
ForceRefresh is not means of forcing a client to check-in, though; it’s a method to force the client to re-evaluate all Analysis Properties (even if it’s not time to do so yet, based on the property’s “Evaluate every” time, 1 hour, 6 hours, once a day, etc.); and to re-evaluate all Fixlets from every site before posting a new Full Report.
That effort is useful when client reports have been missed, or the system state has changed (adding or removing software, for example) and you need the new values to be reflected in properties. But it’s not a good method for making the client act on new actions, re-evaluating all the other Fixlets can actually delay action processing.
Great explanations. I put it in a simple statement now: What is the procedure to notify the client when an action is created on the BigFix server? So that the client can take action immediately?
if actionCreated {
log.Printf("force a client refresh")
b.ForceComputerRefresh(computer_id)
}
During typical configurations of BigFix, once an action is created on the server, all eligible clients are automatically notified during their regular communication intervals. However, if BESClient is not responding as expected, you must look all possibilities which I highlighted in my initial post to improve the BESClient’s responsiveness.
If not, you can open a case for complete, individualized advice and assistance.
@ravimendu - Notwithstanding the warnings about the side-effects of a Force Refresh, one approach you could take is to create a policy action, use the action script command notify client ForceRefresh, and set a scheduled start of 4:30am, waiting 23 hours before becoming relevant again, so that it runs every day. Policy actions remain active on the end point, and don’t require immediate communication from the console or server.
Why don’t use just enable CommandPolling and set it for 1 day interval? It will ask for new information
When I want to check why new content is not received by the Client -
I create an action for a specific machine (mailbox) - It will create a file on a mailbox folder on the Root Server and then it will propagate to the Relay chain’s mailbox through TCP and then the Parent Relay of the Client will UDP ping the Client to gather a new content - then the file will get to the mailbox folder on the client side.
I had issues that Av exclustion were not configured on the Server , Relays , Clients and also of course Network misconfiguration
I generally recommend command polling be enabled for all endpoints, but generally in the 1 hour to 3 hour interval. A 1 day interval won’t actually help.
That is tricky and would require VERY aggressive command polling, which can have drawbacks, especially if set always. You could technically have a policy action that sets command polling to be more aggressive at like 4am, then switch it back to once an hour after 6 am or something.
This might help, it does use TCP, but there are limits to the number of endpoints that can use it per subnet and per relay.
I think this is not entirely true, as long as the persistent connection is created between a particular client and a particular relay and they are both online and the connection is established, then it should basically assure the message gets there.