Hi all !

About time for another blogpost I reckon! And well aware of that fact that I may be opening Pandora’s box here, not to mention a can of worms, let’s have a look at what our options are in view of keeping our Macs up to date.

Disclaimer: My intent with this blogpost is to discuss the available options for macOS Big Sur update strategies as things are at the moment in view of some changes native to Big Sur and Apple Silicon Macs. No judgements calls are made in this post. The only intent is to help fellow Mac Admins to understand the current challenges.

Let’s first start with listing what is available as tools and functionality to achieve our goal:

  1. Do nothing and educate your end users to keep their devices updated, maybe remind them from time to time with a notification via a Jamf Pro smartgroup and policy.
  2. Deploy a configuration profile to enforce automatic updates
  3. Use the ‘Software Update’ payload in a Jamf Pro policy
  4. Use the ‘Files and Processes’ payload in a Jamf Pro policy
  5. Package the full installer and use a Jamf Pro policy
  6. Use MDM commands
  7. Use any other 3rd party tool and or script, like nudge (see below)

As you can see, quite some options, but are they all even efficient? Well, in a perfect world we would be able to pick a flavour which suites our deployment strategy, and go for it. Unfortunately, like I mentioned above, things got a bit complicated, and with some unexpected behaviour and bugs, I mean features, we are actually a bit limited in view of what actually works.

That said I’d like to start with the following Jamf tech write up on the topic: https://docs.jamf.com/technical-papers/jamf-pro/deploying-macos-upgrades/9.96/Overview.html

I’m sure my colleague-tech writers are gonna forgive me for using the below flowchart, so let’s have a closer look at it:

I did not include the ‘erase’ scenario in my list here above, but yeah, if your goal is to wipe and re-install macOS, using the –eraseinstall flag on the startosinstall binary would be my preferred way of doing things. Unless you are only having tech wizards as end users, who can manage an erase/install/re-enroll on their own, but even then, you may want to keep things easy. For instance by caching the installer and provide a one click button in Self Service to speed things up. I’ll leave this path at providing you the link where this approach is explained in detail: https://www.jamf.com/blog/reinstall-a-clean-macos-with-one-button

Note: One thing I do want to highlight is the fact that for Apple Silicon devices, this will only work if you provide a username and password of a SecureToken-enabled admin account in the command. This however, brings up the discussion on passing admin (or any for that matter) credentials in clear text in a command or script. As mentioned on the link above, Administrators will need Apple to help finding a better solution for this. The command you'd use if you want to go that route would be like:
echo 'mYsup3rS3cur3P4sSw0rdW1ch1w1LLn3v3RpUt1N4Scr1Pt' | '/Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall' --eraseinstall --agreetolicense --forcequitapps --newvolumename 'Macintosh HD' --user adminuser --stdinpass

Moving to the left side of the chart, where we retain computer data, ignoring using recovery mode, we have:

  • Package the installer
  • Run software update using a policy
  • Use MDM commands

Those are basically the main 3 options we can use, but as you saw at the beginning of this post, I added a few more. Why? Well, first of all, because they are available and are not limiting us to use the pure built in functionality of Jamf Pro, but also because what happened over the recent macOS and Jamf Pro versions.

In view of keeping this post within acceptable length, I’m not going to elaborate each issue or roadblock we saw, but instead summarise it as follows.

First of all, starting with Macs equipped with a T2 chip, we saw that using a Jamf Pro policy with that ‘Software Update’ payload resulted in failing updates if the update required a shutdown instead of a reboot. This was fixed in Jamf Pro 10.23, but Apple Silicon / M1 Macs made this issue resurface. On Intel-equipped Macs the best workaround prior to Jamf Pro 10.23 would be to use the ‘Files and Processes’ payload and issue a softwareupdate -iaRcommand:

Even if this was fixed in Jamf Pro 10.23, to keep things simple, I would still remove that from the list and go for option 4, ‘Files and Processes’ with the softwareupdate -iaRcommand, if you only have Intel-equipped Macs to manage.

  1. Do nothing and educate your end users to keep their devices updated, maybe remind them from time to time with a notification via a Jamf Pro smartgroup and policy.
  2. Deploy a configuration profile to enforce automatic updates
  3. Use the ‘Software Update’ payload in a Jamf Pro policy
  4. Use the ‘Files and Processes’ payload in a Jamf Pro policy
  5. Package the full installer and use a Jamf Pro policy
  6. Use MDM commands
  7. Use any other 3rd party tool and or script, like nudge (see below)

But as you can see, I’ve just put option 4 (our ‘Files and Processes’ option which I just said to use instead), as well as packaging a full installer or using a 3rd party script, in RED. Why?

Well, because of Apple Silicon / M1. Since the introduction of M1 equipped Macs, ALL non-MDM programmatic software updates, on M1 Macs, require user interaction by a ‘Volume User’. The TLDR of what that means is basically that the user must be a cryptographic user, aka ‘have a SecureToken’. This means that every software update action which is triggering the ‘Softwareupdate binary’ ( does not apply to MDM commands – see below), will result in the popup prompt below on Apple Silicon Macs:

The fact that I’ve put ‘packaging the full installer and use a Jamf Pro Policy’ in red is not because of this popup, but because of the requirement of passing the credentials of a SecureToken-enabled admin in clear text in the command or script.

So for Intel-equipped Macs those options will still be feasible, but for M1 Macs this is not fully automated or goes against best practice in view of scripted credentials.

That said, I do like the nudge tool! It’s just a pity that M1 equipped Macs bring that extra challenge of user interaction to the mix. https://github.com/macadmins/nudge

So where does that leave us? What do we have left to build a future proof update strategy for macOS Big Sur which will work for both Intel and M1? Well, while the above discussed options may still work for you if you only have Intel-equipped Macs, I’m afraid I have to reduce my list to the 3 options below if you have M1 Macs in the mix:

  1. Do nothing and educate your end users to keep their devices update, maybe remind them from time to time with a notification via a Jamf Pro smartgroup and policy.
  2. Deploy a configuration profile to enforce automatic updates
  3. Use MDM commands

The first option is self-explanatory I guess, so let’s quickly have a look at option 2. “Enforce” automatic updates via a Configuration Profile…. what does that really do?

Ignoring the deprecated SUS URL option, the main setting in the Software Update of a Configuration profile would here be “Automatically install macOS updates”, which however, does nothing more than when you would manually enable it in System Preferences. As discussed here.

And this would then notify the end user and offer some options when updates are available.

This together with educating and reminding end users (with Jamf Pro Policies, additional Notifications, etc…) could be a strategy if you don’t require much enforcing of updates at a specific time.

But if you do need to really force updates without user interaction or passing of credentials in scripts and you do have Apple Silicon / M1 Macs in the mix… there is, as things are at this moment, only one option left: MDM / Remote Commands !

The reason why, is because Apple Silicon Macs can now use the ‘Bootstrap Token’ (if escrowed into MDM), to install updates triggered by MDM commands without user interaction. Yes, in all the above I mentioned that all updates on M1-equipped Macs require user interaction by a cryptographic user /Volume Owner, resulting in a prompt for the SecureToken-enabled admin account password. The exception is however that if the ‘Bootstrap token’ is escrowed into the MDM server, MDM commands to update M1 Macs do not require this user interaction!

And this is the only way, at the moment of writing this blogpost, to automate MacOS Big Sur updates on M1 Macs without passing or prompting user credentials.

All good right? We have a solution… ?

NO! Wait! I did mention that writing this blog post was like opening a Pandora’s box style can of worms right? Yes, indeed. Even if I’m presenting MDM / Remote commands to tackle both Intel as Apple Silicon Mac updates, we are not quite there yet, because (as things are at the moment of writing this), there are still a few roadblocks / issues.

First of all we have macOS Big Sur before 11.2. In macOS Big Sur pre macOS 11.2, there was an issue with the AvailableOSUpdates command. How?

Well, let’s first have a look at how the MDM commands to update a Mac work. When you instruct a Mac to check for updates via MDM there are actually multiple MDM commands involved. In sequence:

  • ScheduleOSUpdateScan – Instruct the Mac to scan for available updates.
  • AvailableOSUpdates – Instruct the Mac to report the available updates back to the MDM server
  • ScheduleOSUpdate – Instruct the Mac to download (and install) specific updates. This depending the option selected on the initial MDM action:
    • In Jamf Pro prior to version 10.29:
      • “Download Only” command would send the NotifyOnly action, which would download the update and notify a user of the update’s availability.
      • “Download and Install Updates” command would send the Default action, which would download and trigger the installation of an update.
    • See below for Jamf Pro 10.29 or later

This all worked well before macOS Big Sur. However, on macOS Big Sur prior to 11.2, there is/was an issue with AvailableOSUpdates command. Whenever this command is issued to macOS Big Sur pre-11.2, it would actually result in a situation where the available update disappears from System Preferences and the install via MDM fails.

The workaround here is/was to try rebooting the Mac to see if the update becomes available in System Preferences again, but that seems to be a hit and miss. Alternatively, deploying a full installer could be an option, but as discussed above, this would require to pass credentials in the ‘startosinstall’ command for M1-equipped Macs.

Now, that is fixed in macOS 11.2, however, there is more.

While the available updates don’t seem to disappear fro System Preferences (and fail MDM triggered install) anymore when an AvailableOSUpdates command is sent to devices on 11.2 or later, there is still some voodoo going on. If for instance our Mac is running 11.2, and we sent a ScheduleOSUpdateScan command, the Mac will report all available updates back to the MDM server. At the moment of writing this blogpost this would be:

  • macOS 11.2.1 Update
  • macOS 11.2.2 Update
  • macOS 11.2.3 Update
  • macOS 11.3 Update
  • macOS 11.3.1 Update
  • but also the macOS 11.2 Full Installer (full installer of the current installed version)

And this is where the fun really starts.

If we are sending a ‘Download Only’ command (pre-Jamf Pro 10.29 this results into a NotifyOnly action. See below for Jamf Pro 10.29 or later), and the Mac returns a list including a full macOS installer, the following ScheduleOSUpdate will fail. This both on Intel as M1.

If we are sending a ‘Download and Install’ command, the list of multiple available updates results having the ScheduleOSUpdate command triggering a simultaneous preparation of ALL updates… in turn resulting into a, what appears to be random, choice of which update to install…

On Intel-equipped Macs, this may result in a successful installation of the update, but without some time travelling skills, impossible to predict which one.

On M1-equipped Macs, the result is undefined. It may result in a successful installation, a prompt to enter the password or a notification leading to the System Preferences- Software Updates when clicked.

But, … there is more…

Let’s have a look at the release notes of Jamf Pro 10.29:

Jamf Pro now includes the following enhancements to the Download/Download and Install Updates remote command to make the update process more reliable and allow for updates without user interaction on computers with Apple silicon (i.e., M1 chip):

Download the update for users to install option—Jamf Pro now includes the DownloadOnly key when sending the remote command to computers with macOS 11 or later and the NotifyOnly key when sending the command to computers with macOS 10.15.4 or earlier.

Download and install the update, and restart computers after installation option—Jamf Pro now includes the InstallASAP key when sending the remote command to computers with macOS 10.12 or later.

In view of the issue with the list of available updates and the variety of outcomes discussed above, the results are still similar.

  • ‘Download Only’ will still result in an issue if the available update list includes a full installer of the current macOS version
  • ‘Download and Install’ now results into an ‘InstallASAP’ action and still seems to result into a variety of outcomes. However, the good news is that it seems to behave better on M1-equipped Macs, and more successful update installations. Yet, it may or may not install the latest or most recent available update, and it may still trigger the notification mentioning “A new update was requested to be installed by an Administrator” if macOS picked the full installer. If there is no Bootstrap token escrowed in the MDM server, the user may still be prompted for a password, but that is expected.

One more thing, if the installation an update triggers successfully, whatever available update of the list this may be, there is supposed (?) to be a countdown of 60 seconds before the Mac reboots to complete the update. Just like when you have no MDM involved, but you have automatic updates enabled, there should then also be a dropdown menu to allow the user to defer the update with one hour, try tonight or remind tomorrow.

It does seem however that this countdown / deferral notification does not happen and the Mac reboots out of he blue. Unless an app without auto-save functionality blocks the reboot…

That’s it! As mentioned in the disclaimer at the beginning of this post, my intent here is only to demystify the current challenges you may face when designing a strategy to update your macOS Big Sur Macs at the moment. Intel or M1-equipped.

Oh… but wait, what should we use now… well, if I had to choose at the moment, I’d go back to the first two items of my list:

  1. Do nothing and educate your end users to keep their devices updated, maybe remind them from time to time with a notification via a Jamf Pro smartgroup and policy.
  2. Deploy a configuration profile to enforce automatic updates

Just to save me the headache and wait to see where this goes with macOS 11.3 => 11.4 updates and beyond…

As always, if you liked the post, hit the like button, tell your friends about it and leave a comment down below!

Brgds,
TTG