Automating OS Upgrade for Intels and M1's

[BBB_UMB]

Can someone give me an idea of the best way to automate OS Upgrade without requiring admin passwords to complete it? I've installed a bootstrap token onto my test machine and verified that it was distributed to my standard account but it still requires elevated rights to complete installs that were deployed via MDM.  

[falbrecht]

From what I understand you can update the OS on Intel devices by sending the remote command and they will update and restart without requiring user authentication. M1 updating is a little more trickier and I am still having trouble getting that down as well but one idea is you can make a script that creates an admin account, runs the update and reboots, and then removes the admin account afterwards.

[ChaseEndy]

Download the full installer and upload to your jamf pro instance and then we use this script that will run after the installer is downloaded onto the mac.

#!/bin/bash

# Pulls the current logged in user and their UID
currUser=$(ls -l /dev/console | awk '{print $3}')
currUserUID=$(id -u "$currUser")

fvPass=$(
# Prompts the user to input their FileVault password using Applescript. This password is used for a SecureToken into the startosinstall.
/bin/launchctl asuser "$currUserUID" sudo -iu "$currUser" /usr/bin/osascript <<APPLESCRIPT
set validatedPass to false
repeat while (validatedPass = false)
-- Prompt the user to enter their filevault password
display dialog "Enter your macOS password to start the macOS upgrade" with icon file "System:Library:CoreServices:CoreTypes.bundle:Contents:Resources:FileVaultIcon.icns" default answer "" buttons {"Continue"} with text and hidden answer default button "Continue"
set fvPass to (text returned of result)
display dialog "Re-enter your macOS password to verify it was entered correctly" with text and hidden answer buttons {"Continue"} with icon file "System:Library:CoreServices:CoreTypes.bundle:Contents:Resources:FileVaultIcon.icns" default answer "" default button "Continue"
if text returned of result is equal to fvPass then
set validatedPass to true
fvPass
else
display dialog "The passwords you have entered do not match. Please enter matching passwords." with title "FileVault Password Validation Failed" buttons {"Re-Enter Password"} default button "Re-Enter Password" with icon file messageIcon
end if
end repeat
APPLESCRIPT
)

echo $fvPass | /Applications/Install\ macOS\ Monterey.app/Contents/Resources/startosinstall --agreetolicense --forcequitapps --nointeraction --user $currUser --stdinpass

exit 0

[ChaseEndy]

Here’s an awesome thread to read as well:

https://community.jamf.com/t5/jamf-pro/macos-installer-script-not-working-for-apple-silicon-m1-macbo...

[ajamfadmin1810]

This is how i have it setup for upgrades to  Monterey. 

1. Setup a smart computer group where laptops are one OS prior(big sur), not encrypting and with more than 90GB of HD space) Name it "Eligible - Monterey Installer Cache"

2. Download the installer (monterey) from MrMacintosh its already pkgd up, then upload this pkg to JAMF

3. Create a policy that caches the installer pkg and scope it to the smart group that you created prior in step 1

        3a. I have mine triggering at check in for the cache of the Monterey installer silently

4. Create a second policy and name it "MacOS installer" this will just install the cached package

5. Create a second smart group and call it "Installer cached(Monterey)" criteria is "package cached" is installer_pkg_name

6. Scope the "MacOsInstaller" policy you created in step 4 to the smart group you created in step 5 and make it available via Self Service

Now only users with the installer package cached will see the option to upgrade to Monterey. I also have a jamfhelper screen pop up when the policy is run but that isn't necessarily required

I referenced this site, its for Big Sur but same process for Monterey

https://hcsonline.com/images/PDFs/Upgrade_Big_Sur_Jamf.pdf

[bcrockett]

For the cached monetary smart group, I add an additional parameter of battery is greater than 54. That way the policy only triggers on clients with a high enough battery level that it will not fail due to the battery being too low.