Can't stop Ventura upgrades any more

[AVmcclint]

I was severely disappointed with Apple's new push to treat Ventura an "update" instead of an upgrade. Luckily I was able to block the upgrade on our Macs via Restricted Software and a Profile to delay the major updates for 90 days and it seemed to work very well until suddenly one day in December I started seeing lots of Macs appear with the new OS. I have not changed anything with the existing measures to kill and delete the Ventura installer, so I can only imagine that Apple changed something in the ASU mechanism to slip it through when Macs install Monterey updates. I think I can narrow it down to the 13.1 update. Now we're up to 50+ Macs running Ventura and I have no way to stop it from proliferating through our organization. It's worse than a virus! We aren't even close to being able to test all our apps and tools with Ventura.  

Is anyone else out there having success at stopping Ventura from getting installed? 

[AVmcclint]

I even created a Policy based on a smart group to detect and delete the Install macOS Ventura.app but it has failed to find a single instance of the installer sitting in /Applications (other than on my tester Macs). I think the installer is being cached in a hidden location to evade detection.

[jackofOS]

I've been in the middle of troubleshooting other minor update issues on Monterey and ran into this. I currently restrict the Ventura installer via the Restricted Software settings in Jamf Pro, as well as set software update deferrals to 90 days but ran into one machine getting upgraded to Ventura. The one machine that this has happened on so far was when I updated on the specific machines inventory record by clicking the Download and Install Updates button. This didn't happen when installing updates via a Mass Action to a specific version (although this was one of the issues that I'm troubleshooting because it doesn't always work), or when I built a macOS Monterey installer .pkg that I deployed via Policy.

Jamf support mentioned that they have a ticket or some sort of communication in with Apple about this because it seems to be with the softwareupdate command-line tool or just on Apple's side in general.

For now, I'm going to continue pushing the minor Monterey updates via the full installer package that I built and deploy via policy. Hopefully, there will be some clarification around this soon though!

[AJPinto]

For macOS 12.3+ if System Preferences > Software Update is used the Mac does not download install macOS Ventura.app. MacOS will download a delta like a minor software update. It is no longer possible to block macOS Upgrades by blocking the install macOS {name here}.app as that workflow is deprecated. You must use the Major OS update deferral which only lets you defer for up 90 days which expires in a few weeks.

For my org we have not see any issues of Macs seeing Ventura that should not see it. However our entire feet is "correctly managed" per Apple definition so all devices are seen as organizationally owned and managed. Though going through JAMF discussions you are far from the only person seeing issues.

I sounded the alarm back in early November that we could not block Ventura past January, and basically drug everyone to the table for testing and validation. Vendors (mostly security clients) that were not ready will be running unsupported clients or be removed. A much more hard line approach to what I usually take, but I got mostly positive feedback. Only one application will be left out in the cold and that is Netskope. If Netskope does cause issues we will remove it and there is already a replacement in the works, though in testing Netskope seems fine with Ventura.

Though I totally agree, 3 months to fully validate is absolutely absurd. With how close vested Apple handles development most vendors don't start develop their products until the production release of macOS. No one wants to develop a client with a beta version of the host OS.

[sdagley]

@AJPinto What is the issue that makes you say Netskope "will be left out in the cold"? AFAIK Netskope is compatible with macOS Ventura as of version 99.0.0 (they do note some issues running on a Ventura VM but that's not something I'm concerned about)

[AJPinto]

Internal politics and some people wanting it gone for another tool. So the interest to update it is just not there for the business unit that owns it.

[sdagley]

@AVmcclint Have you tried blocking the InstallAssistant process using a Restricted Software configuration? It won't help for the delta Ventura update, but should block Macs that get the full Ventura installer.

[AVmcclint]

I didn't think of that. I will give it a shot.

[jackofOS]

I also block the InstallAssistant process in Restricted Software. Based on what you said about the difference in the delta update vs. the full installer for Ventura, this would probably make sense as to why the machine that pulled the Ventura upgrade did so. Thanks for the info!

[sdagley]

@jackofOS Unfortunately the delta updates are installed via the software update process, and I don't think blocking that is a good idea.

[jackofOS]

I'll keep that in mind -- thanks!

[relievant]

+1, I've blocked InstallAssistant for years and this Ventura "update" comes through anyway when installed via Software Update in System Preferences.

[AJPinto]

Yes. When you block the InstallAssistant that is a binary that comes within the Install MacOS {version}.app. On Macs running 12.3+ Ventura comes down as a delta, there is no app to block any components of, there is no InstallAssistant.

[McAwesome]

Keep in mind that macOS 12.3 through 12.6 see the macOS 13.1 upgrade as a Minor Update due to a bug that wasn't patched until 12.6.1.  Whatever approach you use to try to block it should include accommodations for that known issue.
https://support.apple.com/en-us/HT213471 

[jackofOS]

That makes sense -- the machine that I had go to Ventura was on 12.6....figures!

[AdamCraig]

You can add the Ventura installer to the restricted software. This will stop the installer from running.

[AVmcclint]

That's one of the first measures I enabled. All my measures seemed to work just fine up until the middle of December. 

[McAwesome]

macOS 13.1 was released on December 13th.  If you had machines running macOS 12.3 through 12.6, they would treat that as a minor update rather than a major one.  That's due to a bug that was fixed with macOS 12.6.1 

Combine that with macOS 12.3 and above using the new Delta update route rather than the full macOS installer and your mid December time frame makes perfect sense.
https://support.apple.com/en-us/HT213471 

[tdanan]

For what it's worth, a machine in our ecosystem which was on 12.6.2 just auto-updated, so that bug fix seemingly doesn't prevent the forced upgrade.

[jackofOS]

Oh goodie!

[tdanan]

I forgot to add that JAMF isn't even recognising machines on Ventura.  It's still showing them as being on Monterey.

[sdagley]

@tdanan How often do you update inventory for your Macs? There is no automatic recon trigger when macOS is updated, so unless you have a LaunchDaemon that runs a script to check for a change in build version on each restart, or a policy triggered on login that does a recon, you're not going to get an update on the version of macOS installed until your inventory policy makes its normal run.

[tdanan]

Our inventory policy runs once a day, but I've just realised a user turned this particular machine off, so it hasn't checked in (unexpected behaviour). My bad for not checking that.

[relievant]

I've confirmed this same behavior in my environment. I've had at least 5 Macs on 12.6.2 that successfully updated to Ventura despite my configuration profiles and restricted software records.

[brockwalters]

One computer state that I've found in addition to the macOS versions mentioned that allow Ventura to install as a minor update is if the computer was never approved by a user for user MDM, ie, if the computer is not Supervised, the MDM deferral keys do not work.

[jackofOS]

Has anyone had difficulty getting any M1 machines running 12.3 - 12.6 to even update to 12.6.1 or 12.6.2? I've been able to get most of my machines updated to 12.6.1-12.6.2, but it seems like some M1 machines running 12.3-12.6, won't even update remotely. I've attempted running via policy (which I know has it's own set of issues with requiring admin, but had to test it for my own sanity), and running the mass action command. I'm nervous to run individually on the machine because the last time I did that for a machine on 12.6, it upgraded to Ventura.

Intel machines work fine, and M1 machines that were already on 12.6.1 have been going to 12.6.2 without any issues.

I know this is sort of off topic, but it's on topic enough with trying to avoid going to Ventura and the weirdness with 12.3-12.6, I figured I'd mention it in case anyone else had similar issues.

[brad-h]

I have the exact same issue.  I was out on holiday break for the past two weeks and I come back to a bunch of messages from support and security saying people have managed to upgrade to ventura.  I check our Jamf configs and it looks like nothing has changed there.  Turns out they're all able to install Ventura 13.1 which Jamf is not blocking for reasons.

[cstout]

It appears that Apple's 12.6.2 update doesn't quite fix the issue which is why we're seeing the Ventura "update" run anyway.

[AJPinto]

There were hoops for the deferral to work. The devices needed to be fully supervised among a few other things. Check with your Apple SE to see what that list was, I cant remember what it was anymore. Though you can only block Ventura until the 22nd anyway, then its out of the 90day deferral window.

[cstout]

Correct, deferral is the only option here and that expiration is fast-approaching. I'm simply pointing out that 12.6.2 still shows 13.1 as a recommended update which is likely the core reason for these undesired upgrades.

[tdanan]

Does that apply for machines on Big Sur as well?

[tdanan]

This may be a bit of a lateral discussion, but it's certainly related to the topic.  In our environment we have config profiles set up to grant standard users the ability to "Allow" legacy kexts, which we rely on for certain hardware and software.  This has worked perfectly well prior to Ventura. 

As part of the context for this I'm aware that SIP is no more (on M1 machines) and everything in recovery mode is now based on admin authentication. 

So, my question is:  Does anyone know if that change applies to System Preferences as well in some way? 

I should add that this inability to allow standard users to "Allow" kexts through deployment of config profiles has been experienced on M1 and Intel machines.

The overall outcome is that JAMF seems to be behind on this change and unaware that Apple have changed security protocols in System Preferences to the degree that this type of config profile is now ineffective.

Strange one, but for us a significant problem which is going to cause a lot of support related tickets just to have an admin authenticate to update a few pieces of software which regularly go through version updates and require the kext to be re-installed.

[AJPinto]

Apple Silicon has SIP and its enabled by default. I think you may be referring to Apple Silicon not having EFI which is true.

I don't think KEXTs will function on Apple Silicon without a lot of hoops though. Its really long past time to force retire anything that requires a KEXT. If a vendor is still using a KEXT that should be loud and clear that vendor is not invested in macOS, and the application is probably full of vulnerabilities. The kext boat has sailed.

JAMF is well known for being full of technical debt, and I have no defense for that. However, if the version of macOS does not support the configuration it does not matter what you do in JAMF.  You can look at all the FileVault configuration, its full of comments of deprecation. JAMF restrictions still let you block USB Mass storage, but macOS has not supported that for years. Ya, JAMF is full of technical debt.

For updating software, use JAMF. Make new packages, or script/config profile auto updates where possible. We have a process that uses must follow to request updates and we enforce that all applications come from JAMF. Its a bit of busy work, but really centralizes the work flow. 

[tdanan]

Sorry, yes you are correct, I meant EFI.  Firmware password lock.

I'm aware of the situation with kext deprecation.  The irony is that the one piece of software which is my main concern, Apple is also a user of as a company, so it's incorrect to say this vendor is not invested in MacOS.  The vendor have told me in the past that they cannot move away from kexts until Apple builds integration into their API for their software.  Apple has a stake in doing so, yet they're implementing further restrictions around kexts.  That's a total nonsense.  Not that anyone here will be surprised by that.  

Complaining aside, I was really just hoping to confirm with others that they have also experienced this behaviour and confirm there isn't a way around it anymore.

That information will give me a direction of travel for a solution, even if that means accepting the extra support hours to help end users.  I just need to know not to spend hours trying to solve the unsolvable and pass word through the organisation. 

As regards automation, we have a policy for this software to pull the latest version from their website when an update is released.  Users can install it via Self Service.  It was as automated as possible with the config profile which is now ineffective.  

[AJPinto]

This application is not by chance made by BlackMagic is it?

[ctomsccad]

In talking with Jamf just now we were told to upgrade to 12.6.3 to continue to restrict Ventura auto-updating. Here's the link from Apple describing what they updated: https://support.apple.com/en-us/HT212586.

[brad-h]

Well it's moot now since the 90 day deferral period is over, but at least we know it was caused by Apple.

[szultzie]

So im fighting with Appel on this as well.  Its so random, i have a lab of 40 identical machines and some went to ventrua and some didnt all on 12.6.3.  Then i have other labs with different hradware and they are still on 12.6.3 and i run the same command on all of them each thursday night  softwareupdate -iaR

-Peter