Well at least I know it's not just me! I thought maybe I was doing something wrong. At least I have confirmation that I'm not.
Well at least I know it's not just me! I thought maybe I was doing something wrong. At least I have confirmation that I'm not.
@howie_isaacks Running the following command will show you if you have more than one profile setting the forceDelayedMajorSoftwareUpdates key. If you do the 2nd command will tell you which one is "winning":
Find any forceDelayedMajorSoftwareUpdates keys in the installed profiles:
sudo profiles show -output stdout-xml | grep --context forceDelayedMajorSoftwareUpdatesFind the "winning" setting for forceDelayedMajorSoftwareUpdates:
osascript -l JavaScript -e "$.NSUserDefaults.alloc.initWithSuiteName('com.apple.applicationaccess').objectForKey('forceDelayedMajorSoftwareUpdates').js"
@howie_isaacks Running the following command will show you if you have more than one profile setting the forceDelayedMajorSoftwareUpdates key. If you do the 2nd command will tell you which one is "winning":
Find any forceDelayedMajorSoftwareUpdates keys in the installed profiles:
sudo profiles show -output stdout-xml | grep --context forceDelayedMajorSoftwareUpdatesFind the "winning" setting for forceDelayedMajorSoftwareUpdates:
osascript -l JavaScript -e "$.NSUserDefaults.alloc.initWithSuiteName('com.apple.applicationaccess').objectForKey('forceDelayedMajorSoftwareUpdates').js"
Thanks! This is very helpful. I credited you on a couple of my scripts even though no one will ever see it unless they login to my Jamf Pro server and look. You've always been very helpful. From what I saw in the post that @JustDeWon linked to, this may be a bug in macOS, which means I spent a whole day battling this thing when it was hopeless.
Thanks! This is very helpful. I credited you on a couple of my scripts even though no one will ever see it unless they login to my Jamf Pro server and look. You've always been very helpful. From what I saw in the post that @JustDeWon linked to, this may be a bug in macOS, which means I spent a whole day battling this thing when it was hopeless.
Yes, unfortunately it does seem that even with a single valid deferral profile in place the restriction process "leaks". There was speculation on the MacAdmins Slack that this was limited to x86 Macs, but I have also seen it on an arm64 Mac.
Yes, unfortunately it does seem that even with a single valid deferral profile in place the restriction process "leaks". There was speculation on the MacAdmins Slack that this was limited to x86 Macs, but I have also seen it on an arm64 Mac.
I used the commands you sent. There is no conflict. Everything checks out. The other Jamf Nation thread linked here makes it seem that this is not a profile issue or a Jamf Pro issue. It's more likely to be something wrong in macOS. I can't believe that with all the smart people here and on Slack that we can't all come up with a solutio for this unless it's macOS that is at fault. I believe this is a macOS issue. We have done what is needed. We are doing what Apple says we're supposed to be able to do, but it's not working.
Have I mentioned how much I HATE the Captcha thing we all have to use to post?
<plist>
<dict>
<key>forceDelayedMajorSoftwareUpdates</key>
<true/>
<key>enforcedSoftwareUpdateMajorOSDeferredInstallDelay</key>
<integer>90</integer>
<key>enforcedSoftwareUpdateDelay</key>
<integer>90</integer>
<key>enforcedSoftwareUpdateMinorOSDeferredInstallDelay</key>
<integer>5</integer>
</dict>
</plist>This matches exactly what I see in Managed Preferences for com.apple.applicationaccess. Our profiles aren't broken. macOS is!
Have I mentioned how much I HATE the Captcha thing we all have to use to post?
Been working with Jamf.. Currently testing a `Custom Schema` config profile via Application & Custom Settings to block the major update only.. "possibly wasn't working with a test user".. However, it worked for my test Mac..
I'll keep everyone updated.. But it seems the `Custom Schema` may be the resolution vs the "Functionality" in the Restrictions payload
@howie_isaacks Running the following command will show you if you have more than one profile setting the forceDelayedMajorSoftwareUpdates key. If you do the 2nd command will tell you which one is "winning":
Find any forceDelayedMajorSoftwareUpdates keys in the installed profiles:
sudo profiles show -output stdout-xml | grep --context forceDelayedMajorSoftwareUpdatesFind the "winning" setting for forceDelayedMajorSoftwareUpdates:
osascript -l JavaScript -e "$.NSUserDefaults.alloc.initWithSuiteName('com.apple.applicationaccess').objectForKey('forceDelayedMajorSoftwareUpdates').js"
I broke down and wrote an EA to report on the number of profiles installed on a Mac that are setting the forceDelayedMajorSoftwareUpdates key. See this post for the EA: https://community.jamf.com/t5/jamf-pro/can-t-block-sonoma/m-p/300911/highlight/true#M264894
Been working with Jamf.. Currently testing a `Custom Schema` config profile via Application & Custom Settings to block the major update only.. "possibly wasn't working with a test user".. However, it worked for my test Mac..
I'll keep everyone updated.. But it seems the `Custom Schema` may be the resolution vs the "Functionality" in the Restrictions payload
Yes, please keep us updated.
In our fleet I've seen all three options:
- no update was shown (the desired option...)
- Delta-Update was shown (6GB)
- Sonoma-Installer was shown (12GB)
All with the same profile 🤨
is there a way to fix this in the config profiles payload in jamf? i have 16 users able to download the sonoma os even though we have a config profile and restrictions set in place hahaha
is this more my fault? or is this something on apples end?
@JamfAdmin2 You can use the EA I posted in https://community.jamf.com/t5/jamf-pro/can-t-block-sonoma/m-p/300911/highlight/true#M264894 to determine if you have multiple profiles setting forceDelayedMajorSoftwareUpdates
Even if you do not it appears that on x86 Macs with automatic updates enabled Software Update will decide to upgrade to macOS Sonoma. Supposedly disabling automatic macOS updates will prevent that from occurring. In theory that recommendation doesn't apply to arm64 Macs, but evidence suggest otherwise.
