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.
+1, I've blocked InstallAssistant for years and this Ventura "update" comes through anyway when installed via Software Update in System Preferences.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Does that apply for machines on Big Sur as well?
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.
This application is not by chance made by BlackMagic is it?
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.
Well it's moot now since the 90 day deferral period is over, but at least we know it was caused by Apple.
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
