Apple Software Updates - Is this possible with Jamf?

[scottlep]

I am a fairly new Jamf guy, recently coming from a full Munki environment for over 7 years. With Munki you could configure (on 10.9.x and above) to automatically install without user interaction any pending Apple Software Updates that did not require a restart, similar to how the OS could do ASUs if configured accordingly. This was known as UnattendedAppleUpdates in Munki. If ASUs required a restart then the user would be notified via Managed Software Center (Munki's equivalent of Self Service). In this scenerio Apple Software Update would be totally disabled in System Preferences and Munki would handle all ASU responsibilities.

It is possible to do the same with Jamf and Self Service? I am a big fan of automating as much as possible and having the least user interaction....especially when it comes to geting updates installed on a timely basis.

Thanks!
Scott

[Sandy]

This is pretty simple! In Computers, Create a new policy.
In the general Tab, decide how you want this policy triggered. (I must use Self Service, but you can automate it too)
In the left column there's also a tab for Software Updates.
You should also look at the restart options, and if you want to update the device record, that's in the Maintenance tab

You can also scope the policy only to devices that have pending updates, which you can gather by clicking the box in Computer Inventory Collection.
Create a smart group with available updates that are more than 0

In your scenario you could use the smart group to trigger a policy to alert the user to restart

[scottlep]

I tried that. I don't think that method is really doing the same thing. With Munki the updates that could be installed without a restart would just be automatically installed in the background when Munki ran at it's normal interval, similar to the way ASU would do it if configured accordingly in System Prefs. Then if there was an update that required a restart it would only show that pending update in Munki's Managed Software Center. Via a metadata plist we could then put a deadline on that pending update if necessary.

With your method above isn't it just running software update then warning the user of a restart with no options to delay, or if using Self Service just running the policy when the users runs it in Self Service which then does the software update check and just installs any pending updates whether they could be automatically installed or not? So at that point if there isn't a deferral deadline configured then none of the updates will be installed if the user ignores it?

[Nix4Life]

@scottlep Welcome!!! I live in both worlds JAMF/Munki. if you know of Munki then you must have heard of Reposado. JAMF has their own vm version, but you could roll your own on baremetal,docker or vm. then update the settings in the JSS as mentioned. Might also want to look at Repotoddy to automate rolling out your updates. Also do a quick search as there are ways to let users delay or postpone updates a number of times before they must install them

Cheers

[gachowski]

You can sort of do it.. you can add the option to defer, but it's only a date in the future (it's under User Interaction tab). This limit forces you to have have change the defer date and flush the policy every-time Apple release a update that requires a reboot.

There are a few FR for a time delay like this that we will get in the future.

https://www.jamf.com/jamf-nation/feature-requests/1418/deferral-limit-as-net-days-or-n-times

Most security groups require that security update are installed in X days and most Apple updates that require a reboot are security updates, so you can kinda fake it with setting the "execution frequency" and "client side limitations" to match what you security rules are.

C

[scottlep]

Thanks for everyone's input.

Coming from 7+ years the Munki world, I am just finding Jamf's patch management and Apple Software Update capabilities kind of weak. But on the other side, there are many things that Jamf does way better than Munki including MDM which is nonexistent in Munki. I am taking the CCT course in a few weeks, so maybe that class will address some of my questions and misunderstandings. Working for a MSP provides it own challenges since we are limited as far as forcing updates and creating the policies to force updates, etc. We can make all the recommendations in the world, but the final say comes from the clients. I also inherited a mess with my new job with 20+ neglected client JSSs and MSP clients that are very far behind with critical updates. Being able to do the updates that do not require a reboot in the background without user interaction would be a huge help, but it seems like the way Jamf is handling the ASUs is more of an all or nothing approach since when ASU is triggered nothing can happen until the computer is forcefully restarted or the user allows it to happen via Self Service. I recently watched some good videos about jamJAR.....I am thinking this is the direction we might have to go so we have the best of both worlds by combining Jamf and Munki and let them each deal with what they are strong at.

~Scott

[donmontalvo]

We find a Self Service policy running softwareupdate -ir for users to run at their convenience, and a second policy to PUSH the same to them on N day of the month with daily countdown Notification Center prompts starting 7 days out to warn of impending PUSH does wonders in getting recommended macOS security patches installed. ;)

[mm2270]

@scottlep It sounds like what would serve you is to use a scripted SWU process, rather than relying on built in functionality. For example, there are existing scripts out there, at least a couple here on JamfNation in fact, that will pull a list of available updates on a machine and parse out just the ones that don't require a reboot, which can be placed into an array or string to pass to a softwareupdate -i command. All reboot required updates are clearly labeled as such when pulling an update list with the softwareupdate binary.

Similarly, you could script a notification to the user about pending reboot required updates. Policies also have the ability to set deferral options and a drop dead date of when the policy must run. Look at the User Interaction tab when setting up a Jamf Pro policy and you will see the options there.

So, while what you're after is not a straight built in checkbox or policy payload, it can definitely be done with Jamf Pro. It will just take a little work in developing the process.

[UESCDurandal]

@donmontalvo Hey Don. Your strategy for Apple updates sounds interesting. I'd be curious to know more about how you're deploying your daily countdown Notification Center prompts. For example, do you have one policy dedicated for these notifications? Are you using cocoadialog?