Skip to main content

Hey Guys,



First time poster, long time lurker. Sorry if this is already covered, I've been searching the forums for a week but found no case that matches what we want to do... here's the situation;




  • We're looking to install High Sierra with APFS to 38 Macs currently running a mix of El Cap and Sierra, compatible and can be wiped, to be done remotely or with very physical interaction


  • We've tried building the Installer into DeployStudio following this guide - http://www.deploystudio.com/Forums/viewtopic.php?id=7947 (Errors out at the part when DS tries to copy HighSierra to the Macintosh HD, getting XSTA errors which are a little mysterious and hard to diagnose)


  • With that fail under our belt, we're experimenting with the method here - https://github.com/kc9wwh/macOSUpgrade but would really like to be able to deploy this remotely rather than user initiated..




The goal here is to get High Sierra with APFS pushed out to 38 machines, does anyone have a tried and tested method of doing this?



Big thanks to everyone who posts on here, its been a life saver these last few years.

I think you may need to user initiate this update. Is there a reason you cant?

You could implement roskos' solution without the user initiation. Just run it as a policy at check-in caveat is that it reboots the computer without warning so you'd need to schedule it.

I think the problem you're running up against is the fact that imaging is not a supported method of upgrading to High Sierra. It depends on your environment's requirements, but you could use the "startosinstall" binary built into macOS installers. We use this along with Self Service to handle our upgrades, but you could certainly set up a policy that runs a script like this at a convenient time:



#!/bin/bash



#Start High Sierra Install

/Applications/Install macOS High Sierra.app/Contents/Resources/startosinstall --applicationpath /Applications/Install macOS High Sierra.app --nointeraction



exit 0


You can learn more about this process here: https://www.jamf.com/blog/streamlining-your-macos-upgrade-process/



If you have any further questions, just post them here. We'd be happy to help you find a viable solution.


  • @wesleya
    in 10.13.4+
    /Applications/Install macOS High Sierra.app/Contents/Resources/startosinstall -help



--eraseinstall, Erase all volumes and install to a new one. Optionally specify the name of the new volume with --newvolumename.


Meaning you can do this in one fell swoop.



#!/bin/bash



#Start High Sierra Install

/Applications/Install macOS High Sierra.app/Contents/Resources/startosinstall --applicationpath /Applications/Install macOS High Sierra.app --nointeraction --eraseinstall



exit 0

Yes, it depends on beano's requirements. If you (beano) would rather upgrade, you can run the script I posted with just the "--nointeraction" flag. If you want to start clean with "--eraseinstall" you need to think about how you're going to enroll these computers after the install.



Some considerations:




  • Do you have DEP in place? If you don't, I would strongly recommend using an upgrade. This keeps the enrollment in place.

  • If you have DEP, do you have a workflow for these? Again, here, if you don't, I would suggest using an upgrade.

  • If you have both in place, DEP is a good way to go and does provide some extra enforcement.

Thanks @wesleya @cubandave @bcrockett




  • I wish we were using DEP, its seems like i'd be a real game changer in situations like this! 😛


  • Based on your suggestions and Since theres no DEP in place we will likely use the following workflow;




Netboot to created DeployStudio/AutomDMG captured High Sierra HFS+ > Install > Enroll/Policies/various JSS goodies> Cache High Sierra installer in the applications folder > Have the user install this using Self Service or schedule the policy to run at a convenient time




  • Again thanks for suggesting the methods above... I assume that each of these processes involve caching the High sierra installer to Applications folder before upgrading right?

@beano as @cubandave pointed out, you can still use this solution just use a login or logout trigger. Use a carrot and stick method with your users.



1) communicate with your users that they have until a set date to do the upgrade on their own using Self Service. The "carrot".



2) On the set date convert from a Self Service policy to an "install at logout or login" policy. The "stick".



We are using this method in many of our locations to upgrade. We push the installer onto the machines ahead of time so the user is not waiting for it to come down. By doing that you should be able to set the login/logout policy to be offline in case you have mobile users that cannot get to your JPS.

Ok, I've done a bit more testing here. What I heard, and can verify it's true is that the "--eraseinstall" flag requires 10.13. I've also heard it requires APFS, but I can't say for certain whether that's true or not.



Anyway, beano, I think you should upgrade these computers by caching the installer and using the script I posted earlier. Imaging, while possible, is going to be convoluted. I would upgrade the fleet using a workflow like this: Cache the installer, Set up Self Service policies, and have staff or help staff run it.



Anyway, DEP is good and useful. Basically it automates the enrollment of devices. You still have to make the policies and profiles that get these set up, but enforcing that enrollment is a big deal, especially when you have a big fleet. 38 definitely isn't huge, and you can probably manage using Enrollment Invitations, but it's still worth keeping on your radar.

thanks @wesleya @stevewood Both really sensible advice, thanks for taking the time to post, we're gonna go with the cache and self service route. We're experimenting with upgrading from 10.12.6 > 10.13.4 and 10.13.0 >10.13.4 to see which one works best. I'll post the results here today.

For any future readers - 10.12.6 > 10.13.4 worked well using the following script after caching the installer in the Applications folder...



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

@beano are you just running that script line by itself or is it in conjunction with this solution? If running by itself I'd be interested in see how you have this policy setup. I am also caching the installer for HS in a separate policy and would like to upgrade from Sierra to High Sierra with conversion to APFS.

Reply


Terms & ConditionsCookie settings