I was trying to do a fixlet that will check if a newly installed BES agent has a certain client setting or not. If the setting is not existing it will add the computer setting. I was trying to figure out what will the action script would look like so I first tried out via the “Edit Computer Setting” action.
The action script using the “Edit Computer Setting” on the console will look like below:
setting "_BES_Resource_InterruptSeconds"="600" on "Thu, 15 Dec 2016 20:09:13 +0000" for client
I noticed that there is also an effective date included and I was wondering if the effective date is necessary for the adding of the action script. I was planning on running the fixlet as a policy so I am not sure what value I can set the effective date to. Can I have it removed or just set it to any value?
The “effective date” for settings commands controls how an Endpoint Manager client handles settings actions. An Endpoint Manager client will only set a settings value if the effective date is newer than the existing effective date. The effective date mechanism prevents older settings from overwriting newer settings (or you can specify dates manually to control the settings override behavior)
When there are several different Actions to take on a client, you are not guaranteed that they will execute in order. For that reason you can get unintended results when you set the effective date to {now}. In general what you’d probably want is to use on {parameter "action issue date" of action}. This evaluates to the date/time the action was issued by the console operator.
Example:
On 12/10, you take “action 1” targetting a group of computers with setting "myvalue"="1" on "{now}" for client
On 12/11, you decide that’s a bad value, so we take “action 2” setting "myvalue"="2" on "{now}" for client
On 12/12, you install a new computer in the group and it tries to catch up with the open actions. But they don’t execute in order - action 2 runs first, then action 1 runs after. You end up with the incorrect value of “1”.
There are several ways to handle it - you could ensure your older actions are stopped, for example. But the easiest way, and the method used in the fixlets in the BES Support site, is to use the action issue date. In that same example, you could have used setting "myvalue"="1" on "{parameter "action issue date" of action}" for client
and setting "myvalue"="2" on "{parameter "action issue date" of action}" for client
…in that case, when action 2 executes first, it resolves as setting "myvalue"="2" on "Mon, 12/12/2016 10:05:32 -0500" for client
…and the setting gets a value of “2”. Then, when action 1 runs, it evaluates as setting "myvalue"="1" on "Sun, 12/11/2016 17:05:02 -0500" for client
Since “myvalue” already has an effective date later than what was specified in action 1, the value is not changed again and remains set to “2”
I believe this is true for most use cases but I think it has unintended results when you are looking to enforce the setting as a policy.
It’s my understanding that parameter "action issue date" of action essentially eliminates your ability to enforce the setting as a policy, any future changes to the setting will not be reverted back by the policy action and as a result, the policy action will continuously reapply failing to apply the setting value.
Agreed, policy actions require more consideration. I use {now} in several instances for those as well. But one does need to take care when using {now}
For instance I use a policy action to close my patch window client setting, checking that the age of the window “opening” was at least two hours earlier than {now}
But seems you covered the bases already. I strongly recommend that you use the {parameter “action issue date” of action} method always to prevent any out of order settings.
One thing I will note is that settings set with a clientsettings.cfg file at client install time tend to not have effective dates, but they still are applied and effective. Ones set with ActionScript must have an effective date.
That is correct, it is assumed that any setting entered like this is valid but has the “lowest possible” date for the OS in question so any date will be “after” this.
