On going/back to back to back Zoom and Chrome update

My users are not having it. What used to be forced updates is now Notifications only and available in Self Service.
But yeah, Chrome and Zoom are keeping me busy... It is kind of sad funny, that we get to 25% compliance then a new patch is out.

I keep Chrome on auto-update and Zoom a Self-Service policy with notifications like @robertliebsch does. However, I will likely force the next major version.

@Chris_Hafner Can you share you notification workflow?

When we started to officially roll out Zoom (prior to this users would download and install to their user/application folder) I had three policies made:
1. Main install policy
2. log out / log in trigger, set to run 1x
3. self service trigger

Policy 2 and 3 will kick off the Main Install policy

Next steps are:
1. scope the force install to computers that don't have app
2. scope the force install to computers with Zoom being out of date

I try to keep it as simple as possible. That usually means only two policies, if possible, for most installs (Enrollment and update) but this one took three. For the initial rollout/new install (scoped in this case to any managed machine that didn't have it). This was based off a smart group and my execution frequency was set to "ongoing". A recon at the end of my policy removed the machine from the smart group so that will sort that. If the user ever deleted the app, it would have simply reinstalled. This policy is set to trigger either at recurring check-in OR via Self-Service but I set no initial notifications. Moving forward, zoom.us is being distributed during enrollment (both DEP and User-Based Enrollment via DEPNotify).

Our update policy is based on a smart group looking at patch definitions. I'd like to be using a script to pull the latest enterprise installer, but I haven't had the time to test that. I mean, I've tested it at home, but not wide enough for distro. With 0 of my users within physical reach, I'm being a little extra cautious. Especially since they now live via zoom. This update policy is also available via Self-Service (with upgrade instead of install labels) and so any time the policy gets updated a notification gets sent out to any machine that qualifies for the upgrade... assuming you remember to update the smart group first.

Unfortunately, that has been an every 72-hour thing it feels like. 4.6.12 (20615.0421) is out so that's hopefully the last before v5... which was supposed to release this week. Oh well.

P.S. Log-in and Log-out triggers are tough things on the end-user. I mean, if you have to, then you have to, but I'll do anything I can to avoid installing anything at log-in or log-out.

I'm starting to take another angle on this. Instead of using Patch Policy and posting it to Self Service, I've set up Smart Groups that say AppName is not Version X. That group becomes the Scope of a Policy that will install the new software. The software is ALSO still availble in Self Service. The Policy, under User Interaction, Allows Deferral up to an arbitrary deadline. When the user falls into that smart group and the policy executes, they get the following pop up on screen. If they don't do the update immediately, they get to choose their deferral. If they defer to the end, the app will be updated forcefully on the deadline date/time.

Just sharing what I have been doing, I have an iMac as my index machine, which I install all the apps on. Chrome and Zoom and Loom have been the popular ones lately, but all I do is run them, allow them update, then make sure they are Quit. Then I drag it from Applications to Composer, and create a new package and upload to JAMF. From there I usually put it in SelfService and put it on the end users to go and get when needed, but every once in a while someone higher up is right in the middle of a meeting so I just push it through a policy. TODAY was a fun one, Zoom decided to cut off everyone who was not on version 5.0 or newer, so all my procrastinators were screaming for updates, and I reminded them about the Self Service, keyword "Self".

This is why I decided to do an AutoPKG JSS Importer static Python code pipeline into my JSS. I have seen Zoom rev versions many times per a month, so I just automate it. It is policy driven so there are ongoing policies that install the newest version by version smart groups. It has flaws/caveats because of how jamf currently handles app data and app installs on the product side. However, I haven't built a package for a third party app (sans a specific binary) in over a year and a half.

This is also why I submitted this feature request

I have posted my code/templates on my GitHub here. It has been in production for 1.5 years now and delivered many 3rd party app updates automatically

Thanks Tom and everyone,
it's just good to know that other admins are also updating back, to back, to back and so on... with out seeing any major issues.
: )

I don't mind my semi-automated process, it lets me "feel" in control. As always Tom is right instead of "worrying" about updates I should be learning more about macOS security and Jamf Protect.

Thanks!!!

C

@gachowski no problem! The way I approach it is probably not like most jamf admins. I always try to silent patch all apps at check in, but only if the app is not running. If an app is not patched, each user gets a weekly prompt per an app, and I did it this way to reduce notification fatigue and not spam my users. I also do auto patch right to prod, as most apps these days have self update mechanisms and you cannot really stop users (at least in my env) from installing software. So, you aren't really controlling it anyway. Plus I have only ever seen an app break things from an auto update horribly 1-2 times in my 20+ years in tech. Both times it was bad, it was tied to email.

So, I am pretty comfortable with the AutoPKG - integrations - JSS Importer - my Python code as an end to end automated solution. When I swapped jobs, I did not want to waste cycles, time, effort, for a QA process that ultimately can only ensure an app installs and launches. Unless you are doing extended app testing, that is all you are doing. So, the first thing I did was create this process and write this code. I know it may not work for everyone, but it works for us and has been running in my prod env for about 1.5 years now. I have delivered 100s of updates to endpoints with out me packaging up the apps, nor doing anything but creating the initial static policy chain.

@atomczynski - How do you deal with forcing the update, what if the end user just fired up a Zoom Meeting and then the update interrupts?

@supson this is why I silent patch, but only if the app is not running