Reinstall a clean macOS with one button

Reinstall macOS Big Sur with one button

Erasing and reinstalling a clean macOS is now a common workflow for reprovisioning Macs for different users, purposes or simply starting over. This feature was introduced in Apple’s macOS High Sierra 10.13.4 installer and has evolved with Mojave, Catalina and now Big Sur.

Let’s spend some time discussing how to manage macOS Big Sur installations including:

Restricting installations

Not every administrator is ready to support macOS Big Sur, but sometimes our end users get ahead of us and install it themselves. This can result in lengthy support calls when something goes wrong.

What steps can we take to prevent our end users from installing a new major macOS version? Keep in mind, end users can acquire the installer and run the installer in multiple ways. That usually means taking more than just one step.

The easiest method for restricting unwanted installations is to disclose your organization’s policy to end users that states “Do not install major macOS upgrades unless authorized by the Information Technology Department”. Be sure to specify the penalty for non-compliance.

This does absolutely nothing to prevent someone from doing it anyway, but it asserts authority without removing any privileges. Depending on your organization, this may be enough.

To avoid end users receiving notifications that the macOS Big Sur installer is available, administrators can use the –ignore option built into the softwareupate command line tool.

Create a new Jamf Pro policy and add the Files & Processes payload toward the bottom. In the Execute Command field enter:

This immediately hides the Big Sur upgrade from both the Software Update pane in System Preferences as well as the softwareupdate command line tool. It also disables the red badge on the System Preferences icon if added to the dock.

Note that macOS Catalina 10.15 is the last macOS version that supports the –ignore option. The option has been removed from Big Sur itself.

Administrators can take action using the Restricted Software feature found under Computers in Jamf Pro. We can use this feature in a few different ways, and it will apply whether the end user is a Standard user or an Admin user.

1. Restrict by application name and warn the end user. This won’t prevent end users from installing macOS Big Sur, but we can both alert them and ourselves via email at the moment of trying to install the software. This won’t alert about attempts to install supported versions of macOS like Catalina.

2. Restrict using the InstallAssistant process and warn the end user. An alternative to restricting the app name, which the end user can change, is to restrict the InstallAssistant process name. This is the name of the process that runs when double-clicking the installer and displaying windows guiding the process. This won’t do anything if the installer is run using the startosinstall command line tool.

3. Restrict using the application name and kill the process. This is similar to the first method, but it includes the Kill Process option. Instead of allowing the end user to continue, Jamf Pro will quit the installer before it can continue. Adding the Delete Application option will delete it immediately, bypassing the Trash. When restricting by application name, be aware the end user can simply rename the installer and bypass the restriction.

4. Restrict using the InstallAssistant process name and kill the process. This is similar to the second method, but it includes the Kill Process option and could include the Delete Application option. It will prevent any macOS installer from running when double-clicked including Catalina, Mojave, High Sierra, etc.

Anyone with admin privileges on a Mac can do practically anything, including installing an operating system. The most basic step we can take is to remove admin privileges for end users and require they use Self Service for running policies you allow.

Removing admin privileges, though, makes your end users heavily rely on IT administration.

Setting a firmware password prevents anyone without the password from booting to the Recovery HD, erasing the existing operating system and installing a new macOS. Since this is at the hardware level, no one without the password can install or upgrade.

The caveat with setting a firmware password is that someone in Desktop Support helping a remote user may have to provide this password to the end user. Be sure each Mac has a unique password that won’t unlock any other computer.

Administrators need to balance limiting access to the Big Sur installer with needing to install it themselves. For example, they can use scoping Exclusions to avoid restricting their own test devices.

Deploying the installer

Before we can deploy the macOS installer, we need to acquire it.

In the past, we’ve discussed Apple’s –fetch-full-installer option in the softwareupdate command.

It has the advantage of being a small and light command that we can send to our Macs to retrieve the installer themselves, which works great with on-premises content caching servers. However, since its introduction, the option has grown more and more unreliable.

It does seem to work somewhat better if adding the –full-installer-version option to specify the specific macOS version we want.

Still, it seems completely broken on the latest versions of macOS Catalina and Big Sur. Maybe, this will reliably work in the future.

The Install macOS Big Sur application is available in Apps and Books when viewing either Apple Business Manager or Apple School Manager and is deployable like other Mac App Store apps. That means we don’t need to upload an unwieldy package to our distribution points or manage new versions as they’re released.

While this works well, it does have one caveat. This will download what some folks describe as a “stub” installer. It’s not a full installer but rather the same app without the 12 GB SharedSupport.dmg in the app bundle. When double-clicked or run using the startosinstall command line tool (discussed a little later), the Mac must be connected to the internet and it will download the rest of the files it needs to complete. Depending on the speed on the current internet connection, that may mean a delay of 10, 20, or 30 minutes or longer.

This type of deployment is best suited for school lab Macs and works well with content caching servers to speed delivery. When using it with home users or those who’ll be invoking the installer themselves using something like Self Service, be sure to alert them not to put their Macs to sleep, to leave them plugged in to power and to allow time for the installation to complete.

Another way to acquire the installer is through the App Store on a Mac. This downloads the latest version and places it into the Applications folder. Before we can deploy it to our fleet, though, we need to package it.

Jamf’s Composer application can do this, but because of the size of the Big Sur installer (it’s just over 12 GB), Composer can only create a DMG file; it cannot create a PKG file. That means only Jamf can deploy this package because it’ll recognize it as a package it can deploy.

Thanks to Armin Briegel who maintains Scripting OS X, we have a new option for not only reliably acquiring the latest macOS Big Sur installer but also downloading it in PKG format ready to deploy.

His tool called is a python script that accesses Apple’s software update servers and downloads the same package the Mac’s built-in software update service would use. You’ll find it on Armin’s GitHub respository.

To use the tool, save the script to your desktop or other location and run it using Terminal (this does not require admin or sudo privileges).

The Terminal window displays both the download speed and time remaining. When the download is finished, the script places an InstallAssistant.pkg file in the same location as itself. Upload the package to your Jamf Pro distribution point and when deploying, it’ll place the Install macOS Big Sur application into the Applications folder.

When we’re ready to deploy the installer using any of these methods, we need to make sure it’ll do so successfully. So, let’s next examine macOS Big Sur’s installation requirements.

Identifying Macs eligible to erase and install

Before running the installer to erase and install our Macs or even upgrade them, we need to first identify which ones meet Apple’s system requirements.

Let’s create a new Smart Computer Group to identify eligible Macs and name it “macOS Big Sur Compatible Macs” and add the following criteria:

We need to use the model identifier of Macs to pinpoint the exact models Apple says are eligible for Big Sur. That’s a little more than 50 models. Rather than bloat our Smart Computer Group with 50 more lines of criteria, we can use a regular expression (or regex) to identify them. Regex lets us create a pattern that can match certain strings of characters such as model identifiers. This one line of text will match all the eligible models including the new Apple Silicon Macs introduced this year. Copy and paste it in the value field for the Model Identifier criterion in the above Smart Computer Group.

After saving, be sure to click the View button to verify the group is working as expected.

While we’re at it, create a second Smart Computer Group named “Install macOS Big Sur App Cached” and add the following criteria:

This will help us identify Macs that have the Big Sur installer app already downloaded to prevent Jamf Pro from downloading it again. Be sure to get the current version of the installer app by selecting it and choosing File > Get Info.

Now that we’ve identified Macs ready for macOS Big Sur, let’s end with methods for running the installer.

Remotely running the macOS installer

The startosinstall command line tool is found inside the Install macOS Big Sur app bundle. It does the same thing as double-clicking the installer application without showing any of the dialogs and windows. It also has the advantage of working even if we’ve used Software Restrictions to block the InstallAssistant process and we can invoke it as part of a script or a Jamf Pro policy (optionally, using Self Service).

To find the command line tool, right-click or Control-click the Install macOS Big Sur application and choose Show Package Contents > Contents > Resources. Locate and drag the startosinstall file into a Terminal window and add –usage to the end.

This lists several arguments (each beginning with double-dashes) and explains what each does. We want to use the following:

Putting the entire one-line command together, it looks like this:

We can put the startosinstall command into a policy and make it available in Self Service. We’ll need two policies altogether.

The first policy will place the Install macOS Big Sur app on our target Macs.

When that’s successful, our “Install macOS Big Sur App Cached” Smart Computer Group should now list Macs ready to erase and install.

Create a second Policy in Jamf Pro named “Erase and Install macOS Big Sur”. Complete the following payloads and scope.

Add a button icon, assign categories and save the policy. As Macs check in, they’ll download and install the Big Sur installer and update inventory. Then the Self Service policy to erase and install macOS Big Sur will become available for all end users or specific users you scope.

One more thing — Apple Silicon

Late this year, Apple started releasing updated product lines that include their new Apple Silicon M1 chip. While the macOS behaves the same on Apple Silicon as it does on Intel Macs, the startosinstall command has two additional required parameters. They are:

As part of our command, we need to supply the username and password of an account with a SecureToken. We know of SecureToken today as a requirement for using FileVault.

This example is providing the password of an admin account in clear text at the beginning of the command. It should be obfuscated in some way to keep it concealed, but it’s still a risk to include any password in a script. Consider using Jamf Pro to create an admin account just before running the script. The admin account should be a username and password unique to just this process to avoid disclosing credentials used elsewhere. This doesn’t completely mitigate the risk of exposing admin credentials in your scripts. Administrators will need Apple’s help with a better solution.

We don’t know yet if Apple is planning to provide more information or best practices for using the –eraseinstall option on Apple Silicon Macs. When they release their updated Deployment Reference for macOS Big Sur, maybe we’ll know more.

Upgrading instead of erasing

With one simple change, this entire workflow can instead upgrade a Mac to macOS Big Sur from an OS X 10.9 or later operating system preserving applications, data and user settings. Or it can reinstall Big Sur over an existing Big Sur operating system. Installing the same version of macOS can sometimes repair corrupted installations.

Edit the “Erase and Install macOS Big Sur” policy or clone it to make a new one and rename it to “Upgrade to macOS Big Sur”. Then adjust the Execute Command field in the Files and Processes payload to omit the –eraseinstall and –newvolumename options.

See what Jamf can do for you

Still on macOS Catalina?