Skip to main content

Here's what I am trying to do.

To stay compliant, we have to make sure our Mac's are staying up-to-date. I have EA that checks if there are available updates and places them in a Smart Group if there are. Then I am going to run a script that prompts the user there are updates available. They have 2 options, run updates, or decline. Each time they decline, a read receipt is created and the script uses those receipts to determine how to proceed the next time the script is ran. We have a lot of users that travel so we will allow them to decline 3 times and the 4th prompt will force the update.

My issue is that I need these prompts to happen several times with 10 days. If I could run the policy every 3 days, that would be great, but JAMF doesn't give us that capability.

So I thought, ok, we can make the script smarter and apply logic based off when the read receipt was modified using something like

if [[ $(find "$read" -mtime +2 -print) ]]; then either continue with the script or exit. But -mtime doesn't seem to be accurate. I have a read receipt created on my Mac from Jan 4th and if I run that command it won't find it and today is the 7th. If I change it to +1 it does find it. So, I'm not sure what the deal is.

Any help on the best way to accomplish this would be great!

What about creating a LaunchDaemon that trys to run the policy every 3 days?

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>KeepAlive</key>
        <string>true</string>
        <key>Label</key>
        <string>com.company.updateCheck</string>
        <key>ProgramArguments</key>
        <array>
                <string>jamf</string>
                <string>policy</string>
                <string>-trigger</string>
                <string>*policy_Custom_Trigger*</string>
        </array>
        <key>RunAtLoad</key>
        <true/>
        <key>StartInterval</key>
        <integer>259200</integer>
</dict>
</plist>

A possible solution (admittedly, not the greatest solution) would be to create a policy that has a client side limitation. You could create it so it doesn't run on say, Sunday, Tuesday, Thursday, and Saturday (so it would run on Monday, Wednesday, and Friday). The caveat being that if the machine isn't on on one of those days, you'd have to wait until the following specified day.

I created a Feature Request along the lines of what you're asking but for times per day instead of week, it has gotten no attention, maybe you could add a note for times per week as well!

https://www.jamf.com/jamf-nation/feature-requests/6804/custom-execution-frequency

I setup something custom for Updates to prompt the user every hour (my check in is every half hour). Essentially i set the policy to every check in, and write the time to a text file on the system. The next time the policy runs i check that time and if it hasn't been an hour, the script exits cleanly...if it has been an hour, the script executes. While not very clean, it works for what we were trying to do.

I would create a plist file for the script that contains information like "last run time" and then build the logic based on that. I tend to use "seconds since the epoch" for my timestamps since it's super easy to do integer math that way, and can be pulled with (date "+%s").

So, if you wanted it to run every three days, you'd just make sure the current time is 259200 more than the last run time.

Like what @alexjdale said, use a unix time stamp in the file or some other file if needed, then scoop up the files contents on script run and do some math comparisons to see if it exceeds the time in seconds for 3 days, or however many days you need it run again by. Set the policy to run once per day and it should do what you want.

As an aside, it would be nice if the Jamf framework allowed for a little more flexibility in how often to run. Something between once per day and once per week does seem like it would be useful to have.

In case you want to minimize changes to your script why not use hours in the mtime option to find? That way you should gain flexibility and precision.

@mschroder Good looking out. Didn't even think about this. Using "-mmin +$((60*72))" seems to prove accurate rather than using my previous command. Why? No idea, but this might work!

Terms & ConditionsCookie settingsAccessibility statement