Executing a software update policy bi-monthly?

[cghigliotty]

HI all,

I wanted to set up a fleet-wide software update policy that runs twice a month; currently, the default execution frequency that seems the most applicable is once per month. This is probably fine but it would be handy to run it twice a month, in particular during the summer when people are traveling (or when execs are on the road for long periods of time).

Does anyone else have experience running software update policies on a "non-standard" cadence?

[mm2270]

You may have to create something custom, since I don't think the JSS has any default settings you can choose to do that. Its once per day, once per week, once per month, etc, though of course you can specify the days it shouldn't run, but that won't help in this case.

How I might approach it is with a dual policy set up and some scripting.

If, for example, I always wanted this policy to run on a Friday, every 2 weeks. I would first set up the policy to run every week on Friday's only, excluding other days.
Then I would have the policy first check for a local file written on each successful policy run. This would just have the last date it ran in it, perhaps in simple Unix time format.
Each time the policy runs, once a week, it first checks for that local file. If it sees it, it checks the value in the file and compares it to the current date. Since the difference between the current unix time and the time in the file should be more than 7 days and less than say, 15, you can do some simple math to determine if it should continue. If its been over a week and within 2 weeks since the last run, it calls the actual Software Update policy by a custom policy trigger or by its ID. So, first policy checks to see if it should be run, second policy does the actual updates.
If on the other hand, it sees the time difference is within 7 days, it means it ran last week and should exit without trying to run again until the following week.

To make this work, each time it runs and sees it needs to do the updates it should first write in the new current date into the local file, meaning before it installs all the updates and reboots, since it may not get the chance after the completion of the policy. That way when it runs again in a week it will see that it already ran last week and exit silently.

Does that make sense?

[cghigliotty]

Sorry for the late response @mm2270. That does make sense. Thank you for the suggestion!

[Look]

Create a date extension attribute based on a modified file when the policy is run as @mm2270 suggested.
Create a daily policy scoped to a smart group for more than 13 days ago based on that extension attribute.
Include an inventory update (if your worried about it running more than once and you have infrequent inventory) so the machine moves out of the group once it is completed.