I'm sure it will follow the same naming convention but there is no way to tell until its released.

I've got mine set to block "Install macOS Sonoma.app"

You can search discussions for blocking Ventura, its the same. 

• Macs running macOS 11.3.1 or newer will not download install macOS Sonoma.app. So, blocking that installer really does not do anything other stopping people who download the app manually, still a good idea to block but wont help much.
• MacOS 11.3.1 and newer will download Major Software updates as a delta, the ONLY way to block this is with a OS update deferral configuration profile. You cannot defer longer then 90 days.

Deferring Availability of macOS Software Upgrades and Updates with a Configuration Profile - Technical Paper: Deploying macOS Upgrades and Updates with Jamf Pro 10.34.0 or Later | Jamf

Yea I have my deferral set for 90 days in Jamf already, this is just incase people try and download it in other ways

This also is the new way to block folks running the beta OS, as well. Under  your Software Update payload is a check-box to enable/disable installing macOS beta releases. Create one for those who are allowed to pre-test the Software, leave unchecked for all others.

Do i leave the others checked and just uncheck the beta one?

Hello All can i get confirmation if this restricted access i did to kill the mac os sonoma beta will work? 

As far as I am aware there is not an install macOS Sonoma Beta.app. Your restriction on install macOS Sonoma.app should work fine, however I strongly suggest testing this yourself. Keep in mind blocking install macOS Sonoma.app wont do anything on Macs running greater then 12.3.1 as they will never download the app to upgrade.

sorry can you elaborate on that. What do you mean by they will never download the app to upgrade?

I mentioned this in another comment on this thread. Apple changed how macOS Major upgrades are installed with macOS 12.3.1. The install macOS XYZ.app is no longer downloaded. Instead the update comes down as a delta, and there is no way to block it aside of a configuration profile. 

I did mistype and put 11.3.1, it was 12.3.1.

You can search discussions for blocking Ventura, its the same. 

• Macs running macOS 11.3.1 or newer will not download install macOS Sonoma.app. So, blocking that installer really does not do anything other stopping people who download the app manually, still a good idea to block but wont help much.
• MacOS 11.3.1 and newer will download Major Software updates as a delta, the ONLY way to block this is with a OS update deferral configuration profile. You cannot defer longer then 90 days.

Deferring Availability of macOS Software Upgrades and Updates with a Configuration Profile - Technic...

---

so if all macs are on ventura they will not be able to download the sonoma beta? 

No, @AJPinto is just saying it doesn't download a complete installer, just an update containing the necessary files to upgrade to macOS 14.

You don't really need a software restriction to block OS betas anyway, it's a simple checkbox available in a configuration profile:

hmmm okay thank you for the info let me ask you is it possible to block the sonoma 14 beta? in the restricted software sections or is it different this year where you are unable to at all?

I am only asking because i asked a lot of people and i am getting mixed answers people are telling me yes where others are telling me no and to create a config profile 

I'm honestly not sure, but my guess is yes since it is possible to download a full installer. This thread seems to support that: https://community.jamf.com/t5/jamf-pro/blocking-sonoma-developer-beta/m-p/292714

The old-school method to block software updates involved setting Restricted Software process blocks for the software that you wanted to deny. In Ventura's case, it was a combo of blocking the InstallAssistant, Ventura as a process, and I also blocked Install macOS Ventura.app. You can change both scoping and wording to affect different outcomes.  For Sonoma, your process names/app names would just be updated to reflect that. I would feel like the Configuration Profile restriction would be more effective though.  

even with restricting install assistant did not work for me, does it work on your end? 

Restricting the Install Assistant did not work on a Test Mac in our Jamf environment either. It would appear the only way to block the install of macOS Sonoma is to use a Configuration Profile to Defer major software updates:

Under Restrictions > Functionality.

As this can only be set for a maximum of 90 days I am looking for a way to extend beyond this time period for further testing. If there is a possible way to do this or put a feature request into Jamf for that would be what we require.

It is not possible, there is no point in submitting a feature request to JAMF as this is Apples intended design. You could submit feedback to Apple, but don't expect them to change anything. All you can do is communicate to users, and hope no one goes rouge. 

If you need Apples documentation, its linked below.

Test and defer software updates for Apple devices - Apple Support

Restrictions | Apple Developer Documentation

It is both unfortunate and continually a major pain that each year with a new OS release, Apple changes the method for enterprises to block the new OS. Restricted Software will no longer prevent Sonoma from installing, as it appears Apple has wrapped the process into the upgrade process without directly engaging the installer app that would get killed by the Restricted Software process.  This is yet another example of big tech "wagging the dog," implicating that THEY will tell you how to manage your Macs, unless you do the deep or creative way to stop them.  Apple, please stick with a reliable method for sysadmins to block your OSes so WE can manage our network, not YOU!!!!

It's not really "new" as mentioned above this was changed early on in Monterey, around 12.3 and has been like that since then. The only way to defer Major Software updates is via a config profile and the maximum length is 90 days.

This. Plus, Restricted Software should still prevent the user from using a full installer they download themselves.

Well, this is undoubtedly distressing news. Our company works within a regulated environment and has put in a lot of work in managing macOS and applying additional security controls in conjunction with the macOS compliance project on GitHub. This includes a non-insignificant amount of time and money spent with JAMF professional services in implementing controls for specific cybersecurity frameworks and the Defense Industrial base that necessitates baselining against a specific version of macOS.  Needing to this on a yearly cadence is going to represent a non-insignificant amount of time and effort on our end and to be frank, the response from Apple has been a joke.

Our local Apple business rep implied that we weren't using JAMF correctly to control these updates. They were, however, useful in obtaining a phone number to talk with Apple's Enterprise Support Team engineering team.  I spoke with 2 agents that were a delight to work with, however at the end of the day the Apple Engineering team basically told them to pound sand and that the update process is working as intended.

I realize we're pretty small fries when compared to other organizations out there since we're only managing about 80 macOS devices, but the way that Apple is pushing these updates in conjunction with an ever decreasing support life cycle, will probably necessitate us moving away from macOS in the medium term if this is the approach that they're going take.

I suggest everyone here call the Apple Enterprise Support phone number (866) 752-7753 and start making noise.

Can the configuration profile be re-applied, thus getting around the 90 day maximum deferral?

It’s 90 days from the date of the public release of the software update/upgrade. Not 90 days from the date the configuration profile was installed. This is the same deal as with macOS 13 Ventura last year, nothing has changed with how macOS differs updates in the last year.

So there's effectively no way to prevent a user from self-initiating an upgrade to a new version of macOS after 90 days of a new release, is there?  That's the problem though, when macOS announces a new version, we have 90 days to test and validate our security settings otherwise we risk being non-compliant with our own cybersecurity polices.