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.

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!

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.

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

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

@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)

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.

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!

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 Unfortunately the delta updates are installed via the software update process, and I don't think blocking that is a good idea.

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

I'll keep that in mind -- thanks!

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

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

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 

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.

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.

Oh goodie!

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.

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

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

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.

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.

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

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.