For many MacAdmins, Nudge has been an amazing tool for bothering users to update their Macs to the latest patch. Apple threw a wrench in things by the way it implemented the
13.3.1 (a) Rapid Security Response update, so Nudge doesn’t currently (as of this writing) support Rapid Security Response updates.
There would be challenges to the user experience even if Nudge did implement support for Rapid Security Responses (at least the way Apple’s implemented them so far).
First of all, the
13.3.1 (a) update is available for only
13.3.1, so two (disruptive) reboots would be necessary for users on older versions. If you have users on
13.3, they’ll have to update to
13.3.1 first (that requires a reboot), and then they’ll have to update again to
13.3.1 (a) (another reboot).
Apart from the reboots being disruptive, they’re also a terrible user experience. Since
13.3.1 (a) won’t appear at all for users on older versions of macOS Ventura, if you Nudge people to update to
13.3.1 (a), they’ll see only
13.3.1, install the update, think they’ve updated, and then get confused as to why they’re being Nudge’d again for
On top of the user experience being terrible,
13.3.1 (a) isn’t even an actual version. Let’s take a look at how Apple sees this update:
As you can see, the product version is not
13.3.1 (a) but still
13.3.1, and to get to the
(a) part, you need to look at this new key,
ProductVersionExtra, which is not part of the major OS version (13), the minor OS version (3), or the patch version (1). The “extra” part is its own thing.
If you have Munki, which doesn’t really support Apple updates, because Apple doesn’t properly support script-installing Apple updates, you can’t natively enforce this update. You can’t even stage a full installer, as Apple hasn’t released a full installer for
13.3.1 (a), only for
You can, however, use a Munki nopkg to act like Nudge to prompt users on
13.3.1 to update to
13.3.1 (a). Here’s a sample Rapid Security Response nopkg (feel free to tweak further if necessary for your environment).
4 responses to “Using Munki to “nudge” for Rapid Security Response updates (like 13.3.1 (a))”
Does using ‘open’ as root from a root agent open the system settings in the user space?
What happens if no user is logged in and the system is at the login window?
Great questions, Eric.
Yes, oddly enough, based on my testing, using the open command running as root does, indeed, open System Settings in the user space. Not sure how that works, but it does.
In terms of no user being logged in, I honestly didn’t consider that. Probably should have some kind of extra bit in the beginning like “If no user logged in, consider this installed.”
Just committed a change to the installcheck_script, which I think should address that “at login window” issue. Thanks for reminding me about that.
Sort of an aside I’ve stumbled into with the RSR, some vendors who shall remain nameless and possibly many a Mac admin as well are have scripts with a line like this:
OSVER=$(/usr/bin/sw_vers | grep ProductVersion)
Well, thanks to Apple adding ProductVersionExtra any such variable will now have a two line result like
Instead of just
That could cause all kinds of unintended consequences.
Why you wouldn’t explicitly call sw_vers -ProductVersion is beyond me…
And a question shouted into the void – do we have any idea what the next RSRU will look like? I presume its output of sw_vers -ProductVersionExtra will be (b) and so on? And when Ventura gets another update, to, say 13.3.2 or 13.4, will its first RSRU be (a) again or will they keep building?