(imported topic written by ltd200991)
Ok, I’m hoping there is a simple way to do this… Nothing I seem to be trying is working…
Does anyone have any relevance for creating a patch window on systems that would only allow them to execute actions between a certain time?
Here is the scenerio:
We have systems that are “locked” and I need to “unlock” them between 2:00 and 5:00 AM.
thanks!
(imported comment written by ltd200991)
another question kind of related to this…
looking for the relevance “current time is between 2:00 and 5:00 AM” if i can add that to the relevance of baselines that would guarantee that systems only become relevant during that time…
(imported comment written by NoahSalzman)
Do you want your window tied to the Server’s time or to each machine’s local time? I’m assuming you have machines across multiple time zones.
(imported comment written by JackCoates91)
Have you already tried this? http://forum.bigfix.com/viewtopic.php?id=662
(imported comment written by ltd200991)
hi Noah, would definitley be each machines local time… you are correct we have systems across multiple time zones…
JackCoates, thanks … I reviewed that, I think I’m more interested in the relevance at this point to make it so that systems only become relevant between a certain time…
(imported comment written by SY57_Jim_Montgomery)
Hrm, based on the other thread (which is a couple years old) it seems as though regardless of which way you do it (by relevance, or with scheduled unlocks), the client may miss the window entirely if they are processing a large amount of actions/fixlets.
So, if you send out an action and the client says he’s not relevant because the time isn’t right, then he will continue on his processing loop until he gets back to the action and tests it again… At which point it might be after the execution window. Is that still accurate for the 7.2 client?
If you have a locked machine and send him an action, he’s not going to run the action portion. When he unlocks at his scheduled time (will that time be accurate even??) he still isn’t going to check the other action till he gets through his loop again.
I think a bigger question is exactly how does the (7.2) client order and prioritize actions, fixlets, tasks, baselines, group membership, etc. when doing his regular processing. Is there someway we can trick a machine into running a task at a certain time? Especially when we have a locked client (like all my servers for example) and I want to patch them all quickly in a very short maintenance window. Guidance on this?
–Jimbot
(imported comment written by ltd200991)
in regards to using relevance to check if the time is between a window I found this older info from Ben on the forum…
Q: (item 2 of it >= item 0 of it AND item 2 of it <= item 1 of it) of (item 0 of it as time_of_day, item 1 of it as time_of_day, (first 8 of (current time_of_day as string) as time_of_day)) of (“01:00:00” , “03:30:00”)
I’ve changed that to
Q: (item 2 of it >= item 0 of it AND item 2 of it <= item 1 of it) of (item 0 of it as time_of_day, item 1 of it as time_of_day, (first 8 of (current time_of_day as string) as time_of_day)) of (“02:00:00” , “05:00:00”)
But in my testing on a baseline with that as the relevance, even when changing the local time on the endpoint to 2:40 am it still says “not relevant”.
(imported comment written by JackCoates91)
ltd2009, I think this will work for you (untested):
q: (first 2 of (substring separated by " " whose (it contains ":") of (now as string))) >= "02"
q: (first 2 of (substring separated by " " whose (it contains ":") of (now as string))) < "
It’s done as two separate queries to make it clearer, but they could be ANDed.
Jimbot, it’s possible, but I think it shouldn’t happen unless something’s gone wrong. Evaluation loops can be kept reasonable by doing three things:
don’t subscribe to content on an agent that doesn’t need it
don’t make baselines with > 250 fixlets
be aware of the cpu throttling settings (e.g. if you set it to 0.04 and violate guidelines 1 and 2, Bad Things™ will ensue)
(imported comment written by ltd200991)
thanks!!