Patch Management - Am I overthinking this?

@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.

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.

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

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).

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.

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