Unable to run MacOS Ventura update on M1 Macs only

[aaronedmonton]

We have about 50/50 M1 vs Intel chip Macbooks.

We are using Jamf Connect as well (not sure if relevant)

We have a standard Admin account created and loaded for every computer during prestage enrollment.

We are not able to run the MacOS Ventura Installer on the M1 macs because it does accept the Admin credentials provided. These same Admin credentials are working for installing apps, etc. The update does work if you switch to the mentioned Admin account on the computer and then run the update.

The update has none of these issues for the Intel macs. I can run the update from the user's account using the same Admin credentials.

Anyone know why the M1 would not let us run this update from the user's standard account, even providing the correct Admin credentials?

[bcrockett · Accepted solution]

Ya, this film showing my configuration to force stander accounts to update proves it is possible to update from Monterey to Ventura on a stander user's account. 

They can self-initiate as well with this configuration. 

So far I have had over 100 m1 client computers in the standard user account category update to Ventura successfully. 

Hope that helps. ~ B

[AtillaTheC]

we use https://github.com/grahampugh/erase-install/wiki for our in place upgrades. Essentially that admin account would not have the correct secure token for an OS upgrade.

[bcrockett]

I have the erase install workflow set up and it works like a charm on M1 when users self-initiate. 

Users read this document to learn how to update: 

https://docs.google.com/document/d/1sC0BnvzptHWkEzscmbWnugUrKnBoxzDVlj0bnEeJhcw/edit#

Then run the policy via self-service. 

#####

However, I am wondering if there is a good way to Prompt users to Install an item made available in Self Service such as the erase-install (update) policy?

Basically, nudge but instead of promoting the user to update from system preferences which they can not do for major updates because they do not have admin rights. Instead, prompt users to run the erase-install (update) policy. Which then prompts them for their password from a token account and allows the update to run. 

[AtillaTheC]

https://github.com/bartreardon/swiftDialog

[bcrockett]

@AtillaTheC 

Thanks for sharing that resource! 

I used it to solve my problem in the following way. 

1. I downloaded the .pkg from the swiftDialog repo on git hub. Then uploaded it to the JSS

2. I copied and pasted the example Jamf Scripts into my jss. 

Add pkg

3. I created a policy that:

a. installs the swiftDialog box on the client's computer

b. Runs the dialog script with the following parameters:

script paramaters

The client sees a dialog box that says update now. They click update and the 

a terminal command is executed which runs that erases install workflow for updating the computer.

This prompts the M1 standard users without admin rights to enter their login password for their token volume and the update starts! 

It is not as clean as nudge but functional. 

Victory! ~ B

[aaronedmonton]

Apple Business support told me that it's not possible to update to Ventura from the Standard account and that we would have to switch to the Admin account to run the update for these M1 devices...

[bcrockett · Accepted solution]

Ya, this film showing my configuration to force stander accounts to update proves it is possible to update from Monterey to Ventura on a stander user's account. 

They can self-initiate as well with this configuration. 

So far I have had over 100 m1 client computers in the standard user account category update to Ventura successfully. 

Hope that helps. ~ B

[AtillaTheC · Accepted solution]

Correct, using the erase-install github will work as long as the user account has a secure token 

https://github.com/grahampugh/erase-install/wiki

[aaronedmonton]

Erase/install requires the Mac to be backed up in Time Machine correct?

[bcrockett]

Good question.

Where did you learn about that requirement? 

[AtillaTheC]

no, you can use the --reinstall command instead of the --erase one. See the JAMF wiki in the repo

[aaronedmonton]

This worked for me. Thank you much!

[sharif_khan]

Hi @bcrockett I have a qs regarding the packages you download and upload to Jamf.

1. From where you download erase-install-depnotify-271.pkg. If I upload the .pkg still do I have to upload the Script: erase-install.sh

2. From where you download dialog-2.0-3810.pkg

The link you shared I see only script no .pkg. So please help me on that.

[bcrockett]

That information is in the description section of the film.

The software is downloaded from github. 

##### Links referenced above and in the film

1. Erase-install https://github.com/grahampugh/erase-i...

2. swiftDialoog https://github.com/bartreardon/swiftD...

3. Nudge https://github.com/macadmins/nudge  

[bcrockett]

@sharif_khan It sounds like you are new to using GitHub. No worries we all started somewhere and it is a bit confusing how to download the .pkgs. 

Check out this film of the workflow you can use to download .pkg from erase install

hope that helps! 

[sharif_khan]

@bcrockett Thanks for the workflow. i download the package and upload to Jamf distribution and create policy with that erase-install-29.1.pkg and added /Library/Management/erase-install/erase-install.sh --reinstall --confirm to File & process. then execute that policy as self-service. That started without Ventura icon just an gear icon and I had to hit OK button and then that started after few min after click confirm button start upgrade with Ventura icon. So I guess this policy I have to involve user to upgrade macOS. Is there any way I can make that as required instead of available? if not then please let me know why not?

[bcrockett]

@sharif_khan you are asking the right questions. 

However, if you looking for more direct support from me in putting together this workflow in your environment we would need to do an online session to get this done quickly. 

Feel free to direct message me if you are interested in consulting further on this. 

[sharif_khan]

@bcrockett I able to put together as make available with the package and self-service install by user but I think if we can make that as a required install like without involve end user then that will be great. May be I couldn't make you understand. Sorry for that. But I am not looking for dirrect support from you. I am talking about this solution on this forum. I belive most of IT admin should like that update process without involve user. So I asked that is there any option to make this install package from self-initiate to Automate from Jamf.

[bcrockett]

If your goal is to update without user interaction super
<>is the software with the best chance at
making that possible right now IMO.

I plan to make some films about my lab test with this software soon. I have
still not been able to use it to update standard users without user
interaction however, that could be related to a mistake in my own
configuration.

That said check out the wiki <>
for S.U.P.E.R.M.A.N. by Kevin M. White it is an exciting contribution to
the mac admin community that combines all the tools for updating macOS
computers with notifications in a single configuration.

--
Thanks,



Buck Crockett
Director of Technology
6835 Trinidad Drive | San Jose, CA 95120 | USA
T 408 997-0424 x274
C 303-809-1430
bcrockett@almadencountryday.org
almadencountrydayschool.org <>

FOLLOW. CONNECT. SHARE.
Facebook <> | LinkedIn
<> | Twitter
<> | Instagram
<>

*LOVING THE NOW. READY FOR NEXT.*

*Send ALL tech requests to:*helpdesk@almadencountryday.org

[sharif_khan]

I met with Kevin M at JNUC 2022 and attend to his session. And also talked with him regarding this update process. He told me that will work only for update I guess not upgrade as I recall, I could be wrong.

[bravichandran]

I am unable to get password authorization. while doing ventura update with following script via self service

#!/bin/bash
softwareupdate --list-full-installers | grep 'macOS' | awk '{print ++count " " $0}'
softwareupdate --list-full-installers
softwareupdate --fetch-full-installer
softwareupdate --fetch-full-installer --full-installer-version 13.0.1
echo $pass | '/Applications/Install macOS Ventura.app/Contents/Resources/startosinstall' --user $admin --stdinpass --agreetolicense --nointeraction --forcequitapp

Install finished successfully Error: failed to authorize for installation. Provide a password with --stdinpass or --passprompt. By using the agreetolicense option, you are agreeing that you have run this tool with the license only option and have read and agreed to the terms. If you do not agree, press CTRL-C and cancel this process immediately.

[AtillaTheC]

If you are really dead-set against using the eraseinstall script thats known to work you can try to adapt this old script I used for Monterey.

Honestly tho, erase-install script is the best surefire way to get this done. 

#!/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"} default button "Continue" with text and hidden answer
	set fvPass to (text returned of result)
	display dialog "Re-enter your macOS password to verify it was entered correctly" buttons {"Continue"} with icon file "System:Library:CoreServices:CoreTypes.bundle:Contents:Resources:FileVaultIcon.icns" default answer "" default button "Continue" with text and hidden answer
	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
)
##Heading to be used for jamfHelper

heading="Please wait as we prepare your computer for macOS Monterey..."

##Title to be used for jamfHelper

description="

This process will take approximately 20-30 minutes.

Once completed your computer will reboot and begin the upgrade which can take an additional 15-20 minutes."

##Icon to be used for jamfHelper

icon=/Applications/Install\ macOS\ Monterey.app/Contents/Resources/InstallAssistant.icns

##Launch jamfHelper

/Library/Application\ Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper -windowType fs -title "" -icon "$icon" -heading "$heading" -description "$description" &

jamfHelperPID=$!

##Start macOS Upgrade

echo $fvPass | /Applications/Install\ macOS\ Monterey.app/Contents/Resources/startosinstall --agreetolicense --forcequitapps --nointeraction --user $currUser --stdinpass --pidtosignal $jamfHelperPID >> /var/log/startosinstall.log 2>&1 &

exit 0

[bcrockett]

"failed to authorize for installation"

did you adjust the script to allow for authorization from both an admin account and volume owner? 

[bravichandran]

I believe no. can you please guide me how to achieve this

[bcrockett]

I can try. Can you write out your current configuration with annotated screenshots that show the setting in your JSS? 

[sharif_khan]

This is the method I use to update any macOS update or upgrade

echo $pass | '/Applications/Install macOS Ventura.app/Contents/Resources/startosinstall' --user $admin --stdinpass --agreetolicense --nointeraction --forcequitapp

But before that I deploy the macOS installer.app as .dmg which I package via composer to avoid every endpoint to reach apple server to Download the installer. Then deploy to endpoint with another policy which will deploy the installer to /Applications folder. Then use another policy with the following command

echo $pass | '/Applications/Install macOS Ventura.app/Contents/Resources/startosinstall' --user $admin --stdinpass --agreetolicense --nointeraction --forcequitapp

That worked like charm for me any machine (M1/Intel) for admin/nonadmin user.

[bravichandran]

@sharif_khan can you please elaborate the steps in detail to try in my environmet

[bravichandran]

@sharif_khan can you please elaborate the steps in detail. so that i can try in my environment

[sharif_khan]

1. Download new version of macOS on my test machine whihc download to my /Applications folder as instaler.app. for example I am trying to update macOS Ventura. Then download latest version of macOS Ventura and that will cached to my machine Install macOS Ventura.app

2. Package that installer as .dmg via composer

3. Upload to Jamf distribution point

4. Create a policy to deploy installer to client machine as recurring check-in with Inventory update payload

5. Create a smart group with that application (Install macOS Ventura.app) presence

6. Create another policy with command: echo 'local admin password' | '/Applications/Install macOS Ventura.app/Contents/Resources/startosinstall' --agreetolicense --forcequitapps --nointeraction --user localAdminuser --stdinpass      Note: User single quite ' ' for password and no qoute for username 

7. Add restart payload and Inventory update payload.

I hope that help. I had to push another Inventory update to endpoints to get update macOS update information to Jamf from endpoints.

[bcrockett]

I deployed Super script with a policy to Apple Silicon computers with the following parameters:

Super can automate updates by utilizing an account with a token volume to start the process.

Thus, in my test environment, I created every account possible to give the scrip all options for success these include:

a. a local accout

b. a admin accout

b. and a jamf - admin account though the API process

When I trigger the script from the test computer the client still must enter their username and password for it to work. 

After they enter their username and password the policy log looks is as follows:

#######

Script result: tee: /Library/Management/super/super.log: No such file or directory

Tue Mar 21 13:47:28 testMac S.U.P.E.R.M.A.N.[1704]: **** S.U.P.E.R.M.A.N. 3.0b8 INSTALLATION ****

Tue Mar 21 13:47:28 testMac S.U.P.E.R.M.A.N.[1704]: Installation: Made working folder: /Library/Management/super

Tue Mar 21 13:47:28 testMac S.U.P.E.R.M.A.N.[1704]: Installation: Copying file: /Library/Management/super/super

Tue Mar 21 13:47:28 testMac S.U.P.E.R.M.A.N.[1704]: Installation: Creating default path link: /usr/local/bin/super

Tue Mar 21 13:47:28 testMac S.U.P.E.R.M.A.N.[1704]: Installation: Creating file: /Library/Management/super/super-starter

Tue Mar 21 13:47:28 testMac S.U.P.E.R.M.A.N.[1704]: Installation: Setting permissions in: /Library/Management/super

Tue Mar 21 13:47:28 testMac S.U.P.E.R.M.A.N.[1704]: **** S.U.P.E.R.M.A.N. 3.0b8 STARTUP ****

Tue Mar 21 13:47:28 testMac S.U.P.E.R.M.A.N.[1704]: Startup: Deleting all local non-account preferences.

Tue Mar 21 13:47:28 testMac S.U.P.E.R.M.A.N.[1704]: Status: Restarting automatically set zero day date.

Tue Mar 21 13:47:28 testMac S.U.P.E.R.M.A.N.[1704]: Status: Restarting maximum deferral counters.

Tue Mar 21 13:47:29 testMac S.U.P.E.R.M.A.N.[1704]: Status: Current GUI user is testAdmin with a UID of 501.

Tue Mar 21 13:47:29 testMac S.U.P.E.R.M.A.N.[1704]: Startup: No custom display icon found, copying default icon from: /System/Library/PrivateFrameworks/SoftwareUpdate.framework/Versions/A/Resources/SoftwareUpdate.icns

Tue Mar 21 13:47:29 testMac S.U.P.E.R.M.A.N.[1704]: Startup: Bootstrap token escrow validated.

Tue Mar 21 13:47:33 testMac S.U.P.E.R.M.A.N.[1704]: Startup: Saving new credentials for local account "testAdmin"...

Tue Mar 21 13:47:33 testMac S.U.P.E.R.M.A.N.[1704]: Startup: Validated saved credentials for local account "testAdmin".

Tue Mar 21 13:47:33 testMac S.U.P.E.R.M.A.N.[1704]: Startup: Saving new credentials for super service account "super"...

Tue Mar 21 13:47:33 testMac S.U.P.E.R.M.A.N.[1704]: Startup: Validated saved credentials for new super service account "super".

Tue Mar 21 13:47:33 testMac S.U.P.E.R.M.A.N.[1704]: Startup: Deleting existing super service account "super" in preparation for new account.

Tue Mar 21 13:47:33 testMac S.U.P.E.R.M.A.N.[1704]: Startup: Creating new super service account "super" with full name "Super Update Service" and UID 504...

Tue Mar 21 13:47:38 testMac S.U.P.E.R.M.A.N.[1704]: Startup: Validated the creation of new super service account "super".

Tue Mar 21 13:47:38 testMac S.U.P.E.R.M.A.N.[1704]: Startup: Saving new credentials for Jamf Pro API account "superapi"...

Tue Mar 21 13:47:38 testMac S.U.P.E.R.M.A.N.[1704]: Startup: Validated saved credentials for Jamf Pro API account "superapi".

Tue Mar 21 13:47:38 testMac S.U.P.E.R.M.A.N.[1704]: Startup: Apple Silicon Mac computer running macOS 13.2-22D49.

Tue Mar 21 13:47:38 testMac S.U.P.E.R.M.A.N.[1704]: Startup: Last macOS startup was Tue Mar 21 13:44.

Tue Mar 21 13:47:38 testMac S.U.P.E.R.M.A.N.[1704]: Startup: macOS update/upgrade workflows authenticated via local account.

Tue Mar 21 13:47:39 testMac S.U.P.E.R.M.A.N.[1704]: Startup: Attempting to download and install IBM Notifier.app...

Tue Mar 21 13:47:40 testMac S.U.P.E.R.M.A.N.[1704]: Startup: Found that Jamf is installing or is the parent process, restarting with new LaunchDaemon...

Tue Mar 21 13:47:41 testMac S.U.P.E.R.M.A.N.[1704]: Exit: LaunchDaemon com.macjutsu.super.plist is scheduled to start right now.

Tue Mar 21 13:47:41 testMac S.U.P.E.R.M.A.N.[1704]: **** S.U.P.E.R.M.A.N. 3.0b8 EXIT ****

############

That is not great detail. I will record a screencast with more detail soon. 

The short of it is that I am not sure how to configure the script so that the stander user does not have to enter their token volume credentials for the update to happen. 

Perhaps I am given it to many options by allowing it to use;

an existing local account, super service account, and a custom local super service account. 

https://github.com/Macjutsu/super/wiki/Local-Update-Credentials

Perhaps I will try testing with one account type at a time and see if that helps me identify one that will work to enforce software updates on Mac computers with apple silicon without additional update credentials. 

 

[bravichandran]

Hi, I have used erase-installer 27.1 package and erase-installer-launcher script downloaded from github. passed the following arguments. as per screen shot pasted below with user name and password of admin.

But getting error 'this account cannot be used for mac os reinstall' tried with another local admin as well. same result. can you please anyone suggest to bypass this. i want to upgrade os without asking admin password for end users from self service who are all having standard user accounts on the devices for login

[AtillaTheC]

the first account created on the machine, likely the end user, would have the proper privs, regardless of admin, to us their user/password. 

[bcrockett]

Write out the full sequence of your test configuration step by step. The bug in your configuration is in one part of the sequence of operations. However, if you do not write them out, I can not review and help debug them effectively. 

[bravichandran]

Hi,

I have tried with two scenarios. 

1. with simple script attached to the policy - scoped to test devices

script used: ''#!/bin/bash softwareupdate --list-full-installers | grep 'macOS' | awk '{print ++count " " $0}' softwareupdate --list-full-installers softwareupdate --fetch-full-installer softwareupdate --fetch-full-installer --full-installer-version 13.0.1 echo $Pass | '/Applications/Install macOS Ventura.app/Contents/Resources/startosinstall' --user $admin --stdinpass --agreetolicense --nointeraction --forcequitapps Result: Install finished successfully Error: failed to authorize for installation. Provide a password with --stdinpass or --passprompt. By using the agreetolicense option, you are agreeing that you have run this tool with the license only option and have read and agreed to the terms. If you do not agree, press CTRL-C and cancel this process immediately. /Library/Application Support/JAMF/tmp/MacOSUpgrade.sh test 2: line 7: syntax error near unexpected token `|'

2. Tried with erase-installer packgae 27.1 depnotify and erase-installer-laucher.sh script with the following argument parameters (screenshot pasted)

Result: 'This account can not be user for reinstall mac os' error screen

[bravichandran]

Also tried with erase installer package with policy and the following execute command in files and processes tab

[bravichandran]

hope i have provided the informations required. if you need any additional info please revert. i can check and provide

[bcrockett]

Let's try a different approach. No script this time. 

Clone the workflow in this film on your test device. Except trigger it from self-service. 

Let me know if that works. 

[bravichandran]

using jamf pro 10.42.1 and testing in M1 mac mini device

[bcrockett]

@bravichandran I created some new resources to try and help you automate the process of implementing the major update from macOS Monterey to Ventura:

1.  Configure erase - install to trigger the update from self-service using this workflow.    Once that is done email users and let them know they can and should start updating...

2. Next you can use a simple pop-up box that tells the user they must update which has an action button that when pressed will - triggers the self-service policy above. Link to this workflow here.  Once that is in production for two weeks or so it should work for ~50-70% of your users. *make sure to inventory update often for these non-updated users so they are excluded from the smart group of computers that have not been updated. 

3. For the last ~ 30% configure nudge to prompt the user to update. Make sure, it also triggers the policy step one. This is the link to the workflow.   ( this demo config is ugly however, it is functional)

[bravichandran]

Hi, I have followed that video link and tried with one of my test machine. its started the update process after 1 hr but the os not updated still the device in monterey. I have downloaded the earse installer depnitofy package and created a policy after that downloaded the dialog box package and script as mentioned the video link and job id mentioned.. all started well with dialog box and its accepted the current login standard user name and password. update process started but after reboot its again showing monterey only