Overall - How do you handle patching?

[macsaeki]

We have about 200 employees with all 100% WFH. On paper, I think our patching numbers looks good relative to our user count each week, but my boss isn't buying it as optics are funneled all through Slack and each week, we have about 3 - 5 people complain an app broke during patch. My boss also gets hit up with anecdotal issues of someone complaining to him something broke during patching, and all of that is coming to me. We are using just policy based scripts with smart Groups, instead of leveraging Patch Management, Installer, and 3rd party tools. My question is what does a healthy patching environment look like in terms of statistics? Do you have complaints each week that an app broke? What percentage just fixed an app themselves without reporting or complaining? What are you using to patch our heavy hitters: Zoom, Chrome, and Slack?

[user-dIrrpGXxza · Accepted solution]

First, in general, to me it seems that macOS and iOS users have been spoiled for years that they don't need to patch. Since we manage both Windows and Apple devices, user resistance to patching and what is deemed as acceptable interruptions has a way lower tolerance base for the Apple user community. I think this is because Apple devices have generelly been unmanaged or at least less managed, with less requirements on patching and policies. I also have a hunch that many users who choose Apple devices do so just because they are given more freedom on those devices. But this is now changing with more management options, stricter patching due to Apples appaling security track record in recent years, device attestation, managed appleID's etc.. So, in my experience, many of these complaints is because they had to patch at all and they don't bother to update their legacy apps.

With that said, to keep certain "heavy hitters" apps up to date, we generally use the script installomator as a fallback if they bult-in auto updates aren't working to a satisfactory level. You can use that script as a policy, either for everyone in fully automatic mode, as an optional self service item, or in our case scoped as an automatic policy to those users that have an older version installed. This is accomplished by creating smart groups based on the app version installed.

When it comes to patching statistics, the patch deployment levels for Apple devices are generally expected to be slower/less penetration than for Windows devices, because the tools available to patch are less "sharp" (look for all the threads for the ming-boggling difficulties and methods to patch macOS), combined with that JAMF itself seems easier to circumvent than say SCCM on Windows. A quite large minority tend to uninstall the JAMF framework, indefinetly delay execution of policies with deferrals (by not clicking anything), blocking reboots by having the Terminal running, installing VPNs, proxies or otherwise blocking communication with the JAMF MDM servers etc.

Hope this helps and gives you some insights!

[macsaeki]

First, thank you for your response and great points that i haven't considered. 

So our patch days are Wednesdays, and one of the points from your response got me thinking if we should just use the built-in auto update, or have it auto update instead. by avoiding updating all of our apps in one day might alleviate patch breaking something.

[MatG]

We use the following in order of preference:

Profile - If possible use Profile to force updates, e.g. MAU or Chrome
Apple App store Apps - Provide apps from Apple App store as these can be set to autoupdate
Jamf Catalogue - Specify updates via using Apps listed in the Jamf App catalogue, set deadlines
Installomator - Create policies using Installomator script to update apps, we also use SwiftDialog with installomator
Custom Scripts or other vendor scripts/process e.g. Adobe RUM - Use policy to run script
Patch Policy with Definition - last as requires tracking vendor release, then download, pkg (if required) upload to Jamf, labour intensive.