Forcing MacOS to Update

New2ThisWorld
New Contributor III

Hello World!

This issue is kind of weird since it should work, but it doesn't work.

 

We're using JAMF School as our MDM to control circa 230 M1 MacBook Air that have from MacOS 11.3 all through 11.5.1 We have 11.6.1 available for update on some devices and want to force update on every MacBook but, when you are on the device and choose "Install and Restart", it sends the command to the device, it shows the "Success" warning on the top right but nothing happens on the device side.

I've noticed this has some random reactions, sometimes it stucks on 13% during download on JAMF side, sometimes it goes smoothly through download but nothing happens on device side and once or twice you could get a prompt on device side asking for admin credentials. 

Does anyone have this feature working like it should ?

 

Best regards to you all!

1 ACCEPTED SOLUTION

Hello @MasterNovice!! Thank you for the Kudos btw 🙂
As far as we've discovered the problem is on the "disable App Store" option in one profile. With that feature ticked users cannot update and it cannot be pushed. 

SO, what we've done is, on the main profile where we have the global restrictions, instead of restricting App Store on Preferences tab we restrict it on the Apps tab and removed the admin credentials for update option. With this, a standard user can access to the updates via System preferences while still not having access to App Store. Some users did upgrade to Monterey with setup and, until now, we cannot see other way to allow users to upgrade, but this will always require the users to upgrade whenever they want, the push update it still not functional, but it is better than no updates at all.

 

Also, we tested Monterey on our environment and it actually helped with some other issues we were having, so, no restrictions on this 🙂

View solution in original post

14 REPLIES 14

Fluffy
Contributor III

This is something that was hit or miss with me when I was testing in the summer. I had one that would rarely work, while the others would show up to 10%-12%, then drop. The device would show no signs of any processes or errors.

Dug into it at the time and have forgotten most of what I read, but at the time I was convinced it was a Bootstrap Token issue. I don't know if that was actually the case, as I haven't checked on it since.

I'll try this myself to see if I have any success this time and might be able to contribute something besides a "me too".

New2ThisWorld
New Contributor III

Please let me know as soon as you have something, We wanted this to be fully operational since we've found 2 massive security breaches that will be fixed in the Monterey (supposedly) and we want to enforce this to every machine.

jpeters21
Contributor II

I have been told by Jamf the rushed out 11.6 update is the culprit, apparently it can only be initiated on the client. That said I my ecosystem consist of a single M1 so far, and I have heard from those with many more that M1 macbooks have been an issue for all updates. 

Yes that is true, appart from the apps that has been bought through VPP nothing updates like it should. Like I said above we have 230 M1 and there are 5 diferent versions of macOS, impossible to command, schedule or predict. 

does Jamf have an official stance on this yet or at least acknowledge its an issue? 

No as far as I know, there's why I created this post on the community. Still trying to see something from JAMF side.

Fluffy
Contributor III

So, scratch what I said about Bootstrap tokens. I think I have a separate issue altogether. On the Jamf side it shows up to twenty something percent, then goes blank. Trying to manually update on the device gives an error message saying to check connection. Both Intel and M1.

My work device was able to do updates not that long ago, but it still had profiles from Jamf Pro at the time. I've got more research to do...

ryan_w
Contributor

We have issues with updates and JAMF School too both iOS and MacOS.  Unfortunately I don't have any tips to help.  I really wish they would let you schedule them somehow and have a deadline.  Our users like to ignore them forever and we have to send out emails asking them to update and then follow up on it.  Then do the same thing every so often.  

New2ThisWorld
New Contributor III

We had that issue when we had Windows environment implemented, but since Windows has the good thing of starting to slug when it lacks updates they would come to the IT Office, so, that  wasn't really a problem to us.
Theoretically you can force update, or just schedule but here it just has no action. At the moment the only thing that I can do is remove the App Store restrictions and do the update manually (wich will be a pain the in the behind).

MasterNovice
Contributor

Just jumping on the bandwagon here to Kudos all the replies for visibility and add my case. We've struggled with managing updates and upgrades to the Macs for a while, and see the exact same inconsistencies as @New2ThisWorld is seeing. One of the odd things for us is that, is a device is on say 11.1, it might have 11.2, 11.3, 11.5, 11.6 advertised in Devices > Updates for the device, however, on the device itself, only the most recent version is advertised. And, even if the user acknowledges the software for install is OK, they're either prompted for admin, or for whatever reason the update never completely downloads and updates. It's never worked consistently or well, and there's limited ability to troubleshoot it from the console. I've submitted a few tickets to support for documentation or guidance on what the expectation is here, or how to improve our success rate with updates and the tickets are being closed automatically after several weeks with no response. I just want a working, validated method of patches and minor version updates to be offered when available, and auto install after user is notified of pending install. 

 

On an aside, is anyone deploying Monterey? Are you just blowing it to advertise through softwareupdate? Will it install for non-admin users if you've pushed a download+install from Devices > Updates? Are you blocking Monterey, and if so how are you doing that in Jamf School? I have questions.

Hello @MasterNovice!! Thank you for the Kudos btw 🙂
As far as we've discovered the problem is on the "disable App Store" option in one profile. With that feature ticked users cannot update and it cannot be pushed. 

SO, what we've done is, on the main profile where we have the global restrictions, instead of restricting App Store on Preferences tab we restrict it on the Apps tab and removed the admin credentials for update option. With this, a standard user can access to the updates via System preferences while still not having access to App Store. Some users did upgrade to Monterey with setup and, until now, we cannot see other way to allow users to upgrade, but this will always require the users to upgrade whenever they want, the push update it still not functional, but it is better than no updates at all.

 

Also, we tested Monterey on our environment and it actually helped with some other issues we were having, so, no restrictions on this 🙂

So, updates regarding this issue, and good ones!!

With JAMF School updates as it can now store bootstraptoken on the server side, making it able to update directly from JAMF without disabling the App Store restriction!! The problem here is that every device had the bootstraptoken stored locally and the only Secure token was with the local admin. So, what we had to do is, run this command

sudo profiles install -type bootstraptoken 

to send the bootstrap token to the server side and, from there on, you can Update from the JAMF side!

Now the only issue is for me to do a script with that since I'm having an error with the credentials, for some reason it's not running from root.


Now the only issue is for me to do a script with that since I'm having an error with the credentials, for some reason it's not running from root.

I've noticed the same problem, as well as it being an issue in Jamf Pro when scripting. I haven't been able to find a solution to this yet. My workaround so far has been to package a self-destructing script and launch agent/daemon, then deploy it. If you find out any more about this problem, I would be interested.

And congrats on your progress! We still haven't gotten it to work at all, as it has somehow gotten worse.

New2ThisWorld
New Contributor III

Try what I wrote above manually and it will work. The problem there was that it needs to be escrowed to the server side. I noticed that if the end device has Big Sur it might not work at first but it will work eventually, with Monterey was straight forward.
As soon as I have updates regarding this issue I'll post here :)