Using Jamf Patch Management for rolling out macOS Updates

tzeilstra
New Contributor III

We've long used Patch Management for the great reporting features (though I do wish I could select which version of the product is the considered the latest version in...) and the notifications of new version releases are invaluable, there's one area where Patch Management has never really seemed to be a viable tool--patching.

My big beef with it is user interaction. If whatever the tool is doing will require some change in behavior on the part of the user, it should ask them before it takes that action and give them the option to postpone.

The area I'm focusing in now is macOS system patches. I'm using the macOS 10.15 Build definition and I've been testing applying the 10.15.5 Combo Update to get everyone up to build 19F101 (initial release of 10.15.5 was 19F96, but the macOS 10.15.5 Supplemental Update that came out five days later kicked it up to 19F101.) I'm not interested in making the patch available in Self Service because no one would ever go into Self Service to go looking for it so I set it to Install Automatically. Because I want to warn the user before their computer restarts, I enabled the Grace Period option to allow users to have a few minutes before the update starts. In my testing, however, Jamf consistently ignores the Grace Period option and just restarts the computer with no warning, no opportunity to save work, and because Apple software updates are huge, their computer is useless for 30 to 60 minutes while the system updates. (I still haven't figure out how I'm going to handle those times when an update comes out, users lose their computer for a half hour or more, and then five days later another update comes out that takes up another half hour.)

How do others handle this? Our solution up until this point has just been to run a weekly script that checks for available software updates and if found, notifies the user that they should go to Software Update and apply the pending updates (a heavily modified version of babodee's excellent patching script). For our own uses, we actually stripped out the defer limit functionality of the script but found (surprise surprise) that users will just defer indefinitely so we'll either have to restore that defer limit in the script or (our real preference) just leverage the built in Jamf tool in a way that doesn't give our users a 30 minute break with zero warning with nothing to do but write angry letters to IT.

We've also run into a similar issue when attempting to update applications but those haven't been as a high a priority with us. We basically have a script that checks to see if the application in question is running and if not, it applies the update. With Jamf Patch Manager, it does throw a notification window in the top left of the screen (and in later versions, it now sees to actually stick around rather than just disappearing after five seconds) but when the price for not noticing that alert is having Jamf kill the application in question with no opportunity to save work, it seems a bit harsh (is it impossible to just send the equivalent of a Command-Q so that the app can shut down gracefully?) If anyone has run into similar issues had has suggestions beyond telling the user it's not really their computer so they just need to put up with us updating it whenever we want, I'd love to hear it.

1 REPLY 1

jwojda
Valued Contributor II

@tzeilstra did you look into using the jamf deferral stuff now built into the user interaction section?

did ripping out the whole deferral section (assuming lines 45-79) cause any other issues?