Deploy Rosetta on M1 machines before everything else

[mwu1876]

We have several M1 chip MacBooks that we want to deploy. How can we push and ensure the Rosetta policy to install (softwareupdate --install-rosetta) gets installed before all the other policies (i.e. Office, TeamViewer, etc.) ? If not, the other installs will fail. I can create a separate policy for each application that has a different scope but that becomes a pain.

[davidhogan]

@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.

[davidhogan]

(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.

[mark_mahabir]

@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.

[rstasel]

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!?!

[Anonymous]

@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>"

[rstasel]

@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. =)

[fponcelin]

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)!

[rstasel]

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

[fponcelin]

I haven't, but will do right away!

[David_Lynch]

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

[rstasel]

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

[mickl089]

@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!

[steve0303]

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

[davidhiggs]

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.

[santoroj]

Did this test out for you?

[jmancuso]

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.

[Keith__Myers]

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

[massive]

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

Thanks

[Cayde-6]

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

[Cayde-6]

Derflounder’s script looks for this file, if it exists then Rosetta2 is installed

/Library/Apple/System/Library/LaunchDaemons/com.apple.oahd.plist

https://derflounder.wordpress.com/2020/11/17/installing-rosetta-2-on-apple-silicon-macs/

[Cayde-6]

<Removed>

[btrav]

No luck getting Derflounder’s script to work. Possibly because of latest macOS Big Sur update to 11.3.1. The script says Rosetta has been successfully installed but then the Jamf Policy app installs fail stating please install Rosetta 2 and try again. If I try and install an Intel app manually I get the macOS pop up screen stating to install Rosetta 2 to install the application.

[mickl089]

@btrav Do you use DEPNotify? Which version if?

[btrav]

@mickl089 Not using DEPNotify yet but looking to do so. Jamf Pro is a fairly new set up at our institution. We only install several basic apps currently on first time set up. Cisco AnyConnect is one app that will not install via Jamf after Derflounder’s script successfully is completed first separately. It's almost like Apple is forcing the install to be interactive even though the script is telling it not to.

[tcandela]

@mwu1876 hey, i'm going to use the same flow as you in regards to installing 'rosetta'. Going to have a smart group grab 'arch type - arm64' and then have a policy apply on enrollment.

I usually have all my other default applications, FV2, some other scripts, all configured in a seperate single policy that i then scope out to the enrolled computer, then use Self Service to install it.

Are you running the rosetta script that someone provided by @txhaflaire on 11/19/2020 ?

or using file and processes with the command? /usr/sbin/softwareupdate --install-rosetta --agree-to-license

[rstasel]

@tcandela note, there's a bit of an issue with just "arch type = arm64". Apparently during enrollment, specifically recons during enrollment, arch type can sometimes come back as Intel (or maybe it comes back Null and jamf is assuming Intel?)

We had to create a second smart group that was "Processor Type -notlike Intel". Otherwise we'd occasionally see Config profiles for stuff like KEXTs (which we're excluding from Apple Silicon) try to install during enrollment, and fail.

YMMV of course.

[tcandela]

@rstasel would you rather then have the script run after enrollment? vs the smartgroup option?

[rstasel]

For rosetta2, I literally just run it on all enrollments. worst case, it fails on Intel machines.

Just saying if you go the smart group route, careful as you may miss some Apple Silicon machines during enrollment. =/

Jamf didn't provide much of an answer on whether this was a bug on their end, or Apple's. This falls under PI-009226.

[tcandela]

@rstasel then instead of smartgroup i'll probably have the script run on all enrollments. The problem i'm having is that enrollment invitations are not enrolling my macs into the SITE specified, so an enrollment policy will not work. Hopefully JAMF resolves this issue. (we have multiple SITES here)

I use to use the quickadd.pkg and that was never a problem enrolling into my SITE. But with Catalina the quickadd.pkg don't work. So i had to re-configure a bunch of 'enrollment' policies

do you have a single site or multiple sites for your JAMF environment?

!/bin/bash

arch=$(/usr/bin/arch)
if [ "$arch" == "arm64" ]; then echo "Apple Silicon - Installing Rosetta" /usr/sbin/softwareupdate --install-rosetta --agree-to-license
elif [ "$arch" == "i386" ]; then echo "Intel - Skipping Rosetta"
else echo "Unknown Architecture"
fi

[rstasel]

we have multiple sites within a single environment. but we're slowly merging into a single site (or maybe like, from 20 down to 3).

Quickadd doesn't really work on Big Sur, so we stopped using. Yeah, configuring enrollment polices for the site, or set one for Site None (Full Jamf) to target all machines on enrollment. That SHOULD work.

[tcandela]

@rstasel each time i use an enrollment invitation i have to hope it worked. It's probably worked 1 out of 30 times. Each time i have to then go in and assign it to my site. They get enrolled but not into any site. I haven't checked but you said i can create an enrollment policy IN MY SITE? and assign it to 'site none'? and the policy will apply?

[rstasel]

enrollment invites I haven't used much, so I'm not sure there. Given they removed the ability for config profiles to install via commandline in Big Sur, I'm not sure they'll work right anymore (but again, don't know, don't use them myself). We do non-ADE enrollments via web interface.

A policy that lives in "Full Jamf Pro" scoped to all computers, triggered on Enrollment, SHOULD fire for every machine, regardless of what site it goes into. So you could make that one JUST install Rosetta2, and then each site has it's own enrollment policy that does other stuff specific to that site.

[scottb]

@tcandela - are you creating site-specific enrollment accounts for user initiated enrollments? I've not had issues with that working...all Macs go into respective Sites.

[tcandela]

@scottb I go to 'enrollment invitations' and fill out the send to: address (and all the other information, subject, sent from), then I select the specific site to enroll into via the 'drop down list'.

I leave the message box that has the enrollment invitation link box unedited. I don't change anything. and then send the invitation off.

i access the email, click on the link to enroll, install the cert and mdm profile, and then enrollment completes. I look in my site and it's not there. I do a search and it's enrolled but with no site specified. I have to choose the site from the drop down list.

no idea what/why it doesn't work. Had a zoom meeting with JAMF and they had no real specific answer to why it's not working.

I have 2 accounts, ------ 1 account that is specific to the whole JAMF environment/sites and allows me to choose the site to enroll into when i create the enrollment invitation.
------ while the second account is just specific to my site and doesn't allow me to choose site to enroll into.

is this what you're talking about "are you creating site-specific enrollment accounts for user initiated enrollments?"

[scottb]

@tcandela - yes. only difference is that we don't have SMTP setup, so we email the links to users based on the site and it works every time. ¯_(ツ)_/¯

[Jason33]

I have Rosetta being deployed during all enrollments, just like @rstasel . And once any software updates/patches are released by Apple, I have Rosetta installed to Apple Silicon devices again. I'd read somewhere that patches in the past had been removing Rosetta.

[rstasel]

I think I heard they fixed that issue (removing it during updates), but yeah, still a good idea to just force it back. we have an EA for Rosetta installed, and just scoped a policy to it in case it somehow disappears. =/

[GabeShack]

@rstasel @Jason33 I just did an update from 11.3.1 to 11.4 and it required me to install rosetta again. Too bad we cant manage it like an app, and push updates to rosetta separately.

Gabe Shackney
Princeton Public Schools

[rstasel]

@gshackney I clicked like, but really, it's more of dislike. Wish Apple would stop doing that........ I swear one of the release notes for a Big Sur update said it was fixing the issue where it kept uninstalling Rosetta...

[tcandela]

@scottb where are you getting this link to individually email out to your people?