When a relevance becomes relevant (in time)?

Content Authoring
1

Hello Everyone, I was wondering if someone can help me.

My secondary goal: to make a fixlet relevant if all the below is true
A server belongs to a manually created group
A server is in a pending start
An specific time and day of the week has been reach.

Also in my environment of 900 servers.
_BESClient_Comm_CommandPollEnable is 1 for all the servers
_BESClient_Comm_CommandPollIntervalSeconds is 3600 for all servers
ALL servers are unattended.

my relevance is:

version of client >= "6.0.0.0") AND ((exists true whose (if true then (exists setting "__Group_0_LM_Static_Windows_Group" whose (value of it is "True") of client) else false)) AND (exists true whose (if true then (pending restart) else false)) AND (exists true whose (if true then (current day_of_week as string equals "Wednesday" AND time of current time_of_day > time_of_day "14:10:00") else false)))

Scenario:
If I change the date to todays and the time of day to something like 20 (12:10 AM) minutes back in time…the relevance reads true “after a while” and 6 servers become relevant.

Now if I change the date to todays and the time of day to something like 20 (12:30 AM) minutes AHEAD in time, the relevance reads true not after the 20 minutes, or 30 minutes or 40 minutes but much, much later on…the latest at 13:28

Questions:
A. Is there any way I can control that the fixlet becomes relevant as close to 11:40 as possible via Command poll intervals?

Is my relevance wrong somehow?

Is my logic not the correct one to achieve the MAIN automation goal of REBOOTING UNATTENDED servers in an specific date and time in the future?

P.S as per my investigations, you can not schedule a reboot directly after an action as long as the server is unattended.

I appreciate any pointers.

2

Is there a reason you can’t simply omit the time criteria from the Fixlet and instead use the Execution tab of the Action (Run between XX and YY time and Run only on Wed)? That’s more or less what we’re doing in our environment.

1 Like
3

Hello Josh, thanks for the quick response. two things:
A. We want to use this as an automation, hence no operator will be present.
b. When using in conjunction with a baseline, the restart happens immediately as the servers are unattended.

Now, when you do it, you just create the action and leave it open and pick up the group even if the group is empyt?

Thanks

4

I don’t know your exact use case, but yes, you can use the Fixlet relevance for pending restart (there are actual external site Fixlets for this in BES Support - 177, 390, 391), then take action on it (targeting your manual group), and set the schedule in the action (keeping it open-ended). As long as you set your reapply behavior appropriately, this action should be able to perform all your reboots for you (unattended).

2 Likes
5

hello Josh, thank you, I will try your scenario and let you know.

6

Joseph, following your advise and using different scenarios, by creating the fixlet in that way, I was able take out the relevance time refresh issue.

thanks a lot for your help.

1 Like
7

So part of the issue here is how long it takes the servers to get the content update, how long it takes for them to go through an eval loop, report back that state, then have that state reflected in the console. In some cases the whole thing could take 60 seconds, in other cases it could be much longer.

This delay does not apply to a policy action. Once a client knows about a policy action from the server, it will process that action over and over again without first communicating with the server and the delay will be very short, typically the length of the evaluation loop at most. This will continue until the policy action is stopped or expired. There can be a bit of a delay before a client gets a new policy action for the first time, and there can be a bit of a delay before a client gets updated with the fact that a policy action has stopped, but otherwise the client works on its own. If you turn off your root server today and never turn it back on, then all of your policy actions would continue to run and work forever as long as they didn’t require downloads from the root server that were not already cached.

If you have an action that you only want to run once, but at a particular time, it is best to set it’s start time correctly, but issue the action far enough in advance to ensure all clients are aware of it before the start time.

NOTE: a “policy action” is just an action that is set to reapply indefinitely without expiration. This is common for an action that would enforce security policy, like for instance requiring a computer’s screen lock after 30 minutes, but could be anything, including scheduled reboots.

One trick with policy actions, is that generally they should be targeted at a group dynamically, not targeted at specific computers. Even if the group is currently empty at the moment, once a machine determines that it belongs in that group, it will process actions targeted to that group. This will likely happen before the console even reflects that the computer is now in that group, which is generally delayed slightly.

The Console provides you a view into the known state of the system, but that known state is really lagging behind the live state by a slight degree. If everything is working correctly, that lag should be between 30 seconds and ~10 minutes. The worst case scenario is clients that cannot get UDP notifications from their parent relay, have no command polling configured, and have long evaluation loops due to too much or problematic relevance. Even in those cases, the maximum time should be ~6 hours, but with minor configuration changes, generally the worst case is ~1 hour.

4 Likes