Reoccurring Policy

[mconners]

Hello,

I am not sure if this is possible, but I am trying to find a way for something to occur on a regular basis. I know we can have a trigger as monthly, weekly and so forth for policies. I would like to take it a step further.

If I package up an app or plugin that changes frequently, I would like have a set of computers to get the policy every month on the first Monday. This way I only worry about packaging up the change and push it into the JSS and it will push out the first Monday of every month, automatically. I would then scope it to a set of computers that DON'T have the update applied.

Is anyone doing something like this? A reoccurring policy where it is set to go on a specific day of every month? Just curious how others are handling updates like this.

Thanks!

Mick

[mm2270]

I'm not sure if there's a way to be quite that specific with the built in policy options. However, you could try the following

Server-Side Limitations, Activation Date/Time: (Set to the first Monday of the coming month, in the AM) Execution Frequency: Once every month Client Side Limitations, Do Not Run On: Sun, Tue, Wed, Thu Fri, Sat (leaving only Monday unchecked)

Once it activates on that Monday, its being directed to only run once a month, on Monday, so it technically should only happen on Mondays of each month.
The only problem is that I'm not sure what the JSS actually considers a "month" Is it 30 days, or does it actually go by the calendar, as once in Jan, once in Feb, once in March, etc etc? With some months being short and some long, over time, if its using 30 days as a month, you'll start getting policy executions happening at the end of a month instead of the beginning.

The other way to do it would be with a LaunchDaemon using a StartCalendarInterval that just calls the policy by its ID or a custom trigger.

[mconners]

Thank you, I never thought of looking into those options.

I was talking with a colleague about this and the idea we have is to deploy all critical updates on the first Monday of every month to a group of IT computers for testing. If all goes well with that push, then we push the updates to the remaining Macs in the infrastructure. If the limitations stuff works, then we will be golden.

I'm going to test this out, thanks!

[mm2270]

Sure, hopefully the JSS actually sees a month as a switch from one month to another, like May to June, and not just using a set number of days. I can see already how it can get quickly out of sync using our current calendar.
For ex, first Monday of June is 6/1. 30 days out, you land on exactly 7/1, but that is a Wednesday so they policy would wait to run until 7/6, which would be fine (first Monday of July), but another 30 days would be 8/5, so again it won't run, but it should run on 8/3, which is the first Monday of August, assuming its using actual calendar months as the timeframe it waits. If it doesn't do that and instead runs again on August 10th, things will start shifting away quickly from the first Monday of every month.

I'm hopeful it actually uses a real calendar month though and not a set # of days. Post back with results, as I'm very curious to hear how it actually works.

[mconners]

I have one set to go next week to test it out. This might be a nice feature bump? Rather than simply monthly triggers, we can tell it to trigger on the first Monday of every month or similar. Thanks for the suggestion.

[lwindram]

While you are waiting on the feature bump, you could also try a LaunchDaemon that is set to run once a month and runs a

jamf policy -trigger xxxxx

command. Deploy the LaunchDaemon to the test population, then build all of the test policies to trigger using the xxxxx custom trigger and they will all run on a predictable schedule.

Alternately you could write the LaunchDaemon to run daily, and you could enable the test policies in the JSS on the monthly basis. This would provide for better handling of policies that fail to deploy.

[mconners]

Well I can say the policy triggered this morning at midnight and is still pushing out as expected. I guess the next phase in testing is to stop the policy after 30 days so we don't overlap into next month's push and add new groups to it starting for next week. The only thing I wished it would do would be automated more.

For instance, I have it configured to only run on Wednesday and live after June 1. This means in July, I have to create a new policy for the policy to trigger after July 1. If we could only have it set to run after the first of every month and only on Wednesday, that would be ideal. Then it would be only a matter of creating a new package for deployment.

[alexjdale]

You don't need to create a new policy, just change the dates and update the package each month. Have it run once a month starting on the first, limit it to Wednesday, have it deactivate after that Wednesday is passed.

You will have to do a little work each month, and as it stands, it's really not much work at all.