@dgreening In all fairness, Apple has changed the upgrade utility a few times. That being said, Jamf should be well aware of these changes in advance, considering their supposed partnership with Apple.

Second what @seann said!!! We should not have to use bubble gum and bailing wire to get this working.

Anyone got this working with the 10.12.6 installer?

@Kyuubi Gotten what working? There's a few methods/scripts that have been proposed that from what I can tell continue to work with 10.12.6 assuming they've been maintained for the changes that Apple made in 10.12.4.

Sorry @bpavlov I didn't read all the posts before i posted. I was thinking that people were still using the old way of stripping the installOSX from the installer.app instead of using the OSInstaller.app. I'll go back to reading now.

@Rosko
I have a question. I am looking to have the machine immediately run a recon command after it reboots after the upgrade. Is there a way to trigger this by injecting a line in the post install script? Or in the launchDaemon?
Also it seems the version check is broken so I had to hash out all the lines of code performing the check and re download of the installer. Otherwise script is working great. I just need it to update inventory and run a few other policies on the 1st boot after it upgrades (or have them run on first login after that, but since it doesn't know it has 10.12.6 yet it makes it hard to find a good scope).
Gabe Shackney
Princeton Public Schools

@gshackney I'm partial to this method ;-)

Deploying an OS X Upgrade: Recon at Reboot script

@gshackney It would have to be a launchDaemon that gets deployed in order to do a post-reboot recon. And @dan.snelson 's script looks good. The only thing I might do is instead of waiting 300 seconds, use the jamf checkJSSConenection verb to check if the machine is able to establish a connection to the JSS or not. If not, have it wait another 3-5 seconds.

Also, @dgreening, @seann, @WUSLS, @Kyuubi, @bpavlov and anyone else interested in native (Jamf) in-place upgrades, check out the beta of Jamf Pro v9.101. Also, if you are using VPP, you can deploy the macOS Installer that way as well, however you are not able to pre-cache it using this method so a caching server is highly recommended for mass-deployments.

@dan.snelson @Rosko
Thanks!
I'll play with this piece. I didn't scan through it too much, does the daemon delete itself after running? Also does it skip running until after the os upgrade reboots into itself once? I basically want to trigger the recon then once the JSS sees that it has run the upgrade policy and now has the new os, then I will have some policies run based on that.
Gabe Shackney
Princeton Public Schools

@gshackney Yes, it self-destructs:

# Delete launchd plist

ScriptLog "* Delete $plistLabel.plist ..."

/bin/rm -fv /Library/LaunchDaemons/$plistLabel.plist



# Delete script

ScriptLog "* Delete script ..."

/bin/rm -fv /path/to/client-side/scripts/reconAtReboot.sh

Here's the way we're deploying the script:

Initial results look good for macOS High Sierra 10.13 Beta (17A360a):

/Applications/Install macOS High Sierra Beta.app/Contents/Resources/startosinstall --applicationpath "/Applications/Install macOS High Sierra Beta.app" --converttoapfs YES --rebootdelay 30 --nointeraction

I executed this script: https://github.com/kc9wwh/macOSUpgrade/blob/master/macOS10.12Upgrade.sh

after confirming macbook is plugged in to power and has enough disk space, i'm getting this screen:

'please wait as we prepare your computer for macos sierra....

this process will take ~5-10mins. once completed your computer will reboot and begin the upgrade.'

it's been on the same screen > 30mins and has not rebooted. did something go wrong? am i missing something?

thanks for any assistance

@dan.snelson You don't need --converttoapfs YES as it will automatically convert if the hardware supports it. That's been my experience in VMs anyways. Has your testing had different results?

Hi All,
Does anybody have suggestions on modifying Josh's script (https://github.com/kc9wwh/macOSUpgrade/blob/master/macOSUpgrade.sh) to force a reboot? The soft reboot just isn't cutting it for us - seems there's always an app open and then the reboot just doesn't happen. Timing-wise I'm just not sure where to drop the reboot now command. Any ideas?

Thanks,
Matt

Try adding shutdown -r now in the line after it finishes running the startosinstall command.

@Rosko I've been trying to get the script to run and keep getting this error:

Launching jamfHelper as FullScreen...

Launching startosinstall...

Error: __28-[OSISClient targetForPath:]_block_invoke, Couldn’t communicate with a helper application.

Error: could not find target...

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.

I'm trying to run it as a recurring check-in policy instead of a Self Service policy, but it gets the same error in Self Service, too. I'm trying this on 10.9.5. Any thoughts?

Hello @mrhollywoodgates -

I have not seen this error before...has the script been modified? Also, please be sure to right-click and download the .sh file and not copy paste from the browser as that can sometimes throw in some hidden characters. Otherwise if the script hasn't been modified, I would try running the script locally on the target system and see if you get the same issue. If you continue to get the same issue its usually best to run the script line-by-line to see exactly where the problem is. Based on the what you've provided I'm assuming the script is failing when calling the startosinstall binary.

Also, are you removing all the calls for jamfHelper? Are you able to provide a copy of the script?

@Rosko
I have not modified the script except for the user variables. I did a lot of testing and reading other posts, and what ended up working for me was a suggestion someone had about having to launch the Installer app as the logged-in user before running it via script. I added this to the script and now it works as expected. I also changed the installer app variables to hard paths as part of troubleshooting. I've now tested it on 10.9 and 10.10 and it works on both platforms.

##Begin Upgrade

    /bin/echo "Launching startosinstall..."

    consoleUser=`ls -l /dev/console | cut -d " " -f4`

    effectiveUserID=$(/usr/bin/id -u "$consoleUser")

    /bin/launchctl asuser "$effectiveUserID" sudo -u "$consoleUser" /usr/bin/open /Applications/Install macOS Sierra.app

    sleep 5

    /bin/launchctl asuser "$effectiveUserID" sudo -u "$consoleUser" osascript -e 'quit app "Install macOS Sierra"'

    /Applications/Install macOS Sierra.app/Contents/Resources/startosinstall --applicationpath "/Applications/Install macOS Sierra.app" --nointeraction --pidtosignal $jamfHelperPID &

    /bin/sleep 3

@mrhollywoodgates I am glad you were able to solve the problem. I have heard of some folks needing to do this, however I have not been able to duplicate the need to launch the app and then close it, nor do many of the customers we have using this workflow have had to do this, so I don't really know what is causing it. But thanks again for the feedback and the solution. I will keep it in mind in the future if someone else should have the issue.

Have a great day!
Josh

@Rosko Sir, can you be so kind to give me an example that you can add in the beginning of your script that can do a User Files Clean up, user keychain clean up, and flush policy history. And maybe a Prompt to change Computername before the Upgrade executes? I am thinking of just using the Self Service for summer machine refresh. Since Jamf Pro 10 can do 3rd Party Patch update, and the super useful MAU Caching Server and AUSTT, there is no need for us to reimage machines during summer roll outs. Plus we cannot image anymore anyways because of High Sierra.

I've been testing this for High Sierra upgrades, first two worked OK, then I had "could not find target" errors.

<br/>Error: could not find target...<br/>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.<br/>If you do not agree, press CTRL-C and cancel this process immediately.<br/>

Turns out that you can't do this while FileVault is doing it's initial encryption.

"You may not install to this volume because it is currently converting to Core Storage."

I just tested the VPP --> self-service workflow for the 10.13.0 macOS High Sierra upgrade.

As predicted it asked for an administrator username and password before starting the installation.

Is there a solution that allows for this workflow without requiring the admin credentials?

Really wish Apple would give a command similar to this, but for macOS upgrades:

sudo softwareupdate --background-critical

@Rosko,

Thanks for the upgrade script. It's working great. I do have one request, can you add a:

diskutil verifyVolume (bootdisk)

I had one upgrade that failed and showed errors upon running this. I'm pretty sure it was a pre-exisiting condition. It would be great if the script halted if the diskutil finds errors.

Thank you!

Fixed My Issue: