@bmack99 Not much to report really.  I went over what I think is happening, stated Jamf Nation and Slack has blown up with admins different/consistent experiences of Sonoma. The Jamf Support fella agreed and understood everything I said.  They are doing some further digging for me. Will update.
As much as it is frustrating there is not much we can do. I have all the correct profiles which work for some but then do not.   This is a very poor experience.

To avoid INTEL machines from auto upgrading to Sonoma I would turn off 'Automatically Install macOS updates'. This key is in Software Update Profile. I discovered this is what (potentially) is causing my INTEL clients to auto upgrade to Sonoma (on top of the Deferral not working correctly).  
Apple and Jamf or other MDMs need to work together to make this a better experience.
I wonder how Walmart, Cisco, Target, SAP deal with this situation?

For me this issue has been intermittent. It seems to work on most of my Macs, but I keep seeing the number of Macs running Sonoma going up. I think this should get a case started with Apple. Apple gives us the ability to do this, so why doesn't it work?

I have yet to see any Sonoma upgrades in my environment beyond those which I genuinely screwed up the scoping on the restriction. Where I agree opening a ticket with apple is the right solution, I dont think apple will do anything to resolve the issue in a timely manner. The most we could hope for is a 13.7.1 which I doubt apple will release as Apple wants us to upgrade to Sonoma. Honestly, I would not be shocked if any issues are intentional oversights. 

Magically this morning all of the non 13.6 machines in our fleet are now showing only SWUs for 13.6 and Safari(and a few xcode CLI tools). Somehow the Sonoma Delta just magically went bye bye...

Looks like the resolution "workaround".. may be setting it up via the Custom Schema.. been testing and having much better results.. 

Here's Jamf's KB on it, looks like it was just recently created... https://jamf.service-now.com/csm?sys_kb_id=c48a1b0a1b297194fb9843fccd4bcb8d&id=kb_article_view&sysparm_rank=1&sysparm_tsqueryId=0eeb320387693d901246fe6acebb358d

The guide/script seemed to work initially but I logged into the test machine this morning and I can once again access and install Sonoma. 

I can confirm that this works on Ventura < 13.6. 

<plist>

	<dict>	

		<key>enforcedSoftwareUpdateMajorOSDeferredInstallDelay</key>

			<integer>90</integer>

			<key>forceDelayedMajorSoftwareUpdates</key>

			<true/>

	</dict>

</plist>

I'm using the Applications & Custom settings < Upload.

It's possible you are restricting it twice and there is a conflict

run this in terminal - 

sudo profiles show -output stdout-xml

look for forceDelayedMajorSoftwareUpdates

or forceDelayedSoftwareUpdates

if its in there twice there is a conflict.  

Hey @JustDeWon !

Here's the EA I wrote to report on the number of profiles installed on a Mac that are setting the forceDelayedMajorSoftwareUpdates key:

This is an EA downloaded as .xml, you can use the Upload button in Settings->Computer management->Extension attributes to import it into your JSS

<plist>

	<dict>	

		<key>enforcedSoftwareUpdateMajorOSDeferredInstallDelay</key>

			<integer>90</integer>

			<key>forceDelayedMajorSoftwareUpdates</key>

			<true/>

	</dict>

</plist>

What's going on Brett!... Hope all is well bro

This works too.

@bmack99 After reading you post i thought this may be the case with our Macs.  Over the weekend I thought people would upgrade to Sonoma, but the numbers were the same on Friday and Tuesday. 
Maybe our non 13.6 users are only seeing the 13.6 update now (and Safari).

nm, we had a Drata-linked 'Software Update' policy (automatically install macOS updates, etc.) that apparently took precedence. After removing that, the custom JSON schema took effect again.

<plist>

	<dict>	

		<key>enforcedSoftwareUpdateMajorOSDeferredInstallDelay</key>

			<integer>90</integer>

			<key>forceDelayedMajorSoftwareUpdates</key>

			<true/>

	</dict>

</plist>

I ran the commands and searched for forceDelayedMajorSoftwareUpdates and forceDelayedSoftwareUpdates. They both show up only once. There are no conflicts.

Did you use anything specific for the preferred domain?

I completely agree. This kind of nonsense makes me hate Apple sometimes. I just don't know what in the world is going on over there some days. This should not only be something very standard, but simple, easy. Instead, trying to block a new OS on company owned and managed hardware becomes a freaking nightmare with them.

I sometimes believe Apple intentionally keeps it semi broken or very hard to get working, just so machines get upgraded to their latest OS, and then Tim Cook can tout upgrade numbers for their OS release at the next big event. Apple drives me crazy with this.

Thanks for posting this. It helped me know that there are no conflicts.

i am confused because some users on monterey can upgrade to sonoma is there to fix that so they cannot upgrade to sonoma 

FWIW.. I've been working with Jamf on this(including the custom .json) payload.. They were able to replicate the issue.

PI114179 has been opened on this

hi @AVmcclint   - possibly a stupid question, but in your initial post, with the image showing the Software Updates - available OS packages listed , where are you seeing this data?  is it in Jamf Pro Console - the new (beta) software updates interface perhaps ?

@RJH The initial screenshot was taken from a random computer record and click on Software Updates under Inventory in Jamf Pro (cloud) version 10.50. Here is another place you can see that the computers are seeing what they aren't supposed to. On the Computer Search page, change the criteria to Software Updates and type "sonoma" then click Search. You'll see all the computers that are seeing the Sonoma upgrade. I have verified that all the computers DO have the config profile installed.

We have a case open with AppleCare Enterprise. They pointed out something very interesting. While looking at data submitted by one of my users they commented, "According this latest dataset, the “mcx_preference_settings” wrapper is shown for both Major and Minor updates meaning it may or may not function as expected." In a previous response, they said that, "As it turns out, AppleCare received reports of admins deploying these keys but still showing users the next upgrade path. Also, customers reported random odd behaviors with these defer keys on the macOS client end. After an in-depth investigation was performed, Apple determined the behavior was expected due to MDM wrapping the configuration around "mcx_preference_settings”. Unfortunately, MDM venders may try to workaround Apple’s OS infrastructure by deploying a custom configuration profile that contains these defer keys but it’s not supported configuration. You may share this email with your MDM vender if they state otherwise, but Apples’ final answer is using the "mcx_preference_settings” for a restriction deployment is not a supported configuration.

This is very telling... "not a supported configuration"! OK. So what do we do now?

One more thing I want to add on this is that we also have a profile to turn on the setting to check for updates and to download updates so they're ready for users to install when they are prompted to update by Nudge. This profile was created using the built-in payloads. I did NOT use the payload for deferring updates, but Apple said that these settings were present in that profile. Why would they be if I did not specifically turn them on? This is why I created JSON for a new profile so I could specify exactly what I wanted without Jamf Pro inserting anything extra that I did not ask for. This really irritates me. Why would Jamf Pro insert additional settings that I did not specify in the profile?

@howie_isaacks If you use Jamf Pro's standard interface for creating a Configuration Profile Restrictions payload, or upload an externally created profile that's not signed for that payload, it's going to include a _lot_ of cruft you might not expect/want (download your profile and un-sign it with a tool like Hancock then examine the profile contents to see what I mean). A common way to avoid that problem is to use the iMazing Profile Editor (iPE) to craft a profile with _only_ the keys you want, but as @talkingmoose recently posted you can use the custom schemas created for the Jamf Pro Applications & Custom Settings editor from the manifests that iPE uses to create the profiles in Jamf Pro: https://www.jamf.com/blog/profilecreator-manifests-now-available-for-jamf/

The advantage of doing it this way is you can edit and re-deploy the profile without having to upload a whole new signed profile if you had to make an edit in an iPE created profile.

thanks for clarification @AVmcclint. A really useful reporting feature clearly.
So it appears both the above options are dependant on enabling the "new Software updates" experience in BETA in Jamf Pro.   
For our environment we have not turned on the Software Updates feature in Prod as yet, 1/ its still in BETA 2/ as it will require some work to revisit the our existing "in flight" updates via the Patch Management functionality (refer screenshot). 
Did you enable this from the get-go when it was released, and have you (or anyone else???) had any issues using this "new software update experience" ?
 

We aren’t utilizing the Software Update beta.  At this point, we aren’t pushing any MDM commands for updates until we can feel safe about not upgrading before we’re ready.