Updated so it does not care about image name or package name for simplicity and fix Setting startup disk. **(Setting startup disk no longer works via scripting using bless or systemsetup due to SIP. Workaround created using Applescript. Requires Terminal is in Security - Privacy - Accessibility on imager)

Hi Chris, how do you handle non SSD (Fusion, Spinning disks etc) based macs as APFS is only supported on SSDs. Would you not be better of doing an in place upgrade in an Apple supported fashion to get to 10.13. Then you can reimage directly to 10.13 as needed.

Or just creating a bootable USB installer.

With /Applications/Install macOS High Sierra.app/Contents/Resources/createinstallmedia

@a.stonham The only Apple computers we have that are non-ssd are 2009 White macbooks, those are 100% imaged (and can't take 10.13 anyway).

If I were to image HFS+ 10.13 I would use a 10.11 USB Imager (pre-SIP) this allows you to things like use bless for setting startup disk. (what I did previous to 10.13 / HS) and works perfectly fine for imaging HFS partitions anyway. You wouldn't have to deal with APFS or containers, or the firmware as that only applies to APFS.

Doing an in-place upgrade is a ludicrous amount of time when you are talking 950 machines for one building :).

Very interesting. While admittedly frowned on by Apple, they really haven't given any good alternatives at this time for large volume lab/classroom deployments, so this may help get us by until they do. I'll have to give this a try in our tech lab.

Thanks!

For the different device firmware packages, has anyone been able to determine how specific they are in regards to the hardware? Meaning is the firmware package the same across each Model Identifier, or can it vary amongst the same Model Identifier depending on the components that are used like brand or size of SSD drive, etc?

@scottlep In my testing it has not made a difference regarding size or brand of SSD, only SSD vs Fusion vs Mechanical. (since mechanical and Fusion drives do not support AFP and do not require the firmware update)

Hi nation, We are setting this up for someone that wanted one solution for thin and re-image to High Sierra, Working with gregnagle's bootstrappr, we modified the script to support re-imaging and thin imaging. This is all done from recovery mode. For re-imaging we are restoring 10.13 hfs dmg created with autodmg(w/localadmin and 1st boot pkg) via http, entering in the device name and rebooting. For thin imaging, use bootstrappr as per original documentation. restores are taking between 4/6 mins. We are right now in the process of testing APFS, will update post once we are done.This is working well until Apple releases the promised changes

@Nix4Life Would definitely love to see what you have come up with to compare. 1st boot package via HTTP is interesting as well :).

For me the biggest factor was full automation. My goal (mostly completed) is to boot a machine to USB, and in a few minutes have a freshly installed 10.13, and enrolled in MDM, with no user interaction.

hey @chrisdaggett,
just to circle back. We were able to get apfs restored and working. we are piecing this together. I cant take full credit as its a mashup of Greg N's bootstrappr and Rich T's first boot generator and a bunch of admins around the world figuring this out. we will script it to be 99% automated, minimal input by the techs(mount dmg, enter hostname). So the steps are the same: create autodmg afps with (localadmin,munki,first boot). boot into recovery. do a http restore(4-6 mins),mount volume/containers, reboot, pull down packages. They are still looking at MDM solutions, so once they have it we will bake that in. both restores were tested on 10.12.6 machines. They are not in rush, we just wanted to get something ready if and when they decide. As always until Apple makes changes or breaks things.

FYI in my testing as of 02/28/2018 I updated to the latest version of Sierra 10.12.6 and the firmware update was pushed from the app store. (This method may still potentially work if you don't have time to update to 10.12.6 or are running El Cap, although I have not tried the standalone firmware update in El Cap. (Now, with the latest firmware, NetResotre of High Sierra 10.13.3 works like a charm.)

Hi Nation, just a FYI,

the above method is still working for us using 10.13.4 with AutoDmg 559beta

L

Hi Nation,

Does anybody know, if I wanted to get a non 10.13 computer onto 10.13 with a fresh install, will I still need to use the above methods?

Use case: We are currently upgrading everybody to 10.13, but for those computers sitting in the stock room that are 10.12, I want to deploy it with 10.13 (fresh image like a brand new computer). I'd hate to have to format the drive with a fresh 10.12, and then run the high sierra install from the app store, this would take forever.

Thoughts?

Thanks!
Ryan

@ryan.er If you have SSD drives, I'd suggest getting to APFS so you can take advantage of future benefits APFS brings (at least startosinstall -erasedisk). Here Apple lays out their supported methods of installation for macOS.

Netinstall works, but you have to support netinstall which Apple is pushing off to open source projects. Apple did publish a migration guide for getting Netinstall to work on macOS, but I'd hate to support that long term. At least with 10.13.4, don't waste your time trying to use automated netinstall as in my testing it left some SSD machines HFS.

We have a few thousand macs we need to get from 10.12 --> 10.13 (APFS) this summer. We want to stick with apple supported methods, so we're using bootable installers on USB drives. macOS install time varies from 25-45 minutes depending on the hardware (for us, 2014/2017 Airs are 25 minutes and 2015/2016 8GB Airs are 35-45 minutes).

What really is frustrating is jamf doesn't support startosinstall so far in any way with their tools. We're paying a lot of money for jamfs tools and open source tool imagr has supported a wipe of the drive, convert to APFS, and loading macOS via supported startosinstall command (which updates firmware) since OCTOBER. Here we are in April and jamf still is shrugging every time I ask them how they're going to support startosinstall.

You can use the above methods that @chrisdaggett and @Nix4Life have put a lot of time into get working. They're not supported by Apple, but probably will work great and are faster. imagr is another (albeit slower option), but it is using apple approved methods to get clients to APFS and 10.13.

I really hope no matter what 3rd party option people are using to get to 10.13, they are asking their jamf reps where they are with startosinstall support.

PS - there's this blog post that could be used once you get machines to 10.13 to "erase all contents and settings." It requires you're APFS, and again, I'd like to see some supported documentation from the jamf side on supporting something like this.

I can not get autologon with root to work on a build disk. i tried using the commands above with no luck. tried with and without a password, anyone got any good ideas? My disk is 10.13.3 at the moment.

I was able to extract and build the FirmwareUpdateStandalone.pkg. But upon installation, I get an error, the installation failed. "The installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance." What did I do wrong?

@CasperSally I have the script from that blog set in a policy with a custom trigger for "reimage"

I packaged an AppleScript application and left it in /Library/CompanyName for support techs to run. The AppleScript simply runs the shell command to run the custom trigger. The Application is set to warn all that the machine will be reimaged.

@chrisdaggett a useful check to build into your script would be to check if the firmware update is already applied. I found this somewhere else a while back and it seems to work. This will be run from the boot disk and inside the script used to install the firmware, just use the output in an if statement.

testEFIState () { current_efi_version=$(/usr/libexec/efiupdater | grep "Raw" | cut -d ':' -f2 | sed 's/ //') echo "current_efi_version $current_efi_version" latest_efi_version=$(ls -La /usr/libexec/firmwarecheckers/eficheck/EFIAllowListShipping.bundle/allowlists/ | grep "$current_efi_version") echo "latest_efi_version $latest_efi_version" if [ "$latest_efi_version" == "" ]; then echo "EFI not upto date" efiCheck="pass" else echo "EFI upto date" efiCheck "fail" fi }

Having the same issue as @jjbauer81 . I was able to extract and build the FirmwareUpdateStandalone.pkg. But when I go to install it on a 10.12 machine, I get the same error he/she did.

i had this working on friday when i left work, i reimaged my computer with it, it works very well! now this morning with 0 changes now it wont lay down my image it's saying there isnt enough space to lay down the image. so frustrated!!!

One update, When capturing the image make sure you do it form a machine using 10.13.3 or lower. Apple has botched something in 10.13.4+ with HDutil/Diskutil and it will fail to scan/restore!

Also realized after some further testing that I had to make some tweaks to the imaging script so that has bee updated in the OP.

@chrisdaggett I'm having a difficult time wrapping my head around this:

"you will have a freshly imaged machine on 10.13 with the correct Firmware and APFS!"

Do you mean a factory version of the image? Or an image with apps, settings, etc.
What's the purpose of doing this way?
What issues or pain points is this method addressing?

@upworkadmin I mean with apps, settings etc.. You could just as easily use this method for a factory image though (just do a fresh install and take an image before doing anything else)

When you run as many customizations as we do, with 2000+ laptops, it makes things much easier and smoother. It saves enormous amounts of time and alleviates MANY points of failure. Every time you have a seperate package, or script, etc.

I can have a machine fully reimaged exactly the way we need them in under 5 minutes. Simply can not be done with fresh install/packages/etc.. As discussed if this isn't your cup of tea that is perfectly fine, for many of us this is the best way to get what we need done. I am not doing a fresh install on 2k machines at 40m a wack (before customization/packages/etc). Doing it the Apple approved method would take me over an hour per run. Right now I can do ~50-60 machines at a time (by myself) and have an entire round done in about 5 minutes. Not an hour+ to get the same 50-60 done. When you are doing this on 2k machines, by yourself, that matters :-D. Literally have had ZERO issues with imaging across any version of OSX/macOS, regardless of what Apple states. Like the OP says though, this is not approved, and not for everyone. I just share for others that want/need some of this method.

@chrisdaggett DILLY DILLY! Apple has lost the focus on Enterprise. This is evidenced by the fact that they keep removing all the tools that make Mac admin's lives better. "Having true server grade hardware to run a Server version of OSX makes IT managers happy? too bad we're killing the XServe. Your Server software (10.6.8) does exactly what you need and is stable as hell? Too bad we're going to start the long painful road of crippling it. Having your own DNS, Mail, Netboot, Software Update server with easy to use management is perfect for small IT departments? Too bad we're just going to toss those out the window. 5 minute imaging saves you time and money? You can kiss that goodbye too."

@marklamont In case anyone else goes to use it there is an Equal sign missing in the script :).

Also the up to date, and not up to date, are backwards. (the pass and fail are correct)

Should be:

efiCheck="fail"

I uploaded my new imager for those that want to mess with it or take a peak. Also updated OP with script updates and updated instructions. https://tinyurl.com/yacat44e

To use: Download DMG and restore to USB Thumb drive.
Place Firmware package in /Packages
Place quickadd.pkg in /Data
Place APFS Container image in /Configurations

If you do not want to use Quickadd portion of imager simply delete the /Data folder.