Posted on 01-14-2021 03:45 PM
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.
Posted on 01-15-2021 01:39 AM
You can't. I asked this of Jamf Support yesterday. I asked them to clarify how we can do it then but I've yet to receive an answer.
Posted on 01-15-2021 12:37 PM
Maybe setup a whole new Site within your instance for just new machines?
Posted on 01-15-2021 09:53 PM
A workaround I can think of is to roll your own patch management server then set up a separate Zoom patch feed so that you can set up a new patch management profile specific for M1 apps. I have yet to test if this works.
Posted on 02-02-2021 03:05 PM
You can also create your own custom package that has both of them included and some code to detect M1 use this package, non M1 use this one.
01-27-2022 09:56 PM - edited 01-27-2022 10:03 PM
That's what I did. Using this method for Webex Teams & Meetings until they come up with a universal package. Here's what my postinstall script looks like and the referenced payload structure. If anyone needs help borrowing this method let me know.
#!/bin/sh ## postinstall pathToScript=$0 pathToPackage=$1 targetLocation=$2 targetVolume=$3 #Set the temp paths to run the package dir="/private/var/tmp/webex" dirarm64="/private/var/tmp/webex/arm64" dirintel="/private/var/tmp/webex/intel" #Store device architecture type uname=$(uname -m) #Check for ARM architecture if [ $uname = "arm64" ]; then #Install the ARM package echo "ARM Mac detected, installing arm64 Webex package." /usr/sbin/installer -pkg $dirarm64/Cisco_Webex_Meetings.pkg -target / #Check for Intel architecture elif [ $uname = "x86_64" ]; then #Install the Intel package echo "Intel Mac detected, installing x86_64 Webex package." /usr/sbin/installer -pkg $dirintel/Cisco_Webex_Meetings.pkg -target / else #Architecure check failed echo "Architecture did not match arm64 or x86_64, aborting install." fi #Cleanup tmp files /bin/rm -rf $dir
Posted on 01-28-2022 12:06 AM
The current Webex Meetings ‘Apple M1 chip’ download package is universal. Don’t know why they don’t label it as such. The package has seperate binaries for x64 and Arm inside with a script that does the detection.
Posted on 02-03-2021 06:50 AM
way too difficult for me. Seems Jamf have no plan to fix this either which is a shame.
Posted on 02-04-2021 09:30 AM
Really, all we'd need is two Definition lines for each release.
e.g. for Zoom:
5.5.1 (12484.0202) x86_64
5.5.1 (12484.0202) arm
Posted on 02-04-2021 11:21 AM
Indeed but they won't do it and I can't see all apps suddenly working any time soon.
Posted on 02-06-2021 07:13 PM
The Zoom 5.5.1 IT installer looks to be a universal binary. Perhaps they received some feedback that distributing separate binaries for each architecture wasn't enterprise friendly...
Posted on 02-08-2021 04:16 AM
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 188.8.131.52 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.
Posted on 02-09-2021 03:27 AM
OK thanks I'll see if the universal binary takes on my M1 macbook
Posted on 02-16-2021 04:25 PM
Not all apps will have universal binaries, upvote this one:
Posted on 05-06-2021 09:18 PM
Cisco Webex another one that comes in x86 or ARM only.
Posted on 05-06-2021 09:45 PM
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.
Posted on 05-07-2021 10:59 AM
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.
Posted on 05-07-2021 06:11 PM
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.
Posted on 12-06-2021 05:58 AM
Hi Tim, I loved your suggestion for the problem, but I just can't seem to add that again. I get "invalid source" when I try. How did you manage to do this?
01-06-2022 02:12 PM - edited 01-06-2022 02:12 PM
Probably need to drop the https:// from the url, see below he responded to someone with that suggestion and a screenshot.
@timdambrosio - I would like to give this a try. I've setup the secondary patch source for Apple Silicon software.
I selected Adobe Creative Cloud in both.
It has ingested data from our fleet from both, looks identical as it should.
So now I would attach the Intel package to one, and the Apple Silicone package to the other.
I guess I'm just worried about things colliding? Our Creative Cloud desktop app policies are setup with smart group targets/exclusions so that intel will only show up if you have intel, apple silicone will only show up if you have apple silicone.
How will patch management know to install the silicone version on ARM computers and the intel version only on intel? Or will both run on all machines and the version is isn't compatible will just fail.
I might be overthinking this, but I was just worried about things colliding somehow.
Seems like a good suggestion, I just wanted to hear more before I actually try it.
Posted on 01-07-2022 03:08 PM
You just need to add the appropriate exclusion group to each patch policy. So All Intel Macs excluded from the ARM patch polices and vice versa.
It also helps to name everything clearly with _ARM or _Intel or use hyphen if that's your thing. The patch polices themselves don't need that though otherwise it'll show up in self service and look **bleep**. Just the software titles.
Posted on 01-07-2022 04:18 PM
Awesome, makes perfect sense. I just hadn't quite proceeded that far out of caution. Just did it as you said and it's working. This is sweet. Many thanks!
Posted on 05-09-2021 06:11 AM
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.
Posted on 05-10-2021 06:32 AM
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 :(
Posted on 05-10-2021 12:38 PM
@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.
Posted on 05-27-2021 07:55 AM
100% not surprised that we're upset about Adobe installers again, but hey, at least flash is finally and actually dead.
Posted on 06-01-2021 07:21 AM
Ah Adobe. I can feel my hair getting a bit greyer already.
Posted on 06-02-2021 04:32 AM
@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
Posted on 06-05-2021 09:47 PM
Posted on 07-08-2021 03:11 AM
Worked like a charm @timdambrosio