Whether you plan to be an early adopter and migrate to Big Sur on day one or slowly make the transition over time, most enterprises won’t be skipping the upgrade to macOS Big Sur. Businesses should not sit this one out given the new security features, redesigning of the underlying OS, and the benefits it could bring to users and IT.
SEE: macOS Big Sur: A cheat sheet (free PDF) (TechRepublic)
Regardless of the timeline for your transition to macOS 11, one thing is certain: The deployment plan offers several choices that depend on your environment’s infrastructure and—in the age of remote working—where the devices are located and the resources they’re using. These, perhaps more than anything else, will define how the upgrade path will proceed.
One such path leverages the Content Cache service built-in to macOS to download and cache a copy of the installer file, in turn deploying it to all devices that are on the same logical network as the clients themselves. This is great to cut down on bandwidth utilization and speed up mass deployments but relies almost exclusively on devices being in-house, making it a no-go for devices off-site, such as employees working from home or abroad.
Mobile Device Management (MDM), or some form of remote management software, seems like the biggest advantage here for IT departments looking to ensure devices are working as intended and remediating it with policies while also keeping resource utilization to a minimum, regardless of whether devices are on- or off-site.
SEE: How to create a bootable USB installer for macOS Big Sur (TechRepublic)
With either strategy, the process is a relatively simple one, but may still trip up users with little experience managing their Macs. Or perhaps device policies in place prevent users from making system-level changes. Either way, the commands baked into the installer app will ensure that the upgrade or full installation occurs without issue and without requiring end-user interaction.
- macOS client computer(s) supported by macOS Big Sur
- macOS Big Sur installer saved to local storage
- Internet access (optional; but highly recommended)
- MDM or remote management software client
macOS Big Sur: Upgrade installation (in-place)
Whether creating an MDM policy or running the command remotely on the client device(s), the command below will perform the upgrade to macOS Big Sur silently, accepting the EULA and forcefully quitting any open apps but otherwise leaving data intact, including user accounts and home directories:
sudo /Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall --agreetolicense --forcequitapps --nointeraction
macOS Big Sur: Full installation (wipe/reinstall)
Similarly, the command below will work as a policy enforced by MDM or when run remotely and will install macOS Big Sur silently just like the upgrade command above, but with a significant addition: The full installation command will perform a wipe, or erase, the HDD/SSD prior to installing macOS 11 from scratch. This command requires APFS as the file system and will delete all data from the drive, including accounts, home directories, and installed applications then create a new volume named Macintosh HD:
sudo /Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall --eraseinstall --newvolumename "Macintosh HD" --agreetolicense –forcequitapps --nointeraction
If the existing APFS volume has other containers that need to be protected from erasure, appending the following syntax to the command will prevent other containers from being deleted when using the eraseinstall argument:
Lastly, the startosinstall command allows for chaining installations after the OS is updated/reinstalled. This is great for custom app deployments and for client-based packages that re-enroll devices to MDM servers if Apple’s DEP service is not being used to manage MDM hand-off during the setup phase:
The –installpackage argument may be specified multiple times in the command to include multiple applications in the chain. Also important to note is that applications referenced by this argument must be copied locally to the device’s storage for the command to run successfully.
Subscribe to the Developer Insider Newsletter
From the hottest programming languages to commentary on the Linux OS, get the developer and open source news and tips you need to know. Delivered Tuesdays and Thursdays