I wanted to schedule an action to run every 2 weeks on a Saturday.
I selected Saturday and then went to the “reapply this action” checkbox and saw that 14 days was not available to me - only 15 days.
So it looks to me like I can’t schedule an action to run every 2 weeks on a certain day.
If I were to choose “reapply after” 15 days and wanted this action to run only on Saturday, would that mean that my action would actually wait another extra week, since the 15th day would be a Sunday?
You can set it to only apply on Saturdays and set it to reapply every 10 days. This will cause it to run every other saturday because after 10 days it will go to reapply, but it will wait for the saturday constraint.
I am also wondering why you have such a specific constraint?
The use case is that my client wants to run the IBM License Metric Tool task “Initiate Software Scan” every 2 weeks instead of the default of every week. The IBM software to be found by this task changes very little. He has 7,000 clients and wants to stagger this task over a two week period, with some groups running on Monday, the next on Tuesday, etc, every 2 weeks.
@jgstew, there is no 10 day option for reapplying a task. The available days are 1, 2, 3, 5, 7, 15 and 30.
Do they anticipate having a much larger number of clients?
They estimate 2,000 - 3,000 more clients over two years in just this region.
What version of ILMT are they using?
ILMT V9.2.1, the current release
Are they primarily worried about the impact on the client,
or are they worried about the length of the ETL process in ILMT?
I think their concern is that running this task on too many computers at once might cause CPU issues. (I have already told them that this task is lightweight, runs quickly and CPU can be governed if necessary (which I don’t think it is) but this is what they want to do.) They did not express concern over the ILMT Import (the ETL process).
I think this might be an overly complicated solution to the problem.
If it’s required, you could potentially tie the relevance of the task itself using additional relevance to the age of a file that is generated each time the task runs? Seems like this is a complicated solution but, as stated, the request is complicated so here we go…
Append a small file creation with a specific name at the end of the Action Script for the task and save it to a space it won’t be accidentally removed:
if {exists file “C:\Windows\Temp\scan.txt”}
delete "C:\Windows\Temp\scan.txt"
endif
appendfile File created
copy __appendfile C:\Windows\Temp\scan.txt
Add something like this to the relevance of the task itself:
not exists file “C:\Windows\Temp\scan.txt” OR now - modification time of file “C:\Windows\Temp\scan.txt” > 13*day
Schedule your task to run every day of the week as necessary.
There should be a way to write a set of relevance to cause the action to only reapply after ?? days. I’m not certain the best way to do this without digging deeper.
The other option is to use the age of a file like @jmaple just recommended, which may be the better option.
You can actually tie each computer to a randomly assigned day of the week by using the computer ID.
If you add the following relevance, then each computer will only run it on a particular day of the week:
exists (it) whose(it = (it as string) of current day_of_week ) of tuple string items (computer id mod 7) of "Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday"
Then if you use something like @jmaple recommended, then it will only run it if it hasn’t run it for the past 10 days:
not exists files "C:\Windows\Temp\scan.txt" whose( (now - modification time of it) > 10*day )
But instead of using the file "C:\Windows\Temp\scan.txt" you could use one already being written to by the ILMT scanner, particularly if it is already using a log file somewhere.
Also, you could add all of this relevance to a baseline, then add the ILMT scanner task to the baseline. This would allow you to add these constraints to the scanner without the need to modify the scanner task as provided by IBM.
Then just run the baseline and it will automatically cause all computers to run it every 2 weeks on a particular day in a randomized distribution.
You would set this to reapply every 7 days. The log file constraint would prevent it from running every 7 days and it would instead run every 14 days.
I have been exploring this same dilemma with wanting to reboot machines on a specific day every 2 weeks. My only concern with the file is it being removed or something happening to it. I have been exploring a different option and wanted to reach out to the forum regarding my logic.
Initially we are concerned about machines not rebooting for a period of time. The 15 day under reapply action is not an option and 7 day is really too short. I really like the idea of adding relevance in the mix so wonder if we add…
(now - boot time of operating system) >8*day
and set the reapply to 7 days.
and runs on a specific day, for instance Thursday
So if I’m thinking this through correctly, when the first occurrence runs on a Thursday, the task executes and reboots the machine. The following Thursday the 7 day wait period has been met but it will not run because in the relevance the 8 days since last reboot has not been satisfied.
When the 8 days in the relevance has been satisfied it should wait to the next Thursday giving me 2 weeks for reboots.
I do understand if machines are rebooted less than 8 days then those machines will not be relevant, but that should be ok, because that means they are getting rebooted on a regular basis.
I think with this method there is no file to maintain or worry about.
With the exception of enterprise schedulers, like TWS or ControlM, and even then, you will find yourself in a “customization” moment where the features fall short of your requirement.
I would create task to create a trigger file based on your date requirements. Add this as the first task in your baseline and make sure in the “Execution” tab you deselect the “Run all member actions of action group regardless of errors”. Add tasks and fixlets to this baseline and you should be good to go.
You could also use the “Pre-Execution Action Script” function for similar results.
Forgot to add is if you take this route please consider maintenance windows and/or times you would not like to run an action or actions. Maybe have your action look for a file called reboot.txt and one that is noreboot.txt
If the action sees noreboot.txt then the baseline, and/or actions, should not run. Of course if you forget to remove the noreboot.txt this will be an issue and hopefully caught in a timely manner. Need to have good functions in place to let you know when BigFix is not running and when critical tasks have failed to run. Preferably an automatic notification app or scripting to send email and/or electronic alerts.
Caution - the 2nd Thursday is sometimes before the 2nd Tuesday.
Patch Tuesday can fall anywhere from the 8th to the 14th of the month.
The following Thursday will be from 10th to 16th. So:
q: current date
A: Fri, 05 Nov 2021
T: 0.234 ms
I: singular date
q: day_of_week of current date
A: Friday
T: 0.205 ms
I: singular day of week
q: day_of_month of current date
A: 5
T: 0.169 ms
I: singular day of month
/* the real test
q: (day_of_week of it = Thursday and (it > 9 and it < 17) of (day_of_Month of it as integer)) of current date
A: False
T: 0.132 ms
I: singular boolean
/* day & date range tweaked to test on today's date
q: (day_of_week of it = Friday and (it > 4 and it < 7) of (day_of_Month of it as integer)) of current date
A: True
T: 0.062 ms
I: singular boolean
That’s great relevance, I never thought of it that way.
I always considered “the second Thursday of the month is always 9 days after the first Tuesday of the month”
Q: first Tuesday of current month_and_year + 9 * day
A: Thu, 11 Nov 2021
Q: current date = first Tuesday of current month_and_year + 9 * day
A: False
T: 940
(today is not 9 days after the first Tuesday - today is 2 days after the first Tuesday.
Q: current date = first Tuesday of current month_and_year + 2 * day
A: True
Fully agree, and I have session relevance that reports on windows patch progress based off ‘first Tuesday of current month_and_year’, but I coded the above to connect with and amplify my comment that the 2nd Thursday doesn’t necessarily follow the 2nd Tuesday (having had to do so a couple of times in conversation recently)
