I was in the process of performing some patch management for the Zoom client and found there are two different versions offered, one for Intel and one for Apple silicone. How do I create separate patch management policies for the two separate architectures? I can only select 1 package in patch management for the Zoom client.
Make it easy on yourself, use the Zoom for IT installer which has a Universal binary.
Now when it comes to something like VLC, that's a different type of problem. 3.0.12 is x86_64 and 18.104.22.168 is arm64 - Jamf only updated the definition to 3.0.12.
Who knows what other crazy things developers will do when they update their apps, and how often will they change their mind. Until Patch is improved, we'll need to use a good external patch definition source (or make one), and make some smart groups to scope to the right architecture.
If y'all would like to have a separate Apple Silicon patch title for any applications in particular make sure you submit an individual feature request for each one. That helps the teams see what's in highest demand to best prioritize building out that patch title in the Patch Management service.
As if Patch Management wasn't hard enough, multiple architectures now complicates it even further. Those interested in an intelligent Patch Management solution that easily accommodates both x86_64 and arm64 architectures might want to check out Alectrona Patch in the Jamf Marketplace. Feel free to chat with us for more details.
You can also just add Jamf again as an external path source with https://jamf-patch.jamfcloud.com/v1
Use the secondary one for arm64 titles. That doesn't help for titles like VLC where the version is slightly different but it's a quick fix for those where the version is the same across architecture.
Hey @darth_undesirable ,
This is not exactly what you asked for, but it helps a lot to keep the environment up to date, and from my knowledge, it's for both Intel and M1 chips.
just run it once a week and all your zoom clients will be upgraded to the latest version.
#!/bin/bash #https://www.jamf.com/jamf-nation/third-party-products/files/1051/install-latest-zoom-client # this is the full URL url="https://zoom.us/client/latest/ZoomInstallerIT.pkg" # change directory to /private/tmp to make this the working directory cd /private/tmp/ # download the installer package and name it for the linkID /usr/bin/curl -JL "$url" -o "ZoomInstallerIT.pkg" # install the package /usr/sbin/installer -pkg "ZoomInstallerIT.pkg" -target / # remove the installer package when done /bin/rm -f "ZoomInstallerIT.pkg" exit 0
Hope that helps something.
I must be missing something, why are companies pushing out non universal binaries? Isn't the fact that you can compile the app to work natively across either architecture the selling point of it?
Having to start putting multiple versions of packages into JAMF to deal with both sounds horrible 😞
@ianatkinson, horrible is a good word for it. I do not know why they are, but they are. In particular Adobe is the biggest offender right now. I'm sure that there are others. With Adobe, you cannot even install an intel application using a package from the Adobe Admin Console unless you choose Apple Silicon when creating that package. To clarify, even if the Adobe application doesn't have an Apple Silicon version yet, you still have to create the installer package for Apple Silicon.
The gist of what I am saying here is that as administrators, we do not directly control what packages are available. In an ideal world everything would be universal, but we don't live in that world. It makes sense then for the tools we use for Mac administration to support the situation where multiple packages are being offered by vendors, as that is the world that we currently live in.
@timdambrosio It seems that Jamf will not allow external patch source set to the URL of the "internal" one https://jamf-patch.jamfcloud.com/v1/. The error is "invalid hostname". If specifying just jamf-patch.jamfcloud.com you get connection error when trying to use it. I'm on 10.29 Jamf cloud