Scheduleing SUS updates with a Policy

I haven't tried what you are doing, but I do have a thought on your setup. I would set the execution frequency to ongoing. You have the activation date/time set to restrict when this will run. WIth once every month set, if the policy fails the first time it runs, it won't try again in 15 minutes - it will try again in a month. If you set it to ongoing, it should run every 15 minutes during your activation date/time, then stop running. I think that would give you better results.

Keep in mind that this is all off the top of my head - I haven't actually tried it.

Good luck!

Are all your machines desktops? Because if you have any laptops, are they going to be on during that time period?

~70% Desktops and ~30% Laptops. I assumed I would not catch all laptops (powered off, closed, sleep etc). I was mainly trying to update the dekstops that are used daily for production.

I work at a research facility that has sicentisits working all hours of the day & night, so its not uncommon to see employees here at 2 AM wrapping up experiments etc. IT sends out an email to remind members to bring in laptops and/or have them awake/available (but who listens to IT, right?).

Im curious to see how many of you use JAMF to manage monthly/quarterly updates such as security patches, OS updates etc

I have a monthly set up as well, around the third week too. Usually week one I do a internal testing, week two is pilot testing, and week three we deploy to users.

The way I have it set up is a I have a policy that is scoped to machines that have a software update available, since I have it configured to use a netsus as a SUS. If a computer has a software update available, then we have a window of two days to deploy the updates to a machine. It tells the machine to use the local Netsus to get the updates from and after it's done to run inventory.

Rinse and repeat each month.

Thanks, @roiegat

Yes indeed, Im very similar to you. I manage my own SUS as well. I do a (very narrow) testing on a groups of IT Macs. I also scope to a Smart Group that has SUS updates pending (i.e.; only Macs that actually have updates waiting are affected).

What Im lost on is how the JSS handles "Pending" updates on scheduled (time-sensitive) Policies (once the schedule has expired, how are Pending Macs treated, etc), and why my Macs got a "reboot?" GUI message.

Mind posting a screenshot of your Policy?

Can't post screenshot due to company policy.

But that is a good question about the pending since the policy would only be active during that time period. So when the computer checks in the next time the policy might be off. Might have to run a test to test it out sometime.

As for the reboot GUI message, check the policy to see the reboot settings. Most of the time I remove reboot completely since I don't want to bother the users. Most of them reboot once a week anyways. So I know it'll get done. If I do need to force them to reboot then I use the User Interaction section to warn them at the start and after the update is done. So should give them plenty of time to save their work and prepare for it.....plus I sometimes let them defer the update depending on the criticiality.

Here is my restart Payload (See screenshot).

The options (if users are logged in) are:

-Do not restart
-Restart
-Restart immediently
-Restart if package or update requires it

What's the difference bewteen "Restart" and "Restart Immediently"???

I have also noticed that Im unable to delete the text string "This computer will restart in X minutes. Please save anything you are working on and log out by choosing Log Out from the bottom of the Apple menu.". The message repopulates as in the JSS as soon as I click "Save".

If the policy is only on for a short period of time and then it goes to Disabled, the machines in the Pending state will never run it, at least while its disabled. The frequency, check-in and other values have no say in running the policy if the JSS knows the policy is off/disabled. You can't override the On/Off state of the policy, even if the Macs fall into the Smart group that should run it.
You're better off using the Client Side Limitations tab and setting the policy to only run during a certain timeframe and on a certain day or days, and keep the Execution Frequency to once every month. But don't have it disable after a few hours. When the next month comes around the policy will still be active and if the Macs it missed the previous round happen to be on during those hours, they'll run the policy.

As for the reboot message, the only way to not have some kind of message is to set all those options to do Do not restart. As soon as you choose any of the restart options, you have to have some kind of message in that field. Restart Immediately appears to be a Self Service option. See this thread for more on that: https://jamfnation.jamfsoftware.com/featureRequest.html?id=34

Thanks @mm2270

To avoid user intervention/notifications, are you suggesting that I remove the "Restart Options" Payload and just run a simple reboot script (or one-liner command via the "Files & Processes" Payload) after the SUS updates are applied?

Would you suggest /usr/local/bin/jamf reboot -immediately, /sbin/shutdown -r now or /sbin/reboot?

Are you suggesting using a combination of Server-Side Limitations and Client-Side Limitation or running ONLY Client-Side Limitations?

Im still not clear on how the Client-Side Limitations tab works exactly (its not described in the JAMF Admin Guide at all). To me, it sounds like when May 1st (which happens to be a Sunday) comes along, Macs that are in the Smart Group Scope will start to fetch SUS updates (This woud be ~3 weeks before the maintenence window arrives and not acceptable.)

I'm mocking-up a revamped Policy now for next month's maintenence window. Screenshot attached.

@dstranathan Sorry for the delayed response. So, you need to be careful about doing an immediate reboot in a scripted way in a policy. Reason is, if the reboot occurs before the policy completes and uploads a log to the JSS, the policy status will remain as Pending for those Macs, which means it may run again at next check-in, assuming its still in scope and the policy is active and all that. The JSS uses the policy log to know that it actually ran since it needs confirmation back from the client. As long as it doesn't see a completed log, it will think it needs to be run on those Macs.

I think some folks here do something like:

/sbin/shutdown -r +2 &

which puts a 2 minute reboot delay and pushes the process to the background (the "&") which allows the policy to complete and upload a log.
You could also use the jamf binary for this as you noted. From the jamf binary help page

jamf help reboot

Usage:   jamf reboot [-minutes <minutes>] [-message <message>] [-background] [-immediately]


     -minutes        The minutes until the machine should reboot

     -message        The message to display to any logged in users

     -background         Background this process (don't wait until the reboot to exit)

     -immediately        Reboot now without warning users

You could do something like this:

/usr/local/bin/jamf reboot -minutes 2 -background

That's essentially equivalent to the shutdown -r +2 & command I posted above. Sets a 2 minute delay and pushes the process to the background, allowing the policy to finish out.

Of course, these are only a few ways to address it. There are probably another 6 ways you can do it that others may post here. But whatever you do, don't run an immediate reboot at the end of the policy without some kind of delay to let the policy finish.

Hope that helps.

What should I do regarding updates if I want to use a Caching Service server rather than SUS or NetSUS?

Is it just a case of needing to create a script that does softwareupdate -a -i on startup or something? Would I need to do anything special to have that running in the background, so it doesn't interrupt users or prevent them from being able to log on and carry on with their work?

Our deployment of Caching Service has been very successful at reducing our internet bandwidth usage as it's already cached 90+GB after only a few weeks of usage, so we'd like to carry on using it.