In-Place macOS Sierra Upgrade Script

[TylerC]

Hello,

I am trying to follow this guide from JAMF: https://www.evernote.com/shard/s398/sh/bec8a262-e33d-4ad9-80fa-05b939db6d8d/f4ca396a63caa510

I am using the script noted here: https://www.evernote.com/shard/s398/sh/bec8a262-e33d-4ad9-80fa-05b939db6d8d/f4ca396a63caa510/res/9163d1d7-3bbf-4e2f-b70a-0cd447c749a1/startosinstall.sh

I got everything else working so far (you do need another policy to place the .dmg in the applications folder that the article neglects to tell you). I would like the script to force the restart instead of being "soft". I tested it and found that any open application will stop the upgrade.

Just need it to forcibly and immediately preform the restart.

Thanks.

Here is the script:

#!/bin/bash
/Applications/Install macOS Sierra.app/Contents/Resources/startosinstall --applicationpath "/Applications/Install macOS Sierra.app" --volume $1 --rebootdelay 30 --nointeraction
killall "Self Service"

[sgutierrez]

Guys, this version of startosinstall doesn't have a "--volume" argument. Take it out of the script and try again. I had to look at it over and over again just to realize this. Also add "--agreetolicense" to the script.

[rqomsiya]

So does anyone have a finalized working script for 10.12.6? I’ve been looking @bp script and it seems to be able to accomplish an authenticated restart.

[cubandave]

Hey @Rosko

I added a part at end to see if if the startosinstall fails and kills the jamfHelper window.

I noticed that was very helpful the handful of users that had an issue with the upgrade.

What do you think?

while [[ $(pgrep startosinstall) ]]; do # echo macos installer in progress sleep 3 done if [[ -d "/macOS Install Data/" ]]; then echo Ready for macOS install else # no instllall data echo macos Install Data Is not there, Preperation failed #kill the full screen window killall jamfHelper ## Remove Scripts /bin/rm -f /usr/local/jamfps/finishOSInstall.sh /bin/rm -f /Library/LaunchDaemons/com.jamfps.cleanupOSInstall.plist /bin/rm -f /Library/LaunchAgents/com.apple.install.osinstallersetupd.plist /bin/echo "Launching jamfHelper Dialog (Preperation failed)..." /Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper -windowType hud -title "$title" -icon "$logo" -heading "Preperation failed" -description "We're sorry, we were unable to prepare your computer for $macOSname. Please restart and try again at a later time from Self Service. If you continue to experience this issue, please contact the Service Desk. Thank you." -iconSize 100 -button1 "OK" -defaultButton 1 -timeout 600 fi killall jamfHelper

[tjt263]

@mrhollywoodgates,
You could probably just use "$USER", or "$LOGNAME".
And "$UID", or "$EUID". They're already set. Just FYI.

[Rosko]

@cubandave I actually didn't do that just because I let the startosinstall binary handle the closing of jamfHelper and want the script to actually complete prior to startosinstall. In my testing, if startosinstall finished and tried to reboot while the script was still running I would get multiple errors from Self Service. I haven't tested this recently, but thats what I used to get and as such just left it that way cause it continues to work great.

But if you need to modify it to make it work a certain way in your environment that is totally cool! Glad it is working for you :)

[lee_smith]

@Rosko

All Thank you all for you hard work on this. I seem to be struggling and being a newbie I am at a loss.

I have performed the following:
- Created two policies:
-- 1.) One to cache the Install macOS High Sierra.app in the /Applications folder - works successfully
-- 2.) The current self-service policy to install the OS using the script provided by Rosko from GitHub https://github.com/kc9wwh/macOSUpgrade

Issue: the Splash screen appears "Please wait as we prepare your computer for the macOS High Sierra..... This splash screen sat here overnight.

Troubleshooting:
- Looking through the install.log from /var/log/install.log I do not see any errors or the startosinstall
- Looking through the JAMF.log it says "Executing Policy CPA-AllCampus-macOS High Sierra Upgrade
- In JAMF I receive the following:

What am I missing?

Thank you in advance!

[Rosko]

@lee.smith Take a look at the issues listed on GitHub, specifically:
- startosinstall sometimes does not run
- Can't find start osinstall via JAMF

There have been some issues around the AssetCacheLocatorService, but we're not sure whats causing it. If you issue lines up, please try some of the suggestions their. If they work I'll add them into the script.

[lee_smith]

@Rosko

Thank you for getting back with me. I apologize for not getting back with you sooner.

I found the issue.

There was something wrong with the install macOS High Sierra.app. I could not even launch it manually. I created it on a VM using Extended Journal. So, this might had something to do with it. I grabbed another physical computer and built it from there. Seems to be working now.

I also had to hard code the User Variables in the script. As they were not working when inputting them into JAMF.

But hey, it is working now. Woo Hoo!

[rkovelman]

Hey all, I just started working on this and a bit confused. I dont see anything about how when you use the cache option it does not install the installer in the Applications folder. What do I need to do to get it from the hidden JSS folder to the Applications folder? Mind you it is a DMG. I am following these directions, although they are all fairly similar as I clicked on the links above.

https://github.com/kc9wwh/macOSUpgrade

[dan-snelson]

@rkovelman Searching for The button section in the following may help: Reinstall a clean macOS with one button.

[stevewood]

@rkovelman you do not "cache" the installer in the traditional Jamf sense. Meaning, in the policy to cache the installer you do not choose "Cache" on the package. If you follow the instructions on the GitHub page, you use Composer to package up the installer, whether as a DMG or a PKG. If you install that PKG/DMG it does not run the OS installer, it simply places it where you want it.

So if you want the installer in /Applications, just install your DMG file. It will copy the OS installer into the folder and it will be there for the script to run against.

Make sense?

[rkovelman]

@stevewood i get what you're saying but I don't at the same time. As of right now the machines that need the upgrade have the 5GB installer in that hidden JAMF folder. Could I execute a script to open the DMG, and copy the contents of that into the Applications folder? Once that is done I can then have it delete the DMG file? I would think the whole point is to cache the file to the machine 1st, and then unpackage it. I dont see a way with the composer to have it install the file in the Applications folder.

[mm2270]

@rkovelman First make sure the OS installer is in the main Applications folder where you want it to go, then in Composer, drag the installer into the sidebar (Sources) list. It will copy the installer in and create a new source, that you will likely want to rename, then build the package as a pkg or dmg file.
When the package gets deployed it will 'install' the installer into that location, but not run it. That's what the script is for.

Incidentally, you could install the installer in any location you want to, but would need to slightly modify the script to point to the correct location as well as using a different sed command to get the installer name. I'm doing that in my version of the script for this process. The main Applications folder is not a hard fast rule, just a suggestion and the script has some hardcoded stuff in it that expects it to be there. But it can be changed if you prefer.

[dan-snelson]

@rkovelman Here's a screenshot of @mm2270's suggestion. (I prefer to build as a DMG.)

[rkovelman]

@dan.snelson I did that and clicked DMG. From a cache perspective, it still places it in the hidden folder. My guess is to run the cached policy and it will throw it in the Applications folder? From there it should work as normal, no? I think that is the missing step most fumble on?

[mm2270]

@rkovelman the problem is you need to use "install" in the policy as the action for the package, not "cache". If you use cache then yes the package will just sit in that folder until something acts on it. Change it to install and when it runs it will place it in the Applications folder.

Edit: I think to add, where you're getting tripped up is that this isn't a real "cache" as in a Jamf caching process. Think of it like installing an app like Firefox or Google Chrome. You wouldn't (normally) set up a policy to cache that, then install it later, unless there was a specific reason for that. Usually you just tell the policy to install FF or Chrome and it lands in the Applications folder. This is the same thing, just that it's installing the Install macOS High Sierra.app. Folks here use the term 'cache' because it needs to be differentiated between running the actual app and "installing" High Sierra on the Mac. Make sense?

[dan-snelson]

@rkovelman When you drag "Install macOS High Sierra.app" to Composer, is it located in the Applications folder or your hidden folder? (Please see mm2270's instructions above.)

[rkovelman]

@mm2270 thanks, setting up a test machine and will do that!

[rkovelman]

@dan.snelson its in the applications folder. By default when you cache a policy it goes to a hidden or locked JAMF folder. As mentioned above it sits there waiting to be executed on.

[dan-snelson]

@rkovelman Thanks for clarifying. As mm2270 mentioned, your policy should install the DMG, not cache it.

[rkovelman]

So running the cache seems to work. Since I am using the script from Josh, is there a line that states its already installed. Reading over the script it seems like it will try to download it and then install it. Since the .app is already installed, it just needs to execute on it.

[mm2270]

@rkovelman So, it sounds like you have some Macs that already have the DMG cached in the /Library/Application Support/JAMF/Waiting Room/ folder and are looking to convert that into a Install macOS High Sierra.app in the Applications folder. Is that right? If so, what I would do is build a Smart Group based on machines that have that DMG cached (use the Packages Cached by Casper/Jamf criteria option) and scope it to a policy that just does a "Install Cached" action on that same package, meaning in the policy Packages payload, add your DMG package there but change the option to Install Cached. Have that run on check-in, once per computer, scoped to the group mentioned before.
Once that runs on them, the High Sierra installer should then be in the main Applications folder, ready to run with the upgrade script.

Hope that helps.

[rkovelman]

@mm2270 Correct, I did that already, so we are good. When I run the script it tries to download the installer, which is should not need to do. It should see it is there and run it. I edited the script so it knew that, or thought it would.

Specify path to OS installer. Use Parameter 4 in the JSS, or specify here

Example: /Applications/Install macOS High Sierra.app

OSInstaller="$4"

OSInstaller="/Applications/Install macOS Sierra.app/"

[Rosko]

@rkovelman it does check to see if the Installer is already present in the folder specified, here is lines 71-77 of the latest version:

##Specify path to OS installer. Use Parameter 4 in the JSS, or specify here
##Example: /Applications/Install macOS High Sierra.app
OSInstaller="$4"

##Version of OS. Use Parameter 5 in the JSS, or specify here.
##Example: 10.12.5
version="$5"

As long as the installer is present in the OSInstaller path and matches the target version specified below that, it will use that installer and not download a new copy. Ensure the target macOS version being deployed by the installer is used there and I also wanted to note that you don't need to escape the space in the OSInstaller variable, its handled by the script.

[stevewood]

@rkovelman You do not need to escape the path since it is in quotes. Change this OSInstaller="/Applications/Install macOS Sierra.app/" to this OSInstaller="/Applications/Install macOS Sierra.app/" and try again.

[mm2270]

Yeah, as @stevewood said, no backslashes in the path. Using them will cause it to not see the installer. That should probably get called out in the script, because it's not the most obvious thing that those aren't needed. I can see how someone not very experienced with scripting could get tripped up on that.

[rkovelman]

Thanks @Rosko . I had to edit the version to 10.12.6 and looks like all is good. Thanks to you, @mm2270 and @dan.snelson

[rkovelman]

Curious do you guys have it running updates after the policy runs? I have a policy that runs weekly for all Macs but curious if you run updates after the install? Is it within the same policy, or did you add to the script? Also, do you guys have it clear out cached folders or not?

[dan-snelson]

@rkovelman No, I don't run anything after the upgrade; I'm just happy it worked.

I do run a script before to cause computers to submit updated inventory data: Deploying an OS X Upgrade: Recon at Reboot script.

The cache folders should be auto-cleared on successful execution, but I do have a maintenance script in Self Service users can run which executes:

/bin/rm -Rfv /Library/Application Support/JAMF/Waiting Room/*

… and …

/bin/rm -Rfv /Library/Application Support/JAMF/Downloads/*

[donmontalvo]

@Rosko we've been using your script to upgrade users to 10.13.3, on our Jamf Buddy @dan.kubley's advice, and its been smooth sailing.

10.13.5 has only been out a couple months, and the script checks to make sure Install macOS High Sierra.app is at 10.13.3.

Is it too soon to ask...can we help test your script against 10.13.5, if so do you have an updated script, or should we tweak the minimum requirement in the script?

I'll post this to your Github page...I guess under "Issues" even though the only issue we have is that Mojave should have been Death Valley after the current High Sierra + APFS + Secure Token Administrator fiasco. ¯_(ツ)_/¯

Thanks,
Don

[Rosko]

Hey @donmontalvo!

Hope your day is going well. The latest version of the script (v2.6.1) has been tested against 10.13.5 and I just did a test of the workflow last Friday without issue. The only thing you should have to change/update is line 77 (on the latest version) where we have:

##Version of OS. Use Parameter 5 in the JSS, or specify here.
##Example: 10.12.5
version="$5"

If you are not using the Jamf Pro Script Parameters, you can just update the hard-coded version we're looking for to 10.13.5.

Hope that helps! :)

[TheDecline]

Anyone using this script but not in self service on encrypted laptops? I need to do upgrades over night and I can't be in front of the computers as they are remote.

It all works when I sit in front of the machine to enter the passwords but no luck trying to bypass. I am going from 10.11.6 to 10.12.6

[rkovelman]

@TheDecline that would be a security hole, especially if you want to run it as the end user. I run it from SS, and on encrypted laptops, but leave it to the end user to do.

[TheDecline]

@rkovelman to an extent, Jamf has the "perform Filevault 2 authenticated restart" and is how I got then on 10.11. I was hoping someone is using the macOSupgrade.sh with that function some how.

[rkovelman]

@TheDecline if the machine is already encrypted there is no need to encrypt it again. Just install the OS and proceed.

[metalfoot77]

Trying to go from 10.12.6 to 10.13.5 with a pre-downloaded High Sierra installer (run from a separate policy) and using the v2.6.1 of the @Rosko script. I am shooting for a non interactive method via policy to kick off the upgrade if possible.

I have the script configured to use the eraseinstall command, however when the upgrade policy runs it shows the "Please wait as we prepare your computer..." window then just never completes and throws me back to my existing Sierra desktop. I have read there are issues when trying to convert HFS (which is what my drives are) to APFS along with the macOS upgrade. Is this the reason it dumps out or am I missing something else? Attached is my Upgrade to High Sierra policy script config.

[Rosko]

@kricotta - The --eraseInstall switch is only available on APFS volumes, hence the machine needs to already be on macOS High Sierra and have been converted to APFS.

[TheDecline]

@rkovelman Yes I know that. The issue is after the reboot it goes to file vault screen for authentication to proceed. Im trying to bypass that like it does when you manually update the OS.

[metalfoot77]

@Rosko thanks, I turned off the option but still seem to be having issues. Basically when applied, it upgrades to High Sierra but doesn't do the APFS conversion at all. Is it possible to upgrade the file system to APFS in a different step or policy in Jamf and then following along behind that with the upgrade to High Sierra?

[Rosko]

@kricotta if you are using the workflow here unmodified, then it should do the APFS conversion. If the upgrade is going through, but not the conversion and the script is the one mentioned, I would assume something is failing along the way and you'll want to dig into the /var/log/install.log and /var/log/system.log to see if there are any errors there pointing out to what happened.