Skip to main content
Solved

Enrollment trigger for Intel vs M1 (Apple Silicon)

  • April 28, 2023
  • 4 replies
  • 40 views
J
Forum|alt.badge.img+3

For new devices and troubleshooting older devices with an OS reinstall, we use the "enrollment" trigger for many of our Mac policies. We have been avoiding creating separate Intel and M1 packages for apps as much as possible. Rosetta has been capable of running all our Intel-based packages on M1s so it hasn't been an issue but I don't want to rely on Rosetta indefinitely. I would like to be able to install either the Intel or M1 versions of apps on enrollment. Is there any JAMF Pro setting I'm missing for the enrollment trigger being able to install the appropriate architecture/processor based package?

Looking at alternative solutions: Eventually, our fleet wont have any Intel Macs but until then we still push a pool of default apps to our fleet and use Self Service to make non-essential/optional apps available. Without the enrollment trigger we have relied on having to flush once per computer policies for OS reinstalls or making policies set to "ongoing" at startup with smart groups to include/exclude devices without the app installed. As an on-prem Jamf system, we try to avoid excessive smart group and "ongoing" frequency policies. 

Best answer by steve_summers

@jguzzo , your question: >>Is there any JAMF Pro setting I'm missing for the enrollment trigger being able to install the appropriate architecture/processor based package?<<

There isn't a setting specifically for the Enrollment trigger to fire based on Architecture.  However, you can always create a policy scoped to ARM devices and in that policy, use the Enrollment trigger.  That's one easy way to get the results you're after.  

Hope that helps.

    4 replies

    S
    Forum|alt.badge.img+9
    • steve_summers
    • Valued Contributor
    • Answer
    • April 28, 2023

    @jguzzo , your question: >>Is there any JAMF Pro setting I'm missing for the enrollment trigger being able to install the appropriate architecture/processor based package?<<

    There isn't a setting specifically for the Enrollment trigger to fire based on Architecture.  However, you can always create a policy scoped to ARM devices and in that policy, use the Enrollment trigger.  That's one easy way to get the results you're after.  

    Hope that helps.

    mm2270
    sdagley
    Forum|alt.badge.img+25
    • sdagley
    • Jamf Heroes
    • April 28, 2023

    @jguzzo I used to differentiate enrollment policies using a processor architecture Smart Group like @steve_summers suggest and it worked well. As we've moved to almost all of our standard installs being available in Universal I no longer use that approach and now use a single enrollment policy for x86 or Apple Si machines, and for the few installs that aren't Universal I created a wrapper installer that bundles both the x86 and Apple Si installer then uses a postinstall script to check the architecture and run the appropriate installer. I could have achieved the same result by having separate policies for each installer triggered by the same custom event and using an architecture Smart Group to control which one ran, but for me fewer polices was the better tradeoff.

    T
    Forum|alt.badge.img+9
    • TrentO
    • Contributor
    • April 28, 2023

    @jguzzo , your question: >>Is there any JAMF Pro setting I'm missing for the enrollment trigger being able to install the appropriate architecture/processor based package?<<

    There isn't a setting specifically for the Enrollment trigger to fire based on Architecture.  However, you can always create a policy scoped to ARM devices and in that policy, use the Enrollment trigger.  That's one easy way to get the results you're after.  

    Hope that helps.


    Going further with this, if you create smart groups for Intel and ARM and scope policies to them, the. you can set the same custom trigger name for both policies. Then calling the custom trigger from your enrollment script will run the appropriate policy. 

    J
    mm2270
    cmccormack
    Forum|alt.badge.img+3
    • cmccormack
    • New Contributor
    • May 1, 2023

    I have been creating an all in one PKGs that auto determines the arch of your machine and installs the corresponding edition.  This allows a single Install Policy and Patch Policy that works on both Intel and Apple Silicon Macs.

    There are two types, one for PKGs and one for Apps.  You then put them into Composer with the permissions for the root of the folder set to Root, Wheel.

    These are post install scripts with Shell.

    PKG (Example Figma)

    #!/bin/sh ## postinstall pathToScript=$0 pathToPackage=$1 targetLocation=$2 targetVolume=$3 if sysctl machdep.cpu.brand_string | grep -w "Intel" ; then sudo -S installer -allowUntrusted -verboseR -pkg /private/tmp/figma/x86_64/Figma-Intel*.pkg -target / fi if sysctl machdep.cpu.brand_string | grep -w "Apple" ; then sudo -S installer -allowUntrusted -verboseR -pkg /private/tmp/figma/arm64/Figma*.pkg -target / fi rm -rf "/private/tmp/figma/" 2>/dev/null exit 0 ## Success exit 1 ## Failure

     

    Applications (Example Miro)

    #!/bin/sh ## postinstall pathToScript=$0 pathToPackage=$1 targetLocation=$2 targetVolume=$3 mkdir -p "${3}/Applications/Miro.app" rm -rf "${3}/Applications/Miro.app/Contents" if sysctl machdep.cpu.brand_string | grep -w "Intel" ; then rsync -aE --delete --link-dest="/private/tmp/miro/x86_64/Miro.app" -- "/private/tmp/miro/x86_64/Miro.app/" "/Applications/Miro.app" fi if sysctl machdep.cpu.brand_string | grep -w "Apple" ; then rsync -aE --delete --link-dest="/private/tmp/miro/arm64/Miro.app" -- "/private/tmp/miro/arm64/Miro.app/" "/Applications/Miro.app" fi rm -rf "/private/tmp/miro/" 2>/dev/null exit 0 ## Success exit 1 ## Failure

     

    Terms & ConditionsCookie settingsAccessibility statement