Execution Tab

The Execution tab can be found in various action dialogs. In this tab you can set the schedule, time interval, and the recovery options that must be satisfied when deploying the action.

Use the settings in this tab to ease the traffic load in your network.


This window displays the Action dialog under which the Execution tab is selected. In this tab you can set the schedule, time interval, and the recovery options that must be satisfied when deploying the action.
This tab is available from several different dialogs:
In the Constraints section of this dialog you can schedule actions and restrict the target computers, in particular:
Starts on [date] [time]
Defines a date and time when the action can first be run. You can choose from Local Client time or Universal time from the pull-down menu. The choice you make here affects all of the scheduling constraints. Note that UTC is only available for version 8.0 or later.
Ends on [date] [time]
It defines the actions expiration date and time.
Run between [time] [time]
Defines a period of time during which the action can be run.
Note: Pending actions are run even if the time period has expired. For example a baseline might start according to the specified time limit and all the actions it contains are run independently from the specified time period during which the actions can be run.
Note: Pending download actions are run even if the time period has expired.
Run only on [Sun,Mon,Tue,Wed,Thu,Fri,Sat]
Defines specific days of the week to run the action.
Run only when [Property] [Operator] [Value]
It filters clients by their retrieved properties. Select a Property and an Operator from the pull-down menus, then select a value for comparison. The value entered must form a valid relevance expression. Note that relational operators like '=' will do a numeric comparision while the others will do a string comparison.
In the Behavior section of this dialog you can manage failed actions and recurrent relevance. The BigFix Client can retry any action that is unsuccessful and reapply any action that succeeds and then subsequently fails. This capability allows you to automatically implement continuing policies minimizing the network load and the operator intervention. You can set the following behaviour:
On failure, retry XX times
It sets the maximum number of retries upon action failure. The default value is 3 retries. After selecting this check box, choose one condition among the following:
Wait XX between attempts
The Client waits a time interval of XX before retrying the action. The default time interval is 1 hour.
Wait until computer has rebooted
The Client waits to reboot before rerunning the action.
Reapply this action
It applies again the action if the target is no more compliant to the policy set by the relevance expression. After selecting this checkbox, choose one condition among the following:
Whenever it becomes relevant again
It reapplies the action as soon as the relevance expression evaluates again to true
While relevant, waiting XX between reapplications
Instead of immediately reapplying the action upon relevance, it specifies a period of time to wait between attempted reapplications.
Limit to XX reapplications
It continues to apply the action the given maximum number of times, while it remains relevant. The default values is 3 times. It counts the number of attempts after the original, so a limit of 3 actually involves 4 attempts.
Start client downloads before constraints are satisfied
The software downloads starts before the Client has satisfied the execution constraints. Select this option if you want to ensure that the download is available for execution as soon as the desired time frame begins.
Stagger action start times over MM minutes to reduce network load
It forces the program to space out the running of actions. This option can reduce the load on the network, in the case of bandwidth-intensive actions, and is useful to help relays in effectively servicing hundreds of attached Clients.
Note: This option can have an additional delay for starting the action and it can exceed the configured delay time, if the client selects a different relay while waiting for the action execution.