How are you deploying Monterey in Jamf School?

MasterNovice
Contributor

Just wondering how Jamf School folks are upgrading to Monterey (especially if you have standard users! 🙂 

Are you deploying .app from the Store? 

Are you calling softwareupdate?

Deploying a custom package uploaded to Jamf (how did you work around the size limitation?)

Any gotchas you ran into not related to the above? Seeing a couple odd errors on M1s "You must provide authorization for this volume by setting it as your startup disk" or simply "MacOS12 cannot be installed on this computer" for both admin and standard with failvault off. 

5 REPLIES 5

khurram
Contributor III

Make sure it is compatible with all the apps being used at school. Adobe has not yet listed Monterey as recommended macOS. We are sticking to BigSur 11.6.2. Die another day.

Thanks! We just got Adobe CC and apps on a smooth deploy so I appreciate the heads up. Still working on getting the deployment of the OS upgrade going in test, but will def check these. I know on my own machine, Parallels wasn't working in Monterey, but I also don't have latest version (I think this was resolved in current version of 17+)

Fluffy
Contributor III

After attempting a Nudge deployment that turned out a disaster, we will not even be thinking about deployment during the school year. Over the summer break I will be updating student devices to Monterey, either manually or by Apple Configurator 2. Staff devices will be the tricky part. Very much looking forward to the Erase All Content and Settings feature on all devices.

And for elaboration, the problems we had when using Nudge were things like bootstrap tokens not being escrowed, hanging downloads that sometimes would magically work after restarting the device, and students actually panicking if they weren't able to update.

I have upgraded three MacBooks to Monterey for testing and have had no issues for the most part, other than a graphical bug (waking MacBook from sleep with a secondary display induces oversized text in the menu bar on external screen), it has been smooth.

I really appreciate the feedback; helps to know some others are working through similar issues (these sound like similar issues!) Our focus is staff, who are standard users, so shaping experience is a part of it. One button erase all does sound really promising for labs and student machine refresh! The guide from @talkingmoose on that using startosinstall here is what I was starting with, just without the --eraseinstall and --newvolume arguments. I assumed it would be as simple as pushing the app from the VPP store, the scripting a call to run startosinstall, but I'm not having success with that. Often just sits at prompt with no acknowledgement, nothing in install.log, no activity for download or install processes in activity monitor. Shees. Sometimes it's a little difficult to fill in the blanks for these guides where Pro is leveraged for some part of the process, and an equivalent isn't in School. 

We have one Intel to test with, and one M1 to test with. The process seems to work well with the Intel, but I think we're finding the same with token issues on the M1. Assuming it's the same issue from a while back where the admin user created with the DEP profile isn't always the first to log in, so the standard user gets the secure token. Often in this case we still see Jamf School report that it has a Bootstrap Token store for the device, which I guess is established with the standar tokened user? But a lot of things requiring elevation or ownership seem to still not work. I'm assuming it's because the admin account doesn't have a secure token, but idk. Still trying to wrap my head around it. We have the sysadminctl token commands for getting the token to the admin account, but it's a clunky process, requiring making the tokened standard user admin, then running the commands. 

Good info on Nudge. Nudge just kind of enforces softwareupdate though, right? So if the user is standard, a major update would still require an admin prompt? We also see downloads interrupted or just failed. Guessing sleep or power policies, wireless auth expiration, something... I'd spend time looking again at third party solutions like Munki or Nugde if I thoght they'd bear fruit. Currently I just don't understand what obstacle they'd be working around, because I don't know what he problem is ha.  

So to be clear, for your Big Sur or < to Monterey, you're you're currently manually upgrading devices? 


Good info on Nudge. Nudge just kind of enforces softwareupdate though, right?

Right. Nudge prompts the user when there is an update required by us (at the time the minimum OS requirement was set to 11.5), and clicking the update button opens System Preferences at the Software Update window.


Currently I just don't understand what obstacle they'd be working around, because I don't know what he problem is ha.

The problem I have been trying to avoid is bogging down our access points with that much traffic all at once. We do not currently have a content cache server setup, but will be looking into that in the future. Nudge was a way to make the user aware of the update process and able to do it at a more convenient time.


So to be clear, for your Big Sur or < to Monterey, you're you're currently manually upgrading devices? 

Currently I am not upgrading any of our devices to Monterey except for testing. Come summertime, if the content cache server is not sorted out, I will most likely be upgrading by USB/AC2.


The guide from @talkingmoose on that using startosinstall here is what I was starting with, just without the --eraseinstall and --newvolume arguments. I assumed it would be as simple as pushing the app from the VPP store, the scripting a call to run startosinstall, but I'm not having success with that.

You may want to look at the erase-install Github. Despite the name, it is useful for updating/upgrading Macs without erasing anything. I was in the process of testing it although, again, it won't be as useful until we have a content cache server.