@jtrant I believe that just added the ability to use the schedule an update remote command. Still does not offer anything in the way of user notification. How I understand it is the Mac just does its thing and once the updates are downloaded it reboots, or waits for the user to tell the Mac to do updates. No user notification of any sort. Also JAMF still has not added support for this. I am not beyond missing information, but this is how I understand it right now.

@AJPinto Right you are that these new MDM commands and fixes to them are only as good as the JAMF implementation of them.

Our Intel fleet: 99% of live devices upgraded. Using the softwareupdate command.

Our M1 fleet: 50% of live devices upgraded 😞 Using "Software Update" configuration profile with automatic updates "forced". Mass action updates don't work any better.   

I keep reading we can use bootstrap tokens to update but as far as I can see this is only the case if we GUI-login - not remotely. 

I'm losing my hair here.....

Its amazing how unreliable it is on M1 Macs right now to manage updates.  I've tried numerous scripts from the community with limited success.

Anyone get anything to work reliably?

We seem to have a workflow down that works for both M1 and intel- after exhausting every option.  We had nothing but problems with minor updates (policy, command, script etc) until we got all devices on 11.6 first.  Not sure what has changed, but complete nightmare running updates on 11.3 and 11.4.

Anyway, caching the full installer (11.6.1 as of today) is the only thing that consistently works.  We opted for sending out the installer in a policy as opposed to the fetch full installer command (is that even working these days?).  After sending out the installer, the basic startosinstall script works for intel devices, but a --passprompt or --stdinpass script is needed on M1s.  We go with --passprompt as we don't want to include the admin password in the script.  And it is after the update to 11.6 is complete that we then run the minor updates.  softwareupdate -iaR in a policy works on both M1s and Intels, but so does mass command.  Once again, neither seemed to work consistently before getting all the devices on 11.6.1.

And of course the accounts running all these updates have secureToken enabled on the logged in user and bootstrap token is supported and escrowed.

Have no intention of caching a full installer for every update, so curious to hear how things go with Monterey.

@andrew_betts Thanks for sharing your solution.  I'm guessing you are caching the full 12gig installer on each machine?  How do you deal with the remote workers on slower internet connections.  Does the full installer take out the users machine longer than the 20mins the 3gig installer does?  For us I can't see us pushing the installer out to our fleet.  I am using the softwareupdate cmd with -I -a -R --force and using jamf notifications giving users 48hrs to update themselves or at 7pm local time the device will update itself.  Emails, CHN request and documentation is submitted so users have plenty of notice.  Hopefully 12.x is better.

Yep, full 12gig installer unfortunately. It hasn't been taking long, although staggering to only so many devices at a time.  We only cache it on prem so that we aren't using end user's at home data.  We do this by just changing the distribution point from default (cloud) to our on prem distribution point.  You could also change the client side limitation to business hours. 

The end users run the startosinstall script in SS at the time of their choosing so it doesn't interrupt anything.  And I haven't tried it yet, but could certainly throw the startosinstall into jamf helper for a little pomp & circumstance.

edit- looks like it takes us around 20 minutes to cache the full installer over wifi, but that is dealing with 5minute check in intervals, so it could actually be anywhere from 10-20 minutes.

Anyone else having a problem with this softwareupdate command on an M1?

I just started testing really, not sure if this works on the M1 or if we have to use softwareupdate -iaR... Seeing if anyone else already has knowledge on it.

Apply are moving away from the software update command for Silicon. I would try and use another method going forward.

If you don't want to prompt the user at all, you can make a bash or python script that runs the Download and Install Updates management command for you. Add the script to a user interaction policy  to give the user the option to defer the update. 

@bwoods 

Looks very promising.
Would the "Default" also be possible to switch to "InstallLater"?

I would recommend against doing this, but if you are going to do it you need to research salting the password. If you dont salt (encrypt) the password it will be going to devices in plane text and many savvy users know how to pull information from scripts. Unless you like the idea of users having your API Username and Password make sure to encrypt the password.

@AJPinto there's a post here about encrypting the password for anyone interested. I'm interested to know why you wouldn't recommend doing this. I'm building a list of pros and cons before I put this into production.

@fredrik_virding I wasn't able to get the "Default" flag to work, but some people seem to have it working. Check out the hyperlink above. The OP is using that action.

its really just two reasons.

1. How JAMF manages API access is not very secure. You have to go out of your way to encrypt the password which is fine for those of us who are savvy. However many admins will not know how to do this properly. That and JAMFs access control sucks, if that API user and password get it it opens many doors. 

2. With how frustrating working with MDM commands is especially in relation to OS updates. This is not how Apple wants issuing MDM commands to work. So there is no telling when or if apple will break it. Also there are plenty of complications like you mentioned with default flag not working. 

To be honest, I am all about blazing a trail. Going where no documentation has gone before, going outside of the supported realm. However we are paying too much for JAMF to be having to do their job for them.

JAMF is supposedly working on making the work flow to issue these MDM commands from policy, but lord only knows when we will actually see it come to light.

https://community.jamf.com/t5/jamf-pro/managed-software-updates-using-deferrals-via-a-mass-action/td-p/249821?emcs_t=S2h8ZW1haWx8dG9waWNfc3Vic2NyaXB0aW9ufEtWNzRHODdVOEZXWEdQfDI0OTgyN3xTVUJTQ1JJUFRJT05TfGhL

I hear you, but if the MDM provider isn't giving me any solutions, I have to bend it to my will. That's the benefit of the API...just encrypt those passwords. Looking forward to Jamf providing a solution for this.

I use the "install" action btw.

To add a #3 to @AJPinto 's list - if you ever decide to restrict the IP addresses allowed to access your JSS console then you will find the API doesn't work except from those IP addresses. That kind of precludes using the API from arbitrary endpoints.

Ah! I see!

So that will simulate "InstallForceRestart" i assume?

We have an always on VPN (Palo Alto Global Protect) , so that's not much of a problem for me.

@fredrik_virding, from testing it seems to have that behavior, but I do see people using "installForceRestart" directly in their API commands though. Doing more testing on this...

With the "install" action it takes anywhere from 20 minutes to an hour to reboot the machine. I'm trying to lower that interval, so that the user won't be confused.

@bwoods 
Tried running the InstallLater, and it did download, and install, but no notification about a restart pending. 

However, manually going into Jamf and running a remote command, and there selecting InstallLater, triggered that notification about a "manage updated". 

Curious behavior, but close to working. 

@fredrik_virding, not sure if that action is fully supported. You can use user interaction or jamf helper to inform the user of a pending update though.

Sadly, even when I use this method, my target computers still prompt for admin credentials and I can't for the life of me, figure out why. They were deployed via MDM to begin with, they are communicating with the server as expected, and their Bootstrap Tokens are escrowed with our Jamf server, and yet I get this pop-up every time I use the actual MDM command in the Jamf Console or use the above script.

I can't for the life of me figure it out!

I finally resolved the admin authentication, but now I'm dealing with a fully inconsistent response to my attempts to initiate the update.

I can use either the Jamf Console or an API Command embedded in a policy to trigger the update. The results in the computer management logs are the same either way:

ScheduleOSUpdate
AvailableOSUpdates
ScheduleOSUpdateScan

The problem is, sometimes it works, and other times it doesn't. I haven't figured out, yet, what I can do to consistently make the update command stick and proceed.

At first, I thought it was the update manager getting stuck, and I came across this command that, once issued and the computer rebooted, seemed to allow the update to go through:

sudo rm -rf "/macOS Install Data"

But that only worked for a couple of my test cases. I then found an alternate solution that involved sending this command in advance:

sudo launchctl kickstart -k system/com.apple.softwareupdated

Which, again, worked for several computers. This one did not required a reboot, so I added it to my API command script to hopefully fix the problem before it became a problem.

Unfortunately, after having updated 20 computers through a variety of the above fixes, I now have 10 more computers that seem resistant to update at all, and thus I'm back looking for another solution, because apparently nothing that I've done previously was actually a solution. They were likely all placebos, and I am thinking I was just lucky with the first 20.

If they would at least all succeed or all fail, that would be something, but this roller coaster of success and failure is just maddening.

To bypass the concerns about username/password info via clear text.. Could we create a service account that's only permissions is to "Send Computer Remote Command to Download and Install macOS Update."