Hello
what is the difference between this two reporting method ?
Send Refresh (triggered by console)
periodic client heartbeat (set by console preferences)
does the same content send to server for both of them ?
Hi,
A heartbeat is a client message indicating that the client is still online – they will update their “Last Report Time” property along with any other properties that have changed since the last heartbeat.
A heartbeat is sent on a schedule based on the console preferences as you identified. A heartbeat is Client -> Server
Using, “Send Refresh” sends a UDP packet from Server -> Client informing the client that it should immediately generate a report and provide it to the server.
2 Likes
one of them is periodic and the other is anytime we want.
what about contents ? are they same exactly ?
for example, does client synchronize its sites with server when it receives “send refresh” ?
A client will only synchronize its sites during a gather.
Gather occurs:
- Once per day
- During Command Polling
- When a UDP Ping is received (from an operator making a change in the console)
- When an operator presses Send Refresh.
A heartbeat does not cause a client to synchronize its sites
More info about how this process happens on the network is available here: https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Endpoint%20Manager/page/Network%20Traffic%20Guide
3 Likes
Send Refresh sends a UDP message to the client telling it to gather all operator sites, reset all periodic evaluation and report on EVERYTHING it knows about. This is rather intensive to the system and will use up resources.
The heartbeat says to report this often even if nothing has changed on the endpoint, as the endpoint will only report on things that change. Note that the endpoint must get through the content loop to consider this heartbeat value at the moment.
6 Likes
I wrote up an FAQ on Send Refresh, please see:
There are concepts related to Send Refresh in this article which may also serve you and be useful:
And please note, problems which may occur if Send Refresh is abused by way of asking to many clients all at once to send up a full report (via Send Refresh requests):
3 Likes
I’ll work on writing something up on how heartbeat interval works (according to what I know) 
What is the problem you are trying to solve?
You can also trigger a full refresh on a client through an action, using Notify Client ForceRefresh but you also have to be careful with that and not do it against many clients at once as it is intensive both for the clients, but also for the server to ingest many full reports.
You generally shouldn’t need to do this if command polling is enabled and changes are made to a property… that change will propagate to all online clients within double the command polling interval, and usually significantly faster.
I generally recommend command polling for all clients in the 3 to 6 hour time frame, and as frequent as once an hour for laptops / devices that roam.
Related
2 Likes
we have a bigfix environment that has 2000 internet clients.
because udp ping is not possible, we enabled polling.
(hearbet in every 10 minute and polling in every 10 minute)
when I check the computers on console, some of computers are updating their last report time but not their action results or their other properties ?
I consider to create a policy action contains “Notify Client ForceRefresh”.
does only such a policy cover both of “client’s heartbeat” and “polling” ?
1 Like
A command polling interval of 10 minutes is WAY TOO FAST. The command polling that often will interrupt property evaluation and cause the clients to NEVER finish evaluating. You should switch command polling to once an hour or less often and that should fix the issue.
(once every 30 minutes is probably fine in most cases, but not needed for most clients)
3 Likes
Command polling controls the frequency at which the client gathers content from the parent relays/server
Heartbeat controls the frequency at which a heartbeat report reports
These are two separate and distinct operations and serve two different and separate purposes.
The heartbeat by default is set to 15 minutes in the console preferences. 15 minutes should be adequate as long as the “Mark as offline after” is set to around 3 times the heartbeat value (default: 45 minutes).
The real purpose of the heartbeat interval is to give you visibility as to whether the client is still online by making it appear online in the console (black) versus offline (grey) during times of low deployment activity. During times of high deployment activity the heartbeat report is not really that meaningful because all the activity in the deployment causes the client to report up more often.
The Last Report time value in the console for a computer shows the last time a computer received a report from the client endpoint and determines if the computer should appear as “online” or not based on the “Mark as offline after” value in console preferences.
2 Likes
@jgstew The following article states at the bottom not to set command polling interval lower than 10 minutes. So BigFix has traditionally run on the assumption (and probably at one point in time some field data years ago) that the floor value of this setting should be no lower than 10 minutes. This may be an area where specific deployment scenarios, results, or opinions may vary. Wondering what sort of behavior you may have observed in any of your deployments using a lower value and if you have ever set this command polling interval to something around 10 or 15 minutes and if any sort of bad behaviors were observed because of a lower interval:
1 Like
I don’t think this is quite right. Command polling just means that the client checks if there is anything for it to do from it’s relay, which includes gathering. It doesn’t gather if there is nothing to gather.
1 Like
I think this can happen if your relays or root are overloaded and drop reports frequently. Sending ForceRefresh would cause the clients to update all properties, but would also cause more load on relays / root.
Command polling at every 10 minutes would also provide more load on the relays.
If this is happening frequently, then that should mean that there is something going wrong at some point in the chain. It could be clients getting interrupted and not finishing evaluation loops, or relay issues. Investigating the client logs on some of the devices with the issues would be a good idea, as well as looking into expensive relevance queries and the evaluation loop.
1 Like
Right, it checks to see if something is there to gather
thanks for comments.
I changed polling interval to 30 minutes.
I obverse it for some time.
can we say ?
forcerefresh (gathers and reports) = polling (gathers updates) + heartbeat (reports changes)
Force refresh is much more intensive on the clients/relays/servers than polling or heartbeats are. Alan says it best here:
You can think of polling and heartbeats as deltas (difference between the last poll or heartbeat) but a full refresh is a full refresh (report all data).
4 Likes