Block Ventura

[auser]

Hi, 

New admin looking for some advice. What is your typical stance on major upgrades such as Ventura? Do you guys have a normal workflow that blocks these updates for a certain amount of time or do you run with it on day 1? I am curious to see how other admins handle these updates. 

[PhillyPhoto]

It's not forcing the upgrade, there's just no way to block it anymore. I've submitted a feedback for a 180 day deferral option, but we should be able to block it completely. There were a couple suggestion from Apple to inhibit the upgrade:

• Block access to Software Update in System Preferences, but then users don't have access to the GUI for security upgrades to Monterey or Big Sur.
• Use the restriction that only allows admins to run the upgrade, but most of our admins are developers and executives that want the latest and greatest as well rendering that option useless.

[bmack99]

yeah i should have clarified that statement. They aren't actually forcing it, so much as presenting it to the end users(even non admins) and giving them the option to install it. Meanwhile our hands are tied and cannot prevent it. I am curious about the 2nd option you mentioned with only allowing admins to run it, this may work in our environment as we stripped admin a couple years back. Would this be found in the Restricted Software section in jamf or under a config profile payload or somewhere else?

[PhillyPhoto]

It looks like Apple has been setting this up for a while too with the removal of the ignore flag in the softwareupdate binary:

---

You can still use softwareupdate --ignore on macOS Catalina 10.15.7 or macOS Mojave 10.14.6 clients to prevent installation of macOS Big Sur or macOS Monterey, but the --ignore option is no longer available in macOS Big Sur and later.

As far as the admin requirements to update preferences, it's in the SoftwareUpdate docs under the "restrict-software-update-require-admin-to-install" key:

restrict-software-update-require-admin-to-install	If true, restrict app installations to admin users. This key has the same function as the restrict-store-require-admin-to-install key in the com.apple.appstore payload.
boolean	Default: false

[jamf-42]

We have blocked without any rogue upgrades by:

Blocking software update in System prefs (yes.. not perfect, but, it works, this also carries the deferral payload)

Restricted Software for: 

Install macOS Ventura.app (with block and delete, if you push your defer back far enough you WILL get the app install and not the major / minor update) 

osinstallersetupd process (this stops the upgrade via System Prefs and can get a bit chatty if you email on this and far from perfect)

softwareupdate binary ( again, not great, but it works) 

if someone gets past all that.. then promote them to one of your beta testers 😎

[bmack99]

if you are blocking software update in System Prefs how are you handling minor updates and security updates? we are currently using something similar to Nudge to force our users to update, through Sys Prefs > Software Update.

[jamf-42]

security update are still allowed (X protect etc) thats another config profile managing download of updates etc. 

point updates are also blocked, but the goal here is to stop mass upgrades.

For point updates, the joys of MDM push (which ignore the delay etc) and yes its far from perfect.. but we have to work with what Apple and JAMF give us.. i'm expecting macOS13 and MDM updates / Mass action / Rapid response things.. it will get better.. maybe, hopefully.. 

[AJPinto]

To be clear this has nothing to do with JAMF, the max deferral of 90 days for OS Upgrades is all Apple. Apple has been very clear in what they were doing, and this is honestly very on brand for Apple. If you guys are unable to test and validate a new OS in 90 days the macOS platform may not be for you and you should probably start considering alternatives like Windows.

[bmack99]

haha oh ok. nice little dig there. To be clear, no one said or inferred this was a Jamf thing. Also, to be clear, we run Windows on 90% of our workstation devices, the other 10% are macOS. Ideally we could continue on like we have in the past with testing and vetting a new majorOS over a year's time frame, similar to how we do with Windows(still on Windows 10 by the way). However it appears Apple doesn't want to allow this, and that's fine. But to have some asinine comment like that helps nothing. I think you will find there are many others who are not early adopters like me who also have a beef with this new way of doing things. 

[AJPinto]

...but we have to work with what Apple and JAMF give us...

---

JAMF was mentioned specifically. JAMF is far from being without blame, the logging on OS Update MDM commands is horrible, we still cant used a policy to deploy them and so on. However, the MDM Framework is totally on Apple. JAMF can only use what Apple makes, Apple is just making a crappy tool.

We are literally 99% Windows. I have worked very hard to get our Macs managed like Macs, and finally have good traction. Though OS updates for us is still a very sore spot with how poor apple has the solutions built. I am actually in the office right now trying to figure why OS updates wont run on 3 of my lab devices from the MDM commands.

Apple has made it clear, either invest in the platform (macOS) or leave. Yes Apple releases new versions of macOS annually, however these are more akin to Window's feature updates which come in spring and fall rather than Win 7>8.1>10>11. MacOS also has a spring feature update usually with 13.3 (or 1#.3 rather) that you just dont hear much about. 

[PhillyPhoto]

The issue isn't even just validating software against the OS, we have a change freeze at the end of every year that carries through January. We can't push out any new software until after that time frame, so as it stands today, there's a week between the 90 days from Apple and the earliest we can push updates without escalating up to VP levels.

The biggest headache may be behind us with the transition to System Extensions. We didn't deploy Monterey on some systems until June due to one of our security software's vendor taking forever to deliver a compatible product.

Like @bmack99, we have a majority Windows environment, so the alternative has already been considered ;p.