Hello, since Ventura is now beyond it's 90 day deferral, is there anyway we can have those users still on Monterey upgrade to the latest security patch 12.6.3 within Monterey? We have used OSUpdateNotifier script in the past and used minor/major flags however the default update showing within System Preferences is now Ventura, not Monterey update.
Curious how other orgs are proceeding with security only updates at this point.
+25@duff2481-1 Because the initial release of macOS Ventura is now more than 90 days old it is no longer possible to prevent it from being offered in Software Update so your users still needing to update will need to drill into the "Other updates" (or whatever it's called) blue link in the Software Update panel to find the Monterey and Safari updates.
Your other option would be to set up a Self Service policy to run the erase-install tool (ignore the name, it'll do updates too) to install the latest version of macOS Monterey using the full installer.
+13We had the same issue. Our restriction policy is set to defer as well, but some devices can see the update. Since we can’t just uncheck that without going through a change process, I just created a clone of the profile and unchecked the defer and moved devices in there and the update will show up after a few minutes. Once it’s updated, just move them back. I’ve used erase-install and works, but it’s a 12gb download, but doesn’t always work. It downloads the update, but it fails to run it.
+26You can issue OS updates from JAMF and not update to Ventura, you cannot prevent users from updating to Ventura if they so choose.
- or -
PS: Dont forget to deploy Safari as that may not install with this command for Big Sur and Monterey. Safari can be deployed with a package.
I no longer attempt to issue updates with CLI. Though you can push the OS package, and use --startosinstall to install whatever version you want on Intel Macs as well as being able to use the softwareupdate binary.
You can issue OS updates from JAMF and not update to Ventura, you cannot prevent users from updating to Ventura if they so choose.
- or -
PS: Dont forget to deploy Safari as that may not install with this command for Big Sur and Monterey. Safari can be deployed with a package.
I no longer attempt to issue updates with CLI. Though you can push the OS package, and use --startosinstall to install whatever version you want on Intel Macs as well as being able to use the softwareupdate binary.
is this reliable? I'm currently reviewing the erase-install option however I would prefer a more 'native' (simplified) tactic especially if security comes back and says to push as quickly as possible. Also how's the notification to users look? I"ll go do testing in QA also.
We had the same issue. Our restriction policy is set to defer as well, but some devices can see the update. Since we can’t just uncheck that without going through a change process, I just created a clone of the profile and unchecked the defer and moved devices in there and the update will show up after a few minutes. Once it’s updated, just move them back. I’ve used erase-install and works, but it’s a 12gb download, but doesn’t always work. It downloads the update, but it fails to run it.
Thanks, I'm working to deploy erase-install in our QA environment and also say the comment from @AJPinto with using mass updates. The only thing there that I struggle with is the notification to end-users.
+26Thanks, I'm working to deploy erase-install in our QA environment and also say the comment from @AJPinto with using mass updates. The only thing there that I struggle with is the notification to end-users.
Mass action does notify users, and will let users defer updates if you tell it to.
Under install action
See this link for more information on software update MDM Commands and behavior.
ScheduleOSUpdateCommand.Command.UpdatesItem | Apple Developer Documentation
Though for a 0 day I would say its more important to install the update, than to make sure users are happy about it. We are here to manage an environment, and secure devices, not keep users happy. I tend to use JAMF Helper to notify people, and issue the MaxUserDeferrals command with 3 days to defer. If users ignore and don't install the updates they can deal with the InstallForceRestart command that comes after the deferrals have been used up.
You can use this tool for Major Upgrades and Minor Updates. It's been working well for me. https://github.com/Macjutsu/super
You can use this tool for Major Upgrades and Minor Updates. It's been working well for me. https://github.com/Macjutsu/super
I've briefly looked at this tool. The real puzzle is why does apple make this more difficult than it should be and how to choose the right tool/method for your deployment. rabbit trailing a bit but..... OSupdatenotifier, Nudge,erase-install,super etc.... all aim to accomplish the same goal: upgrade your machines and notify your users of said update/upgrade.
+26I've briefly looked at this tool. The real puzzle is why does apple make this more difficult than it should be and how to choose the right tool/method for your deployment. rabbit trailing a bit but..... OSupdatenotifier, Nudge,erase-install,super etc.... all aim to accomplish the same goal: upgrade your machines and notify your users of said update/upgrade.
To be honest, because Apple does not care. Apples core philosophy is to empower the user. As years have gone by Apple has steadily removed more and more options to be able to manage the devices. Apples vision is for us to manage devices only with their tools. The problem is Apples tools are usually very poorly designed, like with the MDM workflow for software updates.
On a side note. Apples ideal is also for every device to be on the most current release of macOS, unless a USER wants to not upgrade for one reason or another. This would be great if Apple actually worked with vendors and business partners to make sure stuff was tested, and the new features actually worked. Where is platform SSO? A Major selling point for Ventura, 5 months later and still not in use. Rapid Security Response? and so on. The major features of the new macOS's usually take 6 months to release after the OS that would contain them. Then another 6-18 months for vendors to support them. JAMF just added support for Background services 2 weeks ago.
Apple wants to be very rapid adopt, but wants to put no effort in to making rapid adopt attractive for anyone.
+8is this reliable? I'm currently reviewing the erase-install option however I would prefer a more 'native' (simplified) tactic especially if security comes back and says to push as quickly as possible. Also how's the notification to users look? I"ll go do testing in QA also.
It is not reliable. It really should be, all indications is that it should be, but it will fail with no explanation at any time.
+26is this reliable? I'm currently reviewing the erase-install option however I would prefer a more 'native' (simplified) tactic especially if security comes back and says to push as quickly as possible. Also how's the notification to users look? I"ll go do testing in QA also.
As @piotrr pointed out, no its not what I would call reliable. At best, it will do exactly what you tell it to do. At worst macOS updates will fail and JAMF does not use the MDM Commands to check OS update status for some stupid reason.
It wont hurt to push, and has about a 70% success rate. However things a simple a user having a document opened that needs to be saved will break the force install and reboot command (its more or less politely asking and not forcing anything).
+4If I can chime in here. Mass Action commands are what Apple will always defer to despite them not being at all reliable and impossible to manage in any fashion, even with JAMF. Mass Actions are a complete failure by Apple. They ignore what is important to the Enterprise users and Administrators.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
