MacOS updates management with Nudge

Since moving to the SUPER method, our macOS Major update workflow has been much more streamlined with simply requiring a small adjustment/upgrade of the script for each new version and updating of the blocking mechanism for when we want to restrict deployment to endusers to allow for internal testing (a restriction config blocking only major software updates for X period and excluding IT Test devices group from the scope).

https://github.com/Macjutsu/super

Our Updates Config Plist looks like this (not updated for Tahoe yet).

 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
	<dict>
		<key>AuthJamfComputerID</key>
		<string>$JSSID</string>


<key>InstallMacOSMajorUpgrades</key>
<true/>
<key>InstallMacOSMajorVersionTarget</key>
<string>15</string>
<key>InstallRapidSecurityResponses</key>
<true/>
<key>DeferralTimerDefault</key>
<string>480</string>
<key>DeadlineCountSoft</key>
<string>3</string>
<key>DisplayUnmovable</key>
<string>ALWAYS</string>
<key>DisplayHelpButtonString</key>
<string>Your IT - For assistance please contact us at support@your.org</string>

</dict>
</plist>

• allows minor/security updates,
• allowed deferral amount (3 in this case)
• time between deferrals (480 minutes / 8 hours)

We then obviously scope this to devices that

• are compatible/eligible with the latest update (via smart groups and extension attributes).

I gave up on nudge years ago. Its okay, but considering you cant trigger updates from CLI anymore its literally just a notification tool and for that I use Jamf Helper. As ​@Ke_ReM said look in to using SUPERMAN, or look in to blueprints. 

Don’t get stuck in the past with some third party patching tooling (which was great when MDM protocols were the only way updates could really be had). Declarative updates is the future and will be the best bet here - considering it’s all native to the OS.  I’d recommend using Software Updates or Blueprints to apply updates.  

I agree that its good to stay upto date with developments but its not broken, so no fix required.
Also we are primarily a Windows org so I have minimal time to invest into new methods when the existing just works. Any pointers to the new methods appreciated though, I will put some time aside to read up on it.

Also, not impressed by Apples “in-house” methods from the past which might have been fine for non enterprise level endusers but were not suitable for our standards. Hence the need for things like SUPER and previously Nudge..

The world of Open Source is all giving as someone mentioned in a blog post somewhere...
I would hate to have to rely on Apple for (working) solutions when you need them..

Pointers to the new method?  Just create a blueprint and test.  It has been an awesome resource for us.  We leveraged the old MDM push method for years and it was pretty reliable.  DDU has been flawless minus some of the older devices that are ornery….but that’s like .02% of our fleet.  We turned on jamf SSO less than a month ago and are currently leveraging blueprints for updates.  Just did the 26.1 update to our mobile devices last night and it got over 95% of them up to date.

Hi all,
thanks for the replies so far.

Let me explain my setup a bit better, because I think the issue is related to how macOS handles update deferrals.

I’m using Nudge together with macOS update deferral configured via a Configuration Profile (Restrictions payload).

I have two profiles:

One Restrictions profile assigned to all devices (with the test group excluded).
This profile contains various system restrictions and also software update deferrals. Updates are deferred for 60 days after release, because I don’t want users to accidentally install new macOS versions.

The second Restrictions profile is assigned to a test group.

It’s a 1:1 copy of the first one, except there is no deferral configured at all. This group gets new macOS versions immediately and tests them.

My process is simple:

New macOS version is released.
Testers run it for about two weeks.
After testing, I configure Nudge the way I want and then I edit the Restrictions profile for all users, changing the deferral from 60 days to 7 days. At this point the update should become available.

What I’m seeing in practice:

For around 60% of users, everything works fine and the update shows up in Software Update.
For the remaining 40%, Nudge correctly prompts them, but when they open Software Update they see “You’re up to date”, which is obviously wrong.

The only workaround that works reliably is temporarily adding the Mac to the exclusions of the Restrictions profile and then removing it again. That seems to refresh the profile state and the update suddenly appears.

Now I’m about to roll out macOS 26.1 and roughly 50% of the fleet is already on it. I really don’t want to exclude all remaining devices from the Restrictions profile, even for a short time, because that would leave them without important restrictions applied.

Has anyone seen similar behavior when shortening the deferral window?
It feels like macOS is caching the previous deferral state and doesn’t always reevaluate it after the profile is updated.

Any ideas how to handle this better in the future?
I’m mostly looking for a scalable and predictable approach, because manual profile refresh tricks don’t really scale.

Thanks in advance.

It sounds like a profile conflict. Personally, I have no experience with Nudge (we went SUPERMAN) so I don’t want to make too many assumptions. But from a forwarding looking perspective… have you ever considered moving your restrictions over to a “Blueprint”, even if you don’t want to go that way for Updates just yet? We saw exactly this behavior form some units as we were transitioning one of our campuses from older update methods to Blueprints/DDM, and a profile restricting updates from a previous SUPERMAN notification profile was causing this.

Moving to Blueprints even with just legacy profiles get’s you out of the same kind of pipelined communication method that can sometimes get stuck like this.  It also sets you up to layer remedial blueprints in place to auto resolve items like this. 

P.S. Also, and embarrassingly for me, I had a test machine do this once and it took me almost a day to figure out it could’t actually receive the update. Not saying that’s what happened here, but I had to at least call myself out!

Good catch on the profile conflict angle.

I actually found this thread which describes very similar behavior:

 

I tried the simplest possible thing mentioned there:
renaming the Restrictions profile and hitting Distribute to all, which forces a full repush of the profile.

The profile was not removed from devices, but it was pushed again (I literally just added a space to the profile name). As a result, all devices affected by the issue (basically not only those) received the latest configuration, where the update deferral was already correct. After that, Software Update started behaving as expected.

So this definitely supports the idea that the Restrictions payload state wasn’t being properly reevaluated on some machines until a full profile reinstall happened.
 

Regarding Blueprints because I haven’t gone deep into them yet.
Short version: how do Blueprints relate to the existing Restrictions payload? Can they coexist, or does moving to Blueprints effectively replace the current Restrictions-based approach? I want to understand the interaction there before mixing models.

Thanks again for the insigh!!!  this helped a lot in narrowing it down.

I also had to re-push profiles to correctly set deferrals in this latest round, and ended up doing it via Blueprints. So functionally, the same as what you did. New profile with same settings.

We are in higher ed, so it’s more prickly to set an absolute deadline and fully manage the updates. For computer labs, no problem, we can use DDM software updates. For single-user computers, not so much. There, we use Nudge along with deferral profiles to good effect. We configure Nudge with approximately the default SLAs so I don’t have to edit and re-push profiles each time there are new updates.

I do switch out my deferral profiles (applied via Blueprints): one when we’re actively in a deferral period, to set the deferral, then another with no major OS upgrade deferral once our deferral period is over, because once the deferral is over I want folks upgrading to the latest version, not the version from 90 days ago. I switched these to Blueprints for this group of computers, since all of our important Restrictions for these are applied via signed and uploaded profiles.

When I was troubleshooting sticky deferrals in September, someone showed me the command:

/usr/libexec/mdmclient AvailableOSUpdates

This was really helpful for me to determine why a device I was trying to upgrade was not showing the new OS, because it showed me the active deferrals, which helped me narrow down the cause and make a fix.

About Blueprints vs. Restrictions profile: if you configure Software Update restrictions via Blueprints, it is just a configuration profile -- but it’s a configuration profile with just the settings you’ve configured, not all the things. So you will want to remove any software update settings from other profiles that could also carry software update payloads -- like a Restrictions payload built from the Jamf Pro UI, which will have the payload even if you didn’t set it. Definitely something you want to test out because they can conflict.

@paczo Regarding the Blueprint question:

Ultimately, the idea is that you could use a Blueprint or Blueprints to replace what you currently deploy as individual configuration profiles. I’m pretty sure blueprints supports all existing restrictions (marked as a legacy Payload) that we would have been able to configure previously in Jamf Pro Configuration Profiles. At least in our case, we started with Software Updates and Restrictions (Single Blueprint for Students) as we see it as the easiest way to start with BluePrints. There are still some items that are not totally encompassed by BluePrints, but they’re constantly being added. 

Blueprints are essentially the next, evolutionary step to Configuration profiles. The MAJOR benefit as I see it (traffic aside) is that you can create AND layer Blueprints full of configurations/settings instead of needing to manage all sorts of individual profiles. It also crosses Apple platforms. So your restrictions BluePrint can work across all the apple platforms where the settings you make are applicable (macOS, iPadOS, tvOS, etc).