IBM Support

Preventing Send Refresh abuse in a large deployment



How to prevent a console operator from abusing the right click Send Refresh functionality in a large deployment and negatively impacting deployment reporting performance.

Resolving The Problem

By default, operators have the ability to select thousands of computers in the console, right click on them, and then choose Send Refresh. The Send Refresh command, when received and processed by the client, will then cause the client to generate a full report of all of its relevancies and properties. This full report is substantially larger in size than the typical reports sent up by the client in the course of normal operation. When aggregated together on the relays and server, tens of thousands of small reports usually aggregate down into thousands of reporting files around a megabyte in size. The FillDB service and database often do not have the capacity and resources in keeping up with processing these many large report files and as a result the deployment's reporting functionality becomes backlogged. As a result, computers will start to turn grey in the console as their last report times exceed the default setting of 45 minutes. Actions and properties will also appear as <not reported> for extended periods of time until reports from their results have been processed and put into the database.

You can determine which operator or operators have issued large amounts of Send Refresh commands by looking in the server_audit.log in the BigFix Server directory on the main BigFix server machine. And entry (or entries) similar to the following will indicate the operator who issued a Send Refresh to a large number of computers:

Sun, 06 Dec 2015 20:54:30 -0800 -- user "bigfixadmin" (1) sent a refresh to 5,698 computers.

To prevent non-master console operators from abusing this feature; in the console, set their "Can Send Refresh to Multiple Computers" to "No":

Make this setting change for all non-master console operators.

Note: There is not a feature that will allow you to set this for all non-master console operators all at once.

For master console operators you will need to educate them to only issue Send Refresh commands for a few computers at a time as this setting is not adjustable for master console operators.


Alternatively, you could also set the following client setting on your endpoints deployment wide to disable the endpoint's response to Refresh commands:


Set this setting to 1 to enable it and have the client ignore requests for Refresh commands and set this to 0 to disable it and allow clients to process Refresh commands.

Warning: Setting the _BESClient_Comm_IgnoreForceRefresh setting to 1 on the endpoints will also prevent clients from sending up full reports when requested by the BigFix server. If some of your clients continue to experience issues in which they have <not reported> for several of their properties when checking back into the console recently after having been removed from the database (via the Computer Remover tool); this setting may inhibit them from correcting this condition by sending up a full report of all of the computer's property data.

For more information on how to set client settings, please see the following article: How do I set BigFix Client configuration settings?

After enabling this setting; if you still want to grant some or all of your operators the ability to send a Refresh to endpoints they manage; they can do this through an action using the following actionscript code:

The following actionscript code could then be used to turn off the Ignore Force Refresh setting, execute a force refresh command, and then turn the Ignore Force Refresh setting back on:

    parameter "startTime"="{now}"

    setting "_BESClient_Comm_IgnoreForceRefresh"="0" on "{parameter "action issue date" of action}" for client

    notify client forcerefresh

    pause while { (now-time(parameter "startTime") < 180*second) }

    setting "_BESClient_Comm_IgnoreForceRefresh"="1" on "{parameter "action issue date" of action}" for client

They will need to be instructed NOT to take this action on a large number of endpoints (as the issue may occur via an action as well if not targeted to a limited number of endpoints). You may want to advise them to limit this action to only one endpoint at a time; as the purpose of a Refresh command is often associated to the need for troubleshooting whether an endpoint online and is properly sending up all of its reporting data or not.

The added benefit to you the BigFix administrator of forcing them to do this through an action is for auditing purposes. It will be easier to track down which operator (either via client logs, console view, or database look up) took an action to force a refresh on endpoints.

Related Video:

Internal Use Only

This technote was generated by Technote Kickstart based off of Tivoli Customer Support PMR 49526,442,000.
View the associated PMR's text via Wellspring at:

[{"Product":{"code":"SSQL82","label":"IBM BigFix Platform"},"Business Unit":{"code":"BU008","label":"Security"},"Component":"Deployment","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"Version Independent","Edition":""}]

Document Information

Modified date:
29 September 2018