Can't block Sonoma

[AVmcclint]

I have deployed a Config Profile with the following code to block Software Update from seeing the major OS releases (Sonoma) for 90 days with com.apple.applicationaccess for the domain:

<plist>
	<dict>	
		<key>enforcedSoftwareUpdateMajorOSDeferredInstallDelay</key>
			<integer>90</integer>
			<key>forceDelayedMajorSoftwareUpdates</key>
			<true/>
	</dict>
</plist>

Sonoma was released by Apple 25 minutes ago and already I see Macs that are displaying Sonoma as an available update!

 I have verified that the Config Profile has been installed on these Macs for many weeks. Every single time there's a new Major OS release, it's like trying to hit a moving target. How on earth are we supposed to block Major OS releases? 

[obi-k]

Yeah I agree. There goes change management. 

[bmack99]

I guess the other question I would have, and am curious if anyone has been able to test: for the 13.6 machines that show Sonoma in SoftwareUpdate - are non admins able to install? I'm assuming so if it's treated like a Delta.

[lbehannesy]

In my testing, one I removed a couple of test devices on 13.6 from our restricted config profile, I was able to update to Sonoma as a non-admin

Also our two devices that updated to sonoma auotmatically were inside of the restricted config profile and were on 13.6

[bmack99]

Wow, so basically to prevent this now I would have to get everyone on 13.6 and then in 90 days if our 3rd party stuff is still not ready, completely block SoftwareUpdate on our machines it sounds like. What an absolute cluster.

[pueo]

Had one user report that to me. She came to work in the AM and her machine had upgraded over night. Like WTF!

[bcrockett]

Another note for folks using jamf connects in damage control mode right now. 

Update to version v2.27 

My clients on version 2.23 had the jamf connect login window not show up after updating to macOS 14.0 - Sonoma.  They could still log in with the local login window. However, some configurations of jamf connect could stop users from logging in until the updated pkg is installed.  My workflow to fix this is to create a policy to install version 2.27 targeted at computers affected with a trigger at startup. That way when the computer boots it the updated version is installed. 

Alternatively, you could proactively update to v2.27 

[pueo]

I was informed when a major upgrade happens JC will turn off and will need to be turned on again. It's part of the upgrade process.  I think Jamf Support told me that.

I use Mac Apps to keep Jamf Connect always on the latest.  We only use it for password creation, sso and password sync. Pretty basic config. 

[PorkChopExpress]

If you are seeing instance where 90 Day Deferrals aren't enforcing as expected and users are seeing the Update available ins Sys Prefs, it's likely that they have multiple configs deployed with conflicting deferral settings.

Run the following command in the macOS Terminal:
sudo profiles show -output stdout-xml | grep -i delay

If you see the forceDelayedMajorSoftwareUpdates key set twice, you’ll want to re-run the command without the grep, i.e.

sudo profiles show -output stdout-xml

This will give you list of every preference key set by every config profile on your Mac. You’ll want to search for that forceDelayedMajorSoftwareUpdates key and see in which profiles it’s being set, with potentially-conflicting values. Once found, remove the duplicate profile from your devices, and set the desired value in one of your profiles, likely your Restrictions profile.

More here

[obi-k]

Looks better now. Thank you.

[lbehannesy]

Thank you, 

I ran that command on my device that force updated to Sonoma and I can confirm I only see the forceDelayedMajorSoftwareUpdates key set once

[pueo]

I only see the key once too. 
I am assuming devices less than 13.6 and you allow Minor Updates, Sonoma will appear.
Devices on 13.6 Sonoma will not appear (assumption you have Major Upgrades block).  
But this may or may not work all the time.🤔

[lbehannesy]

Correct, but somehow my device still auto-updated to Sonoma on it's own!

Absolute madness

[sdagley]

We've seen a very small number of Macs that have the major deferral restriction in place (and only one instance of the deferral profile) with automatic updates enabled end up installing 14.0 instead of 13.6 so that approach for preventing updates definitely isn't 100% effective.

[howie_isaacks]

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?

[AJPinto]

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. 

[bmack99]

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

[pueo]

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

[JustDeWon]

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&syspa...

[jender]

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. 

[TheBrettShow]

This works too.

[jender]

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.

[TheBrettShow]

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 !

[JustDeWon]

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

[howie_isaacks]

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

[sdagley]

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

<?xml version="1.0" encoding="UTF-8"?><extensionAttribute>
<displayName>Count of profiles setting forceDelayedMajorSoftwareUpdates</displayName>
<description/>
<dataType>number</dataType>
<scriptContentsMac>#!/bin/sh&#13;
&#13;
# EA - Report count of profiles setting the forceDelayedMajorSoftwareUpdates key&#13;
&#13;
result=$(/usr/bin/profiles show -output stdout-xml | /usr/bin/grep forceDelayedMajorSoftwareUpdates | /usr/bin/wc -l | /usr/bin/cut -w -f 2)&#13;
echo "&lt;result&gt;$result&lt;/result&gt;"</scriptContentsMac>
</extensionAttribute>

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

[howie_isaacks]

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

[SMR1]

Did you use anything specific for the preferred domain?

[JamfAdmin2]

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

[JustDeWon]

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

[RJH]

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 ?

[AVmcclint]

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

[RJH]

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" ?
 

[AVmcclint]

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. 

[howie_isaacks]

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?

[howie_isaacks]

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?

[sdagley]

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

[howie_isaacks]

Thanks for the blog post link. The JSON in the profile manifests will be extremely useful. This whole problem with not being able to defer Sonoma reliably has made me want to write my own profiles more instead of relying on the built-in payloads in Jamf Pro. I believe I may have solved my issue with Sonoma deferrals by replacing the profile I had that was enforcing automatic macOS update checks and downloads with one that was created from my own custom JSON. The original Software Update settings profile was pushing settings that I did not specify in the profile. Removing it seems to have fixed the issue, and then installing my new profile for Software Update settings did not introduce any conflicts.

[roach]

---

At least restricted software for Sonoma still works.

---

[howie_isaacks]

I reached out to AppleCare Enterprise. They showed us that there was a conflict. Another profile that I had created to enforce automatic update checks, and automatic macOS update downloads was also sending deferral settings to our Macs. I DID NOT turn on those payloads in the profile so I was very annoyed to find out that the profile was doing this. The way I solved this was to create a custom JSON just for these specific settings. I then used the new JSON to create a new software update settings profile that does not send the conflicting settings. My users are now no longer seeing macOS Sonoma being presented in Software Update. Oddly, when I ran a command that should have identified any conflicts, I did not see that there were conflicts. When some of my users sent their data to AppleCare, they were able to identify the cause of the issue really fast.