No more sudo with softwareupdate or unattended updates on macOS running on Apple Silicon

Today, Apple announced new Macs running on Apple Silicon running on macOS Big Sur. Let’s talk about a change that should concern IT admins. On Apple Silicon Macs, you get the following message when you try to run:

sudo softwareupdate -i

Using softwareupdate to install updates on Apple Silicon should not be run with sudo

And immediately after, you get prompted to authenticate with a GUI prompt.

Two things to note here:

  1. Almost all software management tools for macOS are built to run as root and run as sudo.
  2. Never before has an update required a user to confirm an update by authenticating their credentials. This makes unattended updates impossible.

What are the methods to get users to update their operating system?

There are a few different methods that have been used by admins to get users to update their Macs.

  • Schedule an OS update using the MDM command. Apple approved.
    • This is unreliable. It does not work consistently on either iOS or tvOS, let alone with macOS. There is also not a very good user experience attached. If the command goes through successfully, the user simply sees their computer restart immediately.
  • Manage automatic update settings though a configuration profile. Apple approved.
    • This is not reliable either. There are specific requirements that need to be met in order for updates to automatically install that Apple has not documented. Running applications can also easily prevent an OS update from taking place. This also seems to take place in the middle of the night when laptops may not be powered on.
  • Force updates using the command line tool: softwareupdate.
    • Up until Macs with T2 chips were introduced, this was the most reliable method. With T2 Macs, this has been a less reliable particularly when bridgeOS updates are part of the equation.
  • Constantly notify the user that they need to update their OS using custom tooling.
    • Perhaps the most reliable method today since this is the method that Apple has designed their software update process around for consumers. This has the drawback of annoying your end users. This also partially relies on being able to read what updates may be available through softwareupdate.
  • Using Zero Trust security policies, block end users from accessing company resources until they’ve updated their OS.
    • This works great if your environment has been setup with all resources being gated behind networked resources and your company has been able to implement zero trust policies. However if there are resources that are not gated behind zero trust policy, you may end up with end users that never update.
  • Deploy the latest full OS installer every time a new update is released.
    • To be fair, I don’t know of anyone using this method. But it is an option nonetheless. Updates will likely take 30-35 minutes if you go this route. Big Sur is supposed to improve and speed up the update process. Deploying the full OS installer would likely undo any of these update improvements. This also would mean deploying ~12GB installers every time there is an update as opposed to the ~5GB downloads you’d be dealing with (combo updates have largely been hovering around this size). Another thing to consider is that it may be possible that a full installer is skipped on certain updates. And there are other side effects of performing a full install vs an update.

Each method has their pros and cons. They all work great in environments where a user is assigned to them. However, they don’t really address the methods in which 1) there is no human available to install an update or 2) where the end user simply is not complying with the notifications or requirements.

Apple has not provided better management options for macOS updates. In fact, with each major OS release they’ve gotten rid of the options that have been available to us. You can no longer run your own Apple Software Update Server. You can no longer ignore specific updates. The command line tool softwareupdate has become less reliable depending on the conditions in which you tried to run it on Macs with T2 chips. Now it seems

I (and I’m hoping other IT admins, too) have requested better options and improvements to the current management tooling, but Apple has yet to implement any of them. As of today, you have the two options listed above which involve sending MDM commands or a configuration profile. Additionally, you have the ability to delay updates up to 90 days where major and minor OS updates are treated the same. But that doesn’t achieve the purpose of getting devices on to the latest OS version.

In our environment, this would be quite disastrous as we have computers that are online, but unattended. There’s no reliable automated method to update Macs to a specific OS version with a good user experience.

The request to Apple: better update enforcement tooling

From an IT admin perspective, I do not believe what is being asked would conflict with Apple’s goal of having users running a secure operating system.

I am (and hopefully other admins are too) just asking for a method that allows us to force a device to be updated by a set date using a configuration profile. We cannot rely on MDM commands that simply may or may not reach a device. This workflow should also account for situations where a user may be turning on a computer for the first time after the deadline has passed, they should have X amount of reminders before the update is forced at this point.

The UX around this request should be handled by Apple (a company that prides itself on its UX) so that IT admins don’t have to deal with custom tooling. This would result in the user getting reminded regularly and then forced to upgrade if the deadline has passed. I believe the above request would work well for other Apple platforms like iOS and tvOS as well.

Final Thoughts

This is not the first time I’ve written about managing software updates on macOS. I cannot help but wonder how a company like Apple can promote and put so much focus on the security of their products and yet not make proper management tooling to keep those same products up-to-date when used in a business environment? Microsoft has figured out how to manage OS updates on Windows and Google has figured it out on ChromeOS so why can’t Apple do the same for its various platforms? Why does Apple make it more difficult for companies to keep devices they have purchased/owned up-to-date?

As of right now, I’m not entirely sure how we’ll be able to manage macOS updates going forward on these machines that are unattended. In the grand scheme of things, our organization is probably insignificant to Apple in terms of the amount of money we spend. I’m writing this in hopes that other admins provide feedback to Apple because this makes the macOS platform considerably harder to keep secure (on the latest version) in business environments. Jamf has a good article that discusses the various options for providing Apple with feedback. Please let your fellow admins know and start filing that feedback with Apple.

Apple plans on removing enterprise options for macOS software update

For sometime now, Apple has allowed IT administrators to manage updates for macOS. However in a very near future that may change unless other IT administrators start to provide feedback to Apple. This will be long but please read as now is a critical time to provide Apple feedback before WWDC (whenever that takes place) and the next major OS is released.

Continue reading Apple plans on removing enterprise options for macOS software update

Handling macOS Software Updates with Jamf Pro

Jamf Pro has not handled software updates successfully on all Mac hardware since Apple introduced the T2 processor with the iMac Pro back in December 2017. It’s been requested that they address this issue in a feature request, but it’s gone completely unacknowledged (Edit: As of November 11, 2019, the feature request is now marked as Under Review).

The problem with the software update process on Macs with T2 processors is that sometimes there is a bridgeOS update (the OS on the T2 processor) which requires a shutdown instead of a restart. The Mac will read the shutdown and automatically power back on to apply the bridgeOS update. However, not all software updates have a bridegeOS update which would mean a shutdown in those situations would actually leave the computer powered down. Unfortunately, Jamf Pro does not know how to handle this situation. Apple did introduce the --restart option for softwareupdate but that also comes with its own problems in that it hasn’t worked reliably in all scenarios. Since the solution to this isn’t particularly difficult to work around, I created a script to address this workflow in our environment.

Before continuing, I’d like to mention that we do leverage macOS’s ability to do automatic updates. This has one benefit of doing automated authenticated restarts which is important on Macs with FileVault enabled. However, we’ve found in our environment that after a month only 60% of computers running macOS 10.14 are up to date on the latest version. It’s a bit of a black box as to how macOS determines when to do automatic updates. Needless to say, the rate of updates is unacceptable.

This script is meant to be used with Jamf Pro and makes use of Jamf Helper. The idea behind this script is that it alerts the user that there are required OS updates that need to be installed. Rather than forcing updates to take place through the command line using “softwareupdate”, the user is encouraged to use the macOS GUI to update. When I say macOS GUI, I’m referring to the Software Update mechanism that Apple refers consumers to:

In recent OS versions, Apple has done a poor job of testing command line-based workflows of updates and failed to account for scenarios where an end-user may or may not be logged in. The update process through the GUI has not suffered from these kind of issues. The script will allow end users to postpone/defer updates X amount of times and then will give them one last chance to postpone. We run this script using the Once A Day policy frequency which means the user will get this once a day so long as it checks in.

This script should work rather reliably going back to 10.12 and maybe further, but at
this point the real testing has only been done on 10.14. Please note, that this script does NOT cache updates in advance. Sometimes Apple releases updates that get superseded in a short time frame. This can result in downloaded updates that are in the /Library/Updates path that cannot be removed in 10.14+ due to System Integrity Protection.

This script does make use of Jamf Pro Script Parameters:
Parameter 4: Optional. Number of postponements allowed. Default: 3
Parameter 5: Optional. Number of seconds dialog should remain up. Default: 900 seconds
Parameter 6: Optional. Contact email, number, or department name used in messaging. Default: IT

Here is the expected workflow with this script:

  1. If no user is logged in, the script will install updates through the command line and
    shutdown/restart as required.
  2. If a user is logged in and there are updates that require a restart, the user will get
    prompted to update or to postpone.
  3. If a user is logged in and there are no updates that require a restart, the updates will get installed in the background (unless either Safari or iTunes are running.)

There are a few exit codes in this script that may indicate points of failure:
11: No power source detected while doing CLI update.
12: Software Update failed.
13: FV encryption is still in progress.
14: Incorrect deferral type used.

Below are some screenshots for what you will see on macOS Mojave. However the text is aware of at least 10.8 and higher where the instructions to get to Software Update might differ.

This is the initial message you will see when prompted to update:


When you click Continue, you will be taken to Apple’s Software Update:


This is the final message you will get when you’ve postponed the maximum number times:


Note: “Please make selection in HH:MM:SS” is not text I can modify. It serves as a countdown for the end user to know how much time they have before they are forced to update.

And lastly when the forced update is taking place, a headsup display window pops up:


The script is easy to modify if you don’t like the verbiage or if you want to use it for inspiration on other workflows. The script can be found here on my Github page.