macOS Ventura upgrade process nightmares

metalfoot77
Contributor II

I am currently working on a process to upgrade all of our fleet (50% Intel, 50% M1 roughly) to Ventura.  As with every upgrade, I am losing my mind finding a good process that works.  All of our users are standard accounts on their devices and Filevault is mandatory.  

I have a policy that temporarily elevates user to Admin (script), installs nudge suite (pkg), nudge branding (pkg), mist-cli (pkg) and then runs the Mist command (script) to download the Ventura installer and it places it in /Users/Shared/Mist with the normal “Install macOS Ventura.app” format.

I would like to use front end this process with Nudge to make users aware of the upgrade and allow deferrals until they click Upgrade.  I have Nudge configured and working and it invokes a policy from Self Service that kicks off the upgrade script.

Here is where I am losing it, when it comes time to issue the upgrade command, it doesn’t work, at least on M1 macs.  I have tried using the Erase-Install app to do the caching of the installer and run upgrade but that doesn’t work.  I’ve tried having Nudge do the caching of the installer and upgrade and that also fails.

Each time I am running into issues trying to get a prompt to happen for the current volume owner so that the install can, you know, actually run.  

Does anyone have a working process for Intel and M1 macs with standard users (non-admin) to upgrade in-place to Ventura?  At this point, I’m open to any ideas or tools or whatever.  Erase-install seems like the answer but I am having a bear of a time getting it all to work and make it pretty for the end user.

14 REPLIES 14

bwoods
Valued Contributor

Hi @metalfoot77 , I'm currently just waiting for Apple to allow delta upgrades so that I can just use the default Nudge functionality. It doesn't require the user to be admin. Anyway, I think I can help with the process that you're using.

I did some extensive testing on M1 upgrades for a majority of the year to find the best upgrade path and concluded that Nudge was the answer. From what I can see, you basically need to place an installer with Jamf  and make Nudge run the startosinstall command. Simple!

1. Contrary to popular belief, the startosinstall command does not require the user to be admin, they just need to be the volume owner. You can track volume ownership with an extension attribute

2. When running the startosinstall command on an M1 device, the user will need to be prompted for a password. This can be accomplished with some Apple Script wrapped in a bash function. See my example below ( Just change the path to the path of a Ventura installer.

#!/bin/bash

####Variables

# Determine the current user
currentUser=$( scutil <<< "show State:/Users/ConsoleUser" | awk '/Name :/ && ! /loginwindow/ { print $3 }' )

# Determine the current user id
currentUID=$(id -u "$currentUser")

###Functions

Password(){
	# Prompts the user to input their FileVault password using Applescript. This password is used for a SecureToken into the startosinstall.
	/bin/launchctl asuser "$currentUID" sudo -iu "$currentUser" /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 "System:Library:CoreServices:CoreTypes.bundle:Contents:Resources:FileVaultIcon.icns"
	end if
	end repeat
APPLESCRIPT
}

executeUpdate(){
	Password | /Applications/Install\ macOS\ Ventura.app/Contents/Resources/startosinstall --agreetolicense --forcequitapps --nointeraction --user $currentUser --stdinpass
}

###Script
executeUpdate

exit 0		## Success
exit 1		## Failure

3. Just upload the script above and make a custom policy using it.

4. Make Nudge run the custom policy when the user clicks the update button. They'll be prompted for the password and once they provide it, the command will run. 

As far as deploying installers, I just keep it old school. I download the installer from Mr. Macintosh and deploy the .pkg to all machines that require the upgrade.

 

 

 

AJPinto
Valued Contributor II

If I am not mistaken you still need admin access to run macOS Upgrades (12 > 13). Apple just removed the admin check and replaced it for a secure token (volume ownership) check for OS Updates (12.6 > 12.6.1).

 

I have never cared for Nudge, it just reminds the user to do the thing and cannot actually do the thing for the user (thanks Apple). I use JAMF Restrictions and JAMF Helper. JAMFs MDM framework and JAMF helper are built in and enables you to be a lot more forceful for users who do not comply than Nudge can. Honestly, there should not be a reason for Nudge to exist. Apple should simply just do better with OS updates, but here we are.

You are mistaken.  macOS 12.3 and above do not require an admin for major updates.  There was a bug in how this was implemented, so Apple paused that non-admin major update channel on Supervised machines for at least 30 days into Ventura releasing.
https://support.apple.com/en-us/HT213471 

AJPinto
Valued Contributor II

There are many works arounds, which are not really viable on Apple Silicon. My recommendation is just doing it the way Apple wants you to and submit tons of feedback complaining.

 

Use JAMF Mass Action > Sent remote command > Update OS version... > Target Version > and one of the two options below.

  • Latest version based on device eligibility > check Include major updates, if available
  • Specific version > 13.0.1

This works about 70-80% of the time, and there is no apple support work flow beyond this aside of manually installing the updates. 

 

SUBMIT FEEDBACK!!!! Product Feedback - Apple

Thanks for the follow-up.  I have experimented with MDM commands to force updates and my success rate is about 25%.  The other problem with this is that I want the user to be in control of when they upgrade, not just a blast of update to them.  I know this isn't on you, I'm just complaining about Apple in general and how this is just not user friendly to update folks.  I will pound on that feedback button, thanks @AJPinto !

bwoods
Valued Contributor

Same here, the MDM commands aren't reliable enough to meet certain deadlines. The other issue is the lack of a progress bar after the command is initiated. I was able to get a pretty good workflow going with the API and Jamf Helper but it was just too unreliable. 

AJPinto
Valued Contributor II

@bwoods @metalfoot77 Oh, I totally agree. The MDM commands are hot garbage, but it's the only solution that Apple provides. I am all about crafty work arounds, but if we are not complaining (feedback) on apples horrible solutions constantly they wont do anything about them. Heck, eventually they will break the work arounds we are using. Considering most of these software update MDM commands have been around 10 years, it's amazing how bad they are.

 

From what I am hearing apple has finally hired a team to work on the software update binary (not MDM, the actual binary) workflow. It's beyond me why they did not have a team dedicated to this to begin with. Maybe we will see something in a couple of years but I am not holding my breath.

 

Most people seem to have about a 70% success rate with OS updates from MDM command. So many things will prevent OS updates from installing even if using the force install option beyond the random issues with OS updates. It is bonkers, and totally unacceptable. 

 

In apples mind, if you want users to have agency over OS updates. You need to get your hand out of the cookie jar and not have the person go JAMF SS, but rather to System Preferences > General Software Update. How Apple handles secure tokens is another conversation for another time... ... ....

bwoods
Valued Contributor

Macin' ain't easy. Keep fighting the good fight. 

Can we get this on a t-shirt?

bwoods
Valued Contributor

😂

mickgrant
Contributor II

I'm Using Jamf to Cache the full installer for Ventura which helps speed up the process. but even if for some reason the installer wasn't cached erase-install.sh is still setup to download it

Nudge points to a self-service policy that does 3 things, it installs the cached Ventura installer placing it in /Applications and installs erase-install. Finally activates a script

#!/bin/sh
# Unload Nudge Launch Agent and Begin MacOS upgrade script
# Written by Mick Grant - mgrant1@arm.catholic.edu.au

# find active user code supplied by Armin Briegel - Scripting OS X
# sample code for this blog post
# https://scriptingosx.com/2020/08/running-a-command-as-another-user/

# variable and function declarations

export PATH=/usr/bin:/bin:/usr/sbin:/sbin

# get the currently logged in user
currentUser=$( echo "show State:/Users/ConsoleUser" | scutil | awk '/Name :/ { print $3 }' )

# global check if there is a user logged in
if [ -z "$currentUser" -o "$currentUser" = "loginwindow" ]; then
  echo "no user logged in, cannot proceed"
  exit 1
fi
# now we know a user is logged in

# get the current user's UID
uid=$(id -u "$currentUser")

# convenience function to run a command as the current user
# usage:
#   runAsUser command arguments...
runAsUser() {  
  if [ "$currentUser" != "loginwindow" ]; then
    launchctl asuser "$uid" sudo -u "$currentUser" "$@"
  else
    echo "no user logged in"
    # uncomment the exit command
    # to make the function exit with an error when no user is logged in
    # exit 1
  fi
}

# main code starts here

#kill the running nudge process
killall Nudge
echo "killing the running nudge window"

# unload the com.github.macadmins.nudge launch agent
runAsUser launchctl unload /Library/LaunchAgents/com.github.macadmins.Nudge.plist
echo "Nudge launch agent has been unloaded"

#launch erase-install 
echo "Erase-install script active, installing macOS - "$4"."
/Library/Management/erase-install/erase-install.sh --reinstall --current-user --check-power --version=$4 --cleanup-after-use

# reload the com.github.macadmins.nudge launch agent if Erase-install script fails, so that nudge will keep activating
runAsUser launchctl load /Library/LaunchAgents/com.github.macadmins.Nudge.plist
echo "Nudge launch agent has been loaded. Your not getting away from me that easily"

The Script unloads the nudge launch agent because I found that while performing installs with erase-install if the install took too long,  the user would get nudged again, which was not ideal. And if the erase-install script fails (they didn't connect to power) then the nudge launch agent gets reactivated, so they keep getting nudged

Awesome, thanks @mickgrant!. I hadn't even given much thought to what to do with Nudge after the upgrade is kicked off.  I will give this process a go as well.  👍

Hi @mickgrant , quick question, what do you have as your variable for $4 when running erase-install?  You have it set as --version=$4.  Thanks!

Oh, sorry, I didn't mention that; it's just a script parameter that I set in the Jamf script options.
it's set to MacOS Version (eg - 12.6.1). 
That way I don't have to edit the script commands in the future just fill in the script option in my policy and it passes the info into the script