@michael.madsen, I figured out the issue with the pre-stage enrollment if you are still interested in that scenario. The issue is in the package that you use. According to the documentation, the package has to be signed with the valid Apple Developer certificate - https://docs.jamf.com/10.9.0/jamf-pro/administrator-guide/Computer_PreStage_Enrollments.html

I signed the package using the productsign utility, and it works great. The Rosetta installation happens via pre-install script as part of the pre-stage enrollment package.

The downside is only in being an authorized Apple developer that will cost you $300 a year if you enroll for the Enterprise plan.

Our approach to installing Rosetta 2 before the applications that need it:

1. Create a new script in Settings --> Computer Management called "Install Rosetta 2" that runs "/usr/sbin/softwareupdate --install-rosetta --agree-to-license"
2. Create a smart group called "Needs Install: Rosetta 2". Set criteria to "Architecture Type 'is' arm64" AND "Packages Installed By Installer.app/SWU 'does not have' com.apple.pkg.RosettaUpdateAuto"
3. Create a policy called "Install Rosetta 2" with the scope target set to the "Needs Install: Rosetta 2" smart group, and have it run the "Install Rosetta 2" script.

That takes care of installing Rosetta 2 on ARM macs. Then for each Intel application X, create a smart group similar to above called "Needs Install: X" that finds computers without the application. Then configure a policy that installs X for members of that smart group, but add the "Needs Install: Rosetta 2" smart group to the exclusions list. That way, Intel and ARM macs share most of the configuration - it's just that ARM macs won't install X until Rosetta 2 has been installed.

I'm fairly new to Jamf so apologies if this is all obvious or misses the point.

@mwu1876 I have kept this policy with checked "Enrollment Complete" under general tab. And I have configured scope with SmartGroup Architecture Type arm64. So, once any M1 Mac gets enrolled, this policy will trigger immediately.

@mwu1876 I have kept this policy with checked "Enrollment Complete" under general tab. And I have configured scope with SmartGroup Architecture Type arm64. So, once any M1 Mac gets enrolled, this policy will trigger immediately.

@mwu1876 I have kept this policy with checked "Enrollment Complete" under general tab. And I have configured scope with SmartGroup Architecture Type arm64. So, once any M1 Mac gets enrolled, this policy will trigger immediately.

@davidhogan It's been reported that installing a Big Sur update will remove any existing install of Rosetta. You may want to check and see if the com.apple.pkg.RosettaUpdateAuto receipt is removed when that happens, otherwise you're going to get a false positive that Rosetta is installed.

I also used the routon script. You create a policy, enrollment complete, in theory will run before the applications. I change after to before and set to once per computer. I see that some used ongoing. I had other issues when polices ran that way. But, Jamf also has a files and process payload and just execute /usr/sbin/softwareupdate --install-rosetta --agree-to-license... What's the difference? Files and process will give failed logs, because said machines were Intel based... Just wanted to throw that method as well. For me, I used the script this time, but usually use a Files and Process. Jamf installs it as root. Cheers

@sdagley I haven't tested that, but i've tested dragging the app to the bin. The Jamf inventory refresh appears to be smart enough to detect that case at least.

(I got confused there, it was a different app i did that test with, not Rosetta 2)

Hopefully future Big Sur updates don't force remove Rosetta 2, that sounds like a bug to me if it's happening.

@tcandela AIUI, the Quickadd package method of enrollment does not work in Big Sur - you need to use either the Automated Device Enrollment or User Initiated Enrollment methods.

Anyone have an EA for checking for Rosetta being installed? I installed 11.3b1 on our test machine and rosetta broke and required reinstalling. So might be nice to have an EA in place so we can re-trigger the install process if it ever breaks.

Nevermind, I see the solutions above. Why the heck is Apple breaking Rosetta on updates!?!

@rstasel https://github.com/grahampugh/Rosetta-2-install/blob/main/Rosetta-2-install.sh can be a good check.

Edit here is the EA:

#!/bin/bash
​
: << DOC
EA to determine whether Rosetta is installed. 
Possible results:
"installed"    - arm64 Mac - Rosetta is installed
"missing"      - arm64 Mac - Rosetta is not installed
"ineligible" - Intel Mac - Rosetta cannot be installed
DOC
​
# is this an ARM Mac?
arch=$(/usr/bin/arch)
if [ "$arch" == "arm64" ]; then
    # is rosetta 2 installed?
    if [[ -f "/Library/Apple/System/Library/LaunchDaemons/com.apple.oahd.plist" ]]; then
        result="installed"
    else
        result="missing"
    fi
else
    result="ineligible"
fi
​
echo "<result>$result</result>"

@randy.andersen Awesome, thank you! I'll add this to our EAs. I'm not sure if the package route does/will work.

Thanks! Saved me from doing it. =)

Has anyone noticed the occasional Apple Silicon reporting its arch type incorrectly? I've had a few occurrences of new machines showing "Processor type: Unknown" and "Arch type: x86_64" (including my own, which is how I discovered this behaviour). Then after a day or two (on the next Inventory Report I guess) they generally fix themselves.
The immediate consequence is that they become scoped incorrectly and potentially receive the wrong profiles and policies!

As a workaround I added these two criteria to my Apple Silicon scoping:
- Model Identifier is MacBookPro17,1
- Model Identifier is MacBookAir10,1

Out of curiosity I created a smart group to catch these machines and see how frequently they appear. So far every week there's been one or two (we have 36 Apple Silicon enrolled so far)!

@fponcelin That's... not great. Have you opened a case with Jamf about this?

I haven't, but will do right away!

ok how do i create a smart group to add this to the m1 proc. I tried to create one with Processer type Apple M1 but nothing worked

@David.Lynch You want a smart group where "Architecture Type" is "arm64".

@mwu1876 How did you manage to start the installation process again after the Rosetta installation? Can you show me the complete script or the process? Thank you!

Hi All

thanks for the script.
I had a similar issue with the M1 Mac's using Pre-Stage Enrollment > DEPNotify.sh
added the script to a policy
then made sure its the first one listed in the Array List in DEPNotify.sh script

this in turn makes Rosetta 2 install prior to all my other applications

Seems to work on my Test Machine

For those that haven't installed Rosetta early enough (or are not using ADE), you could find yourself in a situation where softwareupdate has run and discovered a macOS update, but not discovered an update for Rosetta.

If you install Rosetta after softwareupdate has run, it won't include updates for Rosetta and you'll lose Rosetta after the macOS update is installed. This botched my machine that had an Endpoint Security system extension installed, which relies on Rosetta.

I would consider adding softwareupdate -l at the end of any Rosetta install scripts to ensure an update is picked up. I'm yet to test that this will prevent Rosetta removals in the above scenario, will report back when I do.

I got it to work on my end 100 percent of the time. Info: I use an all for nothing method, meaning my machines, although we have 500 plus all get the same base applications and policies. I use a files and process payload and daisy chain policies, because I wanted my dock policy to run 100 percent of the time too.

What I tried before: Running a script in a policy and renaming with a 1 so in theory, based off another post, it would be priority 1 - not the case. NBD. The second, was using a blank pkg and making it priority 1. I added a post install script of the rosetta install. Did not work, because you need Rosetta on a machine before installing a pkg.

What worked for me: Policy 1 *M1 Rosetta Install Policy
Once per computer Enrollment All computers, All users None ( I am a big all computers all users when pertaining to a base flavor) Files and Process payload: Run Unix command '/usr/sbin/softwareupdate --install-rosetta --agree-to-license;/usr/local/bin/jamf policy -event baseapps'

Ok two things are happening here: 1.) runing the install for rosetta after the enrollment is complete. So, after we enroll, it installs Rosetta on all machines. If it's intel, nbd. If it's Arm, it does what it needs to do. Then by using a ";" you can then add another command. This is where I start daisy chaining apps. I called it baseapps.

Now in Policy 2 the base app policy I have this -1 CF Base Application Install / Checkin and Policy Trigger
Once per computer baseapps All computers, All users None
What I did here was instead of a enrollment complete trigger, I use a custom trigger and declared it as baseapps

So, Enrollment happens > Rosetta installs and that policy then triggers the baseapps policy. That installs all my apps. Thus, the apps run after Rosetta. Extra Credit (making the dock run 100 percent of the time)
In my Base applications policy, I also use a files and process to run Jamf recon: jam policy. That then runs 2 CF Dock Policy Trigger that runs at recurring checkin and uses a files and process /usr/local/jamf/bin/jamf policy -event eventdock. This runs my 3rd policy which is a dock policy payload and a files and process that runs after when eventdock is called. In case anyone else was having "why doesn't the dock work 100 percent of the time and yes since Casper it's been like that". Since we really only want that policy to run once on onboarding. If you had the policy run every time, engineers would get mad... Anyway hope this helps.

The first line in my DEPNotify script installs Rosetta. It has worked well so far. I use the same command as in the OP.

Hi, has anyone managed to work out a way to identify (to create a smart group) macs without Rosetta installed?

Thanks

Doubt jamf had that capability so you’re looking at an extension attribute script to determine if Rosetta 2 is installed