Hi,

I found our issue, we had a Restrictions payload included on a very old profile.
After removing that payload it was solved and we are now able to defer Major Updates as we like.
Note that the old Restrictions payload had no Update deferral option configured, but it seems it is enough to cause conflicts with other Restrictions config (even custom ones in my case).
Best regards!

Here is how our Admin set up our deferments. We have 220 devices, but it only installed on 175, so not all devices have it blocked. When you check the logs, they say cancelled. For one of them that said cancelled, I removed their device and added it back and it switched to complete, but he still sees the Ventura notification.

I had deferment set for Major Software Updates (90 Days) and the users machine was on macOS 12.6.2.... They just upgraded to Ventura today. Suffice it to say, I'm very very upset.

@R_C Be very sure that you do not have multiple Configuration Profiles that include different update deferral settings. If you do the results will be "undefined".

Here's a post from @RobertHammen on the MacAdmins Slack channel (hopefully the same RobertHammen on Jamf Nation) that should help determine that:

---

For those seeing inconsistent results with your Deferral profiles... here's a way to check if the key is being set more than once, with conflicting values. This will happen if you utilize a Jamf Restrictions profile, and create a separate OS deferral profile.Run the following command, and search for the key: forceDelayedMajorSoftwareUpdates (or forceDelayedSoftwareUpdates if you're looking to restrict minor updates) - if it's set in more than one profile, that's your issue.

sudo profiles show -output stdout-xml

---

Nope, just 1 profile scoped to a machine at any given time, and all of them block major os updates by 90days. (Although I wish apple made it so that I could block the **bleep** thing forever until I am ready to let them upgrade. Not the users machine, not the users call.)

User was running 12.6.2, so unless Apple re-introduced the update issue in 12.6.2... it shouldn't have upgraded.

User was running 12.6.2, so unless Apple re-introduced the update issue in 12.6.2... it shouldn't have upgraded.

Got a couple that slipped through the cracks as well. I have a 90-day deferral and Ventura Restriction in place. 12.6.2. Notified users not to upgrade, but not everyone reads emails.

13.1 is appearing as a Software Update (Delta?).

Happy Holidays.

This is the problem with the Restrictions payload that has 50 different options that could be different across configurations throughout a company. You should be able to select which specific restriction you want to enable without having to have to duplicate settings to account for everything. So for example, you want to defer major OS updates, but you have profiles for some people to use external media and others not to. Now you could have 4 profiles, 2 without any deferral options but the different USB drive access, and 2 more with deferral options and different USB drive access. This is also an issue in Configurator.

I'm late to the party, but am seeing similar behavior. Restricting Ventura, Have Major Software Updates deferred for 90 days. macOS 12.6.2 clients upgrading to Ventura through Software Update. This is extremely frustrating as we haven't even begun testing Ventura yet. I also have a ton of machines on 12.1 - 12.6.1 that are showing on Qualys Vulnerability reports that I need to upgrade(another frustrating topic altogether). Has anyone found a method to completely block Ventura while still allowing minor updates?

Unfortunately my friend, you are out of options. MacOS 13 has been out for 90 days, there is no way to differ any any longer. Apple was very clear in this, I am sorry to hear you have not even started testing Ventura yet. Thankfully I have found the update to not be very bad.

Just for my own understanding: Apple is essentially forcing a major upgrade after 90 days deferral. Is that a fair statement? Essentially there is no way for a mac admin to prevent a major OS update now, like we used to be able to. This is baffling to me if true. I understand there are early adopters, but 90 days IMO is not enough time for certain organizations with older and even newer(security toolsets) to test and validate no issues prior to turning it loose on their end users.

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.

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?

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:

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 😎

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.

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.. 

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.

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. 

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.

...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. 

Apple is not forcing the update, they are simply preventing us from blocking it. Its on to users as to what they do at this point.

Generally speaking 3 months is 25% the way though the life cycle of any macOS release. Considering Apple only patches all security findings in the current release of macOS, it should be all of our goals to get to current as soon as possible. The biggest sin I find in this is apples insistence in releasing the new OS going in to 4th quarter with many people out on holiday during the testing period. I feel Apple does release new versions of macOS too frequently. They should release new OSs every other year like it used to be in the past rather than a new OS for the sake of releasing a new OS every year.

As for 3rd party vendors, we have had the same issue. We got rid of the vendors that took their sweet time to validate macOS. Its an investment thing, not all vendors are really invested in macOS as a platform. Personally I think Apple should be working harder to encourage participation, and Apples AppleSeed Program is total crap but it what we must deal with to use Apple Products. 

I am sure we would both agree on how horribly Apple is handling all of this. My main point is Apple has been very obvious about this shift. We had access to Ventura in June. We had from June to October for testing along with all of our security vendors. People who did not test in that time ignored the writing on the wall. I cannot stress enough, submit feedback.

Product Feedback - Apple

As far as older organizations. I work in a very old company in the finance sector that is very much stuck in its ways. There are 7 security clients on our devices, as well as a full testing and validation parity to our windows environment which is 99% of our devices. We had Ventura fully validated by Mid November less one security tool. That Security tool is now in the process of being replaced. I simply explained what was going on with our security partners in October, and made plans. Some stuff needed to be updated, we had to deploy some nonLTS releases but we got it done. At this point we are about 25% Ventura, but there are no concerns about any user updating.