So I’ve been a little quiet on the blogging recently. Between starting a new job and jumping two feet in, it’s been a bit of a hectic few months!
I was recently asked by my new boss (Ben, aka Mac Mule) to look into building a workflow with jamJAR to erase and install a copy of Mojave with minimal interactions. This would allow someone to deploy a ‘clean reinstall’ policy without having to use NetBoot, or the Recovery Partition.
Without further ado, let’s get to it.
Time Sensitive Information
For possible historic reason, please find the versioning of various aspects below.
- Date: October 2018
- Jamf: 10.7.1
- Munki: 18.104.22.16843
- macOS: 10.14.0
So the requirement was to utilise the newer feature of the ‘Install macOS Application’ (added in the ‘Install macOS High Sierra Application’ version 10.13.4) to perform an erase and install from the command line, via the
As discussed in a few videos and conferences, we at dataJAR utilise a mixture of Jamf Pro and Munki for software deployments / patching, called jamJAR, therefore the aim would be to use this to achieve our goal.
In case you haven’t heard of it, jamJAR leverages Jamf to write out the contents of local-only manifests for Munki which then performs most software installations and patching. This leans on the strengths of both products to provide the best solution.
To utilise this new option, there are two main requirements from a technical perspective:
1) The volume we will be targeting must be running APFS.
- For devices running High Sierra, if they are using an SSD / Flash storage, they’ll have been converted to APFS automatically, by default.
- For devices running Mojave, they’ll have all been converted to APFS automatically, by default.
2) You will need to use an “Install macOS High Sierra” Application that installs High Sierra 10.13.4 or newer, or Mojave.
- For this, I have only tested the Mojave 10.14.0 process, but I don’t see why this wouldn’t work for 10.13.4+, just test in your own environment!
3) Ideal (but not required!) you’d have the device in DEP, assigned to your management solution of choice, therefore giving you an almost ‘Imaging’ workflow.
Now as we use jamJAR, we’ll be using Jamf Pro for scoping. In our work here we purely scoped the relevant jamJAR policy (in this case, “Add to installs” “ERASEAndInstallmacOSMojave”) to devices with an OS “like” “10.14.”
You should set this up as required for your own environment. Perhaps you add devices to the policy manually? Perhaps you put the policy in Self Service and behind a login barrier?
For our usage, we also set the policy up as Self Service only (no triggers). This meant we could control the testing and deployment.
Lastly, as we have the Munki install configured as requiring a logout, it won’t trigger automatically until someone logs out. To get around this, we added a ‘logout’ script into the same policy that will force a logout once the Munki install is cached and good to go.
How’s it look?
A little something like this, complete with some dataJAR Munki rebrand work (More info):
Please Note: This has been sped up over the slower screens. Total time from clicking ‘Go’ to rebooted back to the setup assistant is around 40 minutes. This included download time!
So what do I need to do?
So in order to get this working as intended, I had to add two keys to the pkgsinfo ?file (ERASEAndInstallmacOSMojave.plist):
Of the two keys to add, this is the newest and the one with (arguably) the least amount of testing and documentation of all possible options. This is mostly due to how new the commands are, and how often they change / are added to.
This key is detailed in the Munki wiki here, but essentially we simply add the erase flag as show here. This is what instructs the
startosinstall command to erase the disk first instead of performing an ‘in-place’ install.
This key is used to change the default behaviour of Munki, detailed here. In summary, Munki will not try and install a macOS installer Application workflow if the current device is already running the same major OS version, e.g. If I add a 10.13.6 Install macOS appliance to a manifest, it won’t install on any devices running macOS 10.13.0-10.13.6. This is helpful as it’ll stop devices going through a 1 hour workflow just to update their OS, when a combo update would be better for the job.
Unfortunately, this breaks our usage above, so to get around this, I simply added a installcheck_script that runs an
exit 0 which asks Munki to proceed with the install. This is shown here.
Complete pkgsinfo file
To help you get a better understanding of how the pkgsinfo file looks for the above, you can find a copy here.
Please Note: This won’t be a drop in replacement for your own one, but is more to give you an idea.
Considerations if you’re not using jamJAR
So you’re looking to role this out yourself but aren’t using jamJAR? It’s easily possible, with some considerations.
I’m using Munki…
- For the technical requirements, consider changing the
installcheck_scriptto check if a client device has 10.14 and / or a boot volume on APFS
- For the scoping, consider using per-device manifests to only make the erase and install available to those Macs you intend to.
- Also consider setting it as an ‘optional install’ so users would have to run this themselves to trigger it, no automated running!
- To trigger the full wipe and installation without forcing the user to logout, consider setting the
unattended_installkey to true (here be dragons!).
I’m using Jamf Pro…
The folks at Jamf have a White-paper already written up for you, go check it out here.
Other associated links
Phew that was a long one! I’ve detailed how we utilise jamJAR to perform an Erase and Install of macOS Mojave, as well as some considerations if you’re not using jamJAR, but are using Munki or Jamf Pro. As always, if you have any questions, queries or comments, let me know below (or @daz_wallace on Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.
The usual Disclaimer:
While the author has taken care to provide our readers with accurate information, please use your discretion before acting upon information based on the blog post. I will not compensate you in any way whatsoever if you ever happen to suffer a loss/inconvenience/damage because of/while making use of information in this blog.