Patch Management - Am I overthinking this?

[VintageMacGuy]

I am taking over an existing JAMF environment and Patch Management is new to me, so trying to wrap my head around this and see if I am missing something or if anyone has any Patch Management tricks that make life easier.

Let's use Zoom as an example. We have a lot of versions of Zoom out in the environment right now. But we should get everyone on a current-ish version. so I go into Patch management and create a Patch Management Policy (is that the right term?) where Zoom is selected, scoped to all machines, and pointing to a .pkg I have in JAMF that has our currently approved version. I can set Patch Management to go and automatically update all the machines now, or set it in Self Service. There are a few other bells and whistles for downgrading from a higher version or overwriting an unknown version.

Next time Zoom has an update, JAMF will notify me by email/alert that a new version is available so I can go grab it, test it, package it, and add a new policy in Patch Management that says go forth and upgrade to this new version (and I suspect I will need to delete the old policy?).

Is that it in a nutshell?

Now - How do you handle Office updates? Patch Management doesn't have the full Office suite as an item to watch for. But it does have Excel by itself, Word by itself, Outlook by itself, etc. Do I just pick one (or all) of those apps and break my Office install into individual installers? Or use one app (like Word) to flag that there is an update, then manually make a Policy OUTSIDE of Patch Management to basically do the same thing - Upgrade those machines that are below the standard?

I also saw a comment that Patch Management will only work on apps installed via JAMF.

This seems - nice - but not quite a complete solution to me. Or maybe there are some sweet sweet tricks I can use to make this much better?

[sdagley]

@VintageMacGuy For Office updates you'll want to use Microsoft AutoUpdate (MAU), either its built-in automatic update mechanism or scripted updates using the msupdate tool built-in to MAU. This is because MAU will use incremental updates which are much smaller than the downloadable updaters (you'd be better off re-running the full Office installer than the individual app updaters).

There is a Microsoft Build article that talks about configuring the update options in MAU: https://docs.microsoft.com/en-us/deployoffice/mac/deploy-updates-for-office-for-mac

You'll also find multiple threads on Jamf Nation that mention @pbowden's MSUpdateHelper4JamfPro and MSUpdateTrigger scripts (found here: https://github.com/pbowden-msft/msupdatehelper) which can be run via Jamf Pro and use the msupdate tool to install Office updates.

[wildfrog]

For MS updates, it depends on what you're looking for. @sdagley's method is perfectly valid. But we prefer to keep the app update experience unified in Self Service as much as possible as opposed to some via SS, some via MAU, etc. We download the updates for each app via macadmins.software and yes, they are larger. It's a tradeoff we're willing to make for a more unified experience for the user.

My main complaint about Jamf's built-in patch management is that in Self Service, Jamf puts the updates under "Notifications" - which every user I've asked about has found really unintuitive. I'd love to hear Jamf's rationale for combining updates and notifications.

[VintageMacGuy]

Thank you both for the feedback. Looks like I have another tool to learn and add to my skills.

[petecurtner]

For anything that could be in use with a client or other third party, like Zoom, be careful using the Install Automatically option. A traditional policy will still give you much more control over when to install an update (outside local business hours).

[VintageMacGuy]

Good point. Worth mentioning. We are setting up a test group of volunteers who will get the patches ahead of a full deployment and after an initial "This-won't-crash-all-our-computers" test. Nothing automatic - needs to be human (or as close as we can get) reviewed before deployment.

[SCCM]

we just use a extention attribute to check the version of zoom installed on a machine. If its a older version a policy will run on login based on smart group. Never had any issues with it.
Link to the policy update:
https://www.jamf.com/jamf-nation/third-party-products/files/1051/install-latest-zoom-client
cant remeber where the extention attribute was from so cant credit it

#!/bin/bash
#This script is used as an extension attribute and compares
#the IT installer version on the Zoom site vs what the user is running
if [ ! -d "/Applications/zoom.us.app" ]; then
  echo "<result>Not Installed</result>"
  exit 0

else

#Determine current OS version to pass to user string
  OSvers_URL=$( sw_vers -productVersion | sed 's/[.]/_/g' )
#Create useragent to pass into curl command
  userAgent="Mozilla/5.0 (Macintosh; Intel Mac OS X ${OSvers_URL}) AppleWebKit/535.6.2 (KHTML, like Gecko) Version/5.2 Safari/535.6.2"
#Pull current available version of Zoom from their site
  latestver=`/usr/bin/curl -s -A "$userAgent" https://zoom.us/download | grep 'ZoomInstallerIT.pkg' | awk -F'/' '{print $3}'`
#Get current version installed on computer
  installedVersion=$( defaults read /Applications/zoom.us.app/Contents/Info.plist CFBundleVersion )
#Compare zoom version vs installed version, print result

if [ "$latestver" == "$installedVersion" ]; then
  echo "<result>Latest</result>"
  exit 0
else
  echo "<result>Old</result>"
  exit 0
fi
fi