Use a script to install rosetta, and trigger it 'Before' other tasks in your provisioning policies. For example, this is our depNotify-based policy that's triggered by Enrollment. At the end (cut off from the screenshot) is our customized depNotify-starter script, running 'After' everything else.

Step 1 

In Sum, use the "*". Build your workflows to stagger using triggers. 

The M1 Policy is a Run Unix Command '

/usr/sbin/softwareupdate --install-rosetta --agree-to-license'

Your # 1 Policy is 

Look at my -event baseapps and then my trigger on the apps is baseapps. 

pkgutil --expand "InstallRosetta.pkg" "InstallRosetta"

pkgutil --flatten "InstallRosetta" "InstallRosetta.pkg"

Because you need rosetta on the machine to install pkg's

David, I think I'm doing the same thing as you but I can't get it to work. I have a smart group already created that will detect the M1 chip. In Composer I made a new install package that only has a preinstall script listed below. When I run the policy it shows that it installed but when I check the Mac it didn't. If I just run the the preinstall script locally it works.

I know I could just set this all up in the Policy itself but I need to have an installer package for our users that aren't in Jamf. What are your thoughts?

I have a Rosetta policy kicking off the install once Jamf Enrollment is complete. But it seems other polices try to kick off before Rosetta has downloaded and installed. Then they fail because Rosetta isn't completed yet. Is there a way to not let the next policy start until Rosetta is completely installed?

I saw you have an event trigger. Can you share what that may look like?

Name the policy so that it's alphabetically first. Generally you can add "001" or something similar to the beginning of the policy name. This will have it run before other policies. 

I created a policy that runs this script and then I put it into my policy array. It works every time.

Thank you that worked.

Any one have an issue with running a script to enable Rosetta 2 on Monterey?  

/usr/sbin/softwareupdate --install-rosetta --agree-to-license

I see the script failing on macbook pro 2021 with 12.01 installed. Works fine in big sur

We are able to install Rosetta 2 from a shell script. I set my proxy in the script first then the install of Rosetta 2 on a Monterey 12.0.1 MacBook Air. I haven't tried it on a Pro yet.

I ran into this issue not being able to install Rosetta 2 on Monterey. I have a new Mac and when I tried to run the "/usr/sbin/softwareupdate --install-rosetta --agree-to-license" command in terminal I get an prompt saying it's not available. Not sure what is going on. I reached out on the MacAdmin Slack channel and Oweban gave me a link that allowed me to download a Rosetta pkg: https://swcdn.apple.com/content/downloads/22/22/002-23588-A_TE78EA61ZT/20rnkfl4l6yqqeny3i7xz3mkvdo4s038sk/RosettaUpdateAuto.pkg
I've tied the package to my Prestage and will test it to see if it installs Rosetta 2 before the other software.

Thanks. When I look at installations in system information it showed it as being already installed.  Which is odd. My script to install Rosetta 2 checks for  /Library/Apple/System/Library/LaunchDaemons/com.apple.oahd.plist which is not longer there. (Seems 11.5 took this out?) So now i'm checking for /Library/Apple/System/Library/Receipts/com.apple.pkg.RosettaUpdateAuto.bom

@BCPeteo 

There were some reports in these forums previously that suggested that Apple macOS Big Sur updates e.g. 11.1 to 11.3 might remove/disable Rosetta2 such that after a macOS update you needed to reinstall Rosetta2.

It is due to this concern that I had decided that critical components like Anti-Virus software which still currently only work via Rosetta are not suitable for enterprise use. As a result we are dumping Sophos.

From your post and others it is not clear if Rosetta2 has become non-functional or whether it is merely that the LaunchDaemon has changed name or removed. Have you tried executing an Intel app to see if Rosetta2 is still functioning despite the missing LaunchDaemon?

If Rosetta2 is non-functional due to the lack of this LaunchDaemon then your script check still needs to look for the LaunchDaemon.

The original theory had been that a macOS upgrade removed Rosetta2 because a new matching update of Rosetta2 would need to be installed. It could however be Apple just deliberately making things difficult  - perhaps to encourage the move to native software. 

It maybe that merely replacing the LaunchDaemon and re-loading it might be sufficient. Comparing the LaunchDaemon after reinstalling Rosetta2 would be useful.

(I am still waiting for my MacBook Pro 14" to arrive so I can test this.)

Some installer packages when re-run will see the previous installations receipt and refuse to install because they presume it is already installed. Removing the previous receipt and then running the installer should then work. This could be added to your script.

@jelockwood and @BCPeteo I've come across this script that might have some additional ideas on things to check when looking to see if Rosetta is installed. I have not tested or done anything with this myself.
https://support.kandji.io/rosetta 

Thanks for the link. Looking at that script I see this:

# Rosetta Folder location
# Condition to check to see if the Rosetta folder exists. This check was added because the
# Rosetta2 service is already running in macOS versions 11.5 and greater without Rosseta2 actually
# being instaslled.
RosettaFolder="/Library/Apple/usr/share/rosetta"

So the service is already running even though its not installed!

Hey i saw a reply from someone that was very helpful wrt smart groups and i refreshed the page and now its gone, so i will reproduce  what he said in image form. the below works for setting the smart group. Spent way too much time trying to figure out why office wouldnt install today without remembering about stupid rosetta (which i could clearly see was the problem from jamf.log)... I only set up one mac every few months so now this should be fixed going forward with the smart group. Thanks guys.

#!/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

this approach appears to make the most sense imho. Can you please elaborate for me how you would go about creating a preStage pkg? Are you referring to creating a package that is just a script and running it during enrollment?

I got it to work just today with this command: 

sudo /usr/sbin/softwareupdate --install-rosetta --agree-to-license

14" MBP, M1 Pro, OS 12.1

I just did the Files and Processes payload in a policy, add that command to the payload, then ran sudo jamf policy -id etc and it worked for me. 

Credit to @Mac11 for the command towards the top of this post

@dmiguel , or Processor Type like Apple

It should do. Check out the 'Execution Order of Policies' section here:
https://docs.jamf.com/10.29.0/jamf-pro/administrator-guide/About_Policies.html

What settings did you use on your smart group to determine if a system is a M1? 

For my Smart Group I used this criteria:

Processor Type like Apple

Architecture Type is arm64

Hi Jeff,

After our devices are enrolled, I manually, (meaning its not part of the enrollment)  run a policy called  "Admin Base Apps Installs" that includes Adobe, Office, Zoom, Teams etc. and finally configures the firmware settings

In that same policy, I want to install Rosetta first, and put it at the top of the list, as install applications fail without Rosetta.

Question. In that same "Base Apps install" policy, will the Files and Process run first?  

Or do I create a separate policiy and some how link the two?

fyi I haven't removed the Run script yet shown in the pic so you can disregard it as it fails to run first. 

I'm 3 months into the apple world and running into some roadblocks.

Appreciate the help