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.
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/
<Removed>
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.
@btrav Do you use DEPNotify? Which version if?
@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.
@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
@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.
@rstasel would you rather then have the script run after enrollment? vs the smartgroup option?
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.
@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
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.
@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?
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.
@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.
@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?"
@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. ¯_(ツ)_/¯
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.
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. =/
@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
@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...
@scottb where are you getting this link to individually email out to your people?
So far so good with the package/script combo here. Thanks!
Funny, I thought that I had commented here already. Must have been another thread. As an FYI, the Launch Daemon (/Library/Apple/System/Library/LaunchDaemons/com.apple.oahd.plist) that a number of admins have been using to check against, is now installed on the OS out of the box. Just a heads up.
It's not elegant but name your policy starting with an asterisk (*). It should run before policies that are named starting with A-Z or 0-9.
Have you tested this and does it actually work? I would *love* to not have to reconfigure all of our myriad policies to accommodate for this issue.
Sure. So here's how I have everything work.
1. Smart Group with the criteria for Architecture Type is arm64
2. You will want to create two scripts. The first is simple script to install Rosetta
#!/bin/sh
/usr/sbin/softwareupdate --install-rosetta --agree-to-license
3. The second script is to trigger all the remainder policies using sudo jamf policy -event trigger unless you're using DEPNotify.
4. Next I created a policy that only runs with the smart group for M1 processors. The triggers are Enrollment and a Custom Event called install-rosetta (just in case I need to use it manually or via another script).
5. Then I created a second policy to run after Rosetta is installed which fires off the second script that runs the remainder of the policies. That one is only set to run via Custom Event start-enrollmentinstallers.
So far everything is working. I'm testing out DEPNotify which does change how this is done but for now, it's fine.
Wow, this is pretty freaking awesome. Thanks, for sharing this. I am going to give this a try. I'm curious how to execute was workflow like this utilizing DEPNotify. Fascinating!
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.