Offering Big Sur and Monterey OS Updates Through Self Service

New Contributor III

I want to create policies that allow users to run system/security updates from Self Service so they can do it at a time when a restart is acceptable. I put together a test policy to update from 11.6.2 to 11.6.3. After scoping it to two test systems, I clicked on the update offers. The install job starts, but then just sits there with the installation cursor going round and round and no further progress is made. 

I've configured Software Updates, Restart Options, and under Files and Processes I've entered the following under Execute Command - 

/usr/sbin/softwareupdate -i  'macOS Big Sur 11.6.3'


For Monterey 12.2.1, I've configured a similar policy which executes the command -

softwareupdate --install 'macOS Monterey 12.1'

The results there are the same. 

Has anyone done this successfully, and if so, what was the syntax you used? Is there anything else I may have overlooked?

Thanks for your consideration.


New Contributor III

Hi @mlarsen,

I guess you've checked the guide that Jamf has and also the difference between Intel and ARM. My workaround for minor upgrade is:

  • Enable download and install updates for all your devices. The user will have the usual notification to restart or postpone the update.
  • Intel Devices --> follow the guide to enable the downloads and restart. You can enable deferral 
  • ARM --> stick to a profile to enforce updates and use Nudge

For major upgrades no matter if it's Intel or ARM I prefer to cache the installed of macOS in a policy and later a second policy to install the cached package. You can download the full installer in PKG with the following tool.

As the installer for Big Sur/Monterey is now installed in the computer, you can refer to your Applications folder or use Self Service.


New Contributor III

Hi @danitree ,

Thanks for responding. I have seen the guide and have configured the Self Service update exactly as it specifies, and am seeing the behavior I described. This is being tested on Intel Macs. I'm not sure what else I might be missing after following the guide.




New Contributor III

There's a lot of really useful information in this post as well :


Contributor II

Have you ran the policy in the command line with 'sudo jamf policy -id ### (number of the policy as found in the URL when in Jamf Pro)? 


I had a syntax error discovered doing it that way.

Contributor II

Also while I haven't built out for M1 Macs yet for intel mac I created a policy and in files and Processes I execute the command softwareupdate -a -i -R


What I will do is have a smart group that will have a similar policy only for M1 macs and will have the command for that as you need to often pass a username and password now. 


Hope this helps somewhat.

New Contributor II

Does anyone use the following in its own policy for caching minor updates? 

softwareupdate -d "macOS Monterey 12.5-21G72"

If so, do you know how to determine if the updates are cached successfully on Monterey? 

Valued Contributor

Surprisingly we don't force updates down onto users (we're global 24/7 and have users moving all around doing critical work) so pushing anything to users is typically a major no-no (life sucks). That's why we make almost everything available to users in our self service, so they can do them when they aren't working on critical stuff and have bandwidth better than what the local goat herder offers. Any suggestions on separate self service policies for x86 updates an ARM updates that users can initiate themselves (again, yes my life sucks because of stuff like this).