One Policy for Intel and Silicon

[foreverkan]

Hello,

As you know, some applications have separate installation files for Intel and Silicon. For example, I write 2 separate policies for Android Studio.
1 - Android Studio for Silicon
2- Android Studio for Intel

By creating a single policy instead of these two policies. Is it possible to distribute this policy according to the processor model of the machine in scope?

In short, I want to design 1 policy and 2 packages.

Thank you.

[dsavageED]

The easiest answer is some form of scripted toggle, either toggling an install package or a policy call... Basic example would be:

if [ `arch` == arm64 ]; then
	# Install a package (from Resources of a master pkg) installer -pkg "AnArmVersion.pkg" -target "${3}" -dumplog 
	# Call a jamf policy /usr/local/bin/jamf policy -event AnArmVersion
else
	# Install a package (from Resources of a master pkg) installer -pkg "AnIntelVersion.pkg" -target "${3}" -dumplog 
	# Call a jamf policy /usr/local/bin/jamf policy -event AnIntelVersion
fi

[foreverkan]

Thank you for your reply. I'm not expert at Jamf Pro. How can i toggle or do policy call for a policy?

[sdagley]

Another approach that avoids the need for a script to determine the target architecture is to create separate install policies for each architecture triggered by the same custom trigger (e.g. "InstallAppXYZ") and using a scope exclusion to control what processor type it installs on, then have your primary policy use a Files and Processes payload to execute the command "jamf policy -event InstallAppXYZ"). This will trigger installation of the appropriate version without requiring a script.

[foreverkan]

Hello Friend,

i couldnt understand this line.

Install a package (from Resources of a master pkg) installer -pkg "AnArmVersion.pkg" -target 

I deploy my packages with smb filesharing. can i set command for that?

[dsavageED]

I'll go into a little more detail and give some context.

When you create a jamf policy it has an associated trigger with it. You can have a custom trigger MyApp which can be called (jamf policy -event MyApp) to execute that policy on demand.

Once a policy has the My App trigger and is say scoped to All Computers, you can run sudo jamf policy -event MyApp on any of your jamf clients to have them run the policy. That call could also be executed from within another policy or a script.

This thread is pretty good for info on custom triggers https://community.jamf.com/t5/jamf-pro/understanding-custom-triggers/m-p/192897

[Mattdjerome]

I use installomator for exactly this purpose. https://github.com/Installomator/Installomator/blob/main/Installomator.sh The logic in the script will determine the cpu and curl the correct version resulting in only 1 policy being needed

[AJPinto]

I typically just do two policies as its easier to maintain. However, it is possible to build a package to do what you are wanting. 

1. Place both Intel and Apple Silicon packages in a working directory.
2. Use Composer to build a package containing both packages from step 1.
3. Use a post install script to check the CPU architecture and run the correct package and clean up the source files when done.

I have used the script below in the past.

#!/bin/sh
## postinstall
 
pathToScript=$0
pathToPackage=$1
targetLocation=$2
targetVolume=$3
 
 
# Check the processor architecture and run the correct package based on results.
 
processor=$(/usr/sbin/sysctl -n machdep.cpu.brand_string | grep -o "Intel")
     
if [[ -n "$processor" ]]; then
        echo "Installing Intel Package"
        installer -pkg "/private/tmp/Java_JDK_17.0.6/Oracle_Java_JDK_17.0.6_x64.pkg" -target /
        echo "done installing Intel package"
    else
        echo "Installing M1 package"
        installer -pkg "/private/tmp/Java_JDK_17.0.6/Oracle_Java_JDK_17.0.6_ARM64.pkg" -target /
        echo "done installing m1 package"
fi  
 
sudo rm -rf "/private/tmp/Java_JDK_17.0.6"
 
exit 0;     ## Success
exit 1;     ## Failure

[bmcintire]

One easy way we accomplished this was to make the two policies that actually install the app - one for Intel and one for Apple Silicon. Have them trigger by custom event - "installAppName". You make BOTH the same trigger name, but only scope them to their respective architectures via Smart Group. That way, you can use the same trigger NAME, but the scoping will pull the correct architecture.

Then you have primary policy scoped to all that will call the trigger. 

This is especially helpful in the event the separate releases are not in lock step for some reason and you can update one or the other. You should never have to change the actual policy that calls it as it just calls a trigger. 

Ex:

Name                     Frequency                Trigger               Scope

Install App Apple   Ongoing                   installApp           Apple Silicon Macs, 2 computer groups excluded

Install App Intel     Ongoing                    installApp           Intel Macs, 2 computer groups excluded

App                       Once Per Computer  Check-In            All Computers