Enforcing Apple software updates in the year 2021.

[sdamiano]

While this is, arguably, a feature that Jamf should be able to handle at its core, what is the best method in 2021, across the gamut of supported OS's and architectures, to enforce Apple software updates?

I understand that theres resistance to using any terminal commands for software updates. As stated in the Nudge channel, Since 2018 this has been a problem since Apple doesn't test softwareupdate commands that are triggered by a script. In addition to that, this requires a password if the computer is Apple Silicon.

I recently rolled out the UEX-Tool-For-Jamf, and two of the components in it are no longer developed and throw gatekeeper issues in Big Sur.

I would like to use Nudge, but, my confidence in my users is low enough to not expect Nudge to work fine on its own. Nudge cannot force the update to happen.

What is the best way to handle software updates? Is there MDM magic I am missing? What is the downside to having the checkbox "keep my mac up to date" checked via a config profile?

[taugust_ric]

Ha! Already have one answer - macOS Big Sur 11.6.1 was also released today...

[scottb]

Monterey, and others, are out...have fun!

[scottb]

There's this:

Deferrals via Mass Action... 

[bbarciz]

As someone who has just recently began looking into updating hundreds of Macs using Jamf, I'm shocked that this is such a complex issue!  On the windows side, our SCCM software makes handling this very easy.  As a college, we really need some way to perform the updates overnight when the machines are not in use.  We currently have many OS versions in use partially because of hardware that will not support upgraded OS's plus some specialty classes/hardware/software keeping us at certain OS versions.  Does anyone have any thoughts on a method of controlling when updates occur?

[Geissbuhler]

Watched the JNUC session about nudge, that thing seems like a full time job to handle! Thats what I took away from that session, anyone else find a better tool to help this process out with M1 devices, I suppose I can just schedule times to push out the commands, seems silly though.

[bmack99]

Throwing my ring into the hat here, more or less just to say the pain is real and I'm getting pretty agitated. We are currently a fragmented mix of 10.14 10.15 and 11.x machines. (All Intel and all macbooks). Our patching workflow had been to update Pilot machine groups, wait a week then update the rest of the fleet, all the while giving users 3 days of deferral until the patch is enforced. Utilizing either the softwareupdate commands or the SoftwareUpdate payload in policy. Big Sur seems to have changed all of that as others have mentioned. I basically need to "beg" macOS 11 users now to install the latest update, which is ridiculous. I will be reaching out to JAMF support on this also, as this is not an acceptable solution in an Enterprise Environment. My SCCM coworker basically laughs at how absurd this is.

[dstranathan]

SImir situaion here. We are Catalina and Big Sur mostly, but starting to roll out Monterey now that 12.1 is out. We are a mix of Intel and a few ARM CPUs too.

The days of NetSUS seem so far bend in the review mirror.

[Geissbuhler]

Another item to consider with M1 Hardware. We are currently getting older model M1 shipped with Big Sur, but want them on Monterey for Various reasons as some of our stuff just works better in Monterey. Current process (since there is no keyboard command to press to internet recovery for latest OS) Enroll Device, Let Startup scripts run, Log in, Upgrade the OS Manually, Use Erase All Content and Settings and then hand to the end user. No fun at all.

[twall]

@Geissbuhler Have you tried using Apple Configurator 2 for your M1 macs? We've been successful in using it to update and wipe around 5 M1 machines connected to a single host at a time in 15 minutes or so. 

[Geissbuhler]

@twall Apple configurator 2? Buzz your girlfriend, WOOF! THATS DISGUSTING! I’ll give it a try thanks 🙂

[Geissbuhler]

Just got the email JNUC 2021 recap, saw the nudge video being suggested again, made me sad. Here is to hoping for better solutions in the new year! 

[Geissbuhler]

Sorry accidentally posted 2 times

[dmichels]

The only issue is that this kills my network during the day and you can not schedule it. 

[tomt]

---

@dmichels wrote:

The only issue is that this kills my network during the day and you can not schedule it. 

---

Sounds like a good use case for a caching server?

[Geissbuhler]

I am absolutely with you on that one for sure, cause who wants to be there after hours to hit the button. We are all just trying to keep our weekends right!?!? Limiting the traffic from the app store and other apple servers might be a good route to explore.

Depending what your needs are (ios and macOS, like if one is more heavy than others) the answers are likely here, to get over to the network team, or if you are the network team, if you wanted to do things like limit how much total bandwidth macOS updates take etc:

https://support.apple.com/en-us/HT210060

[Geissbuhler]

Not going to lie, I really like the new Mass action command with deferment:

 On Machine:

A way to Schedule this would be amazing, however this is a really great start!

[SMR1]

Question. If you hit Try tonight, do you know what time it'll run?

[AJPinto]

It should try to run the updates between 12a-4a. They mentioned this somewhere in WWDC2021 if I remember correctly. "Uses machine learning to determine the best time to install update between 12a and 4a blah blah blah"

[SMR1]

Was there anything you had to do to get the "Required Managed Update" prompt? I tested it on an intel Mac yesterday while I was remoted it, but I didn't get any prompts. The user locked his Mac and the update did run successfully, but never seen the initial prompt.

[bbarciz]

Do you know, if you select either try tonight or remind me tomorrow, is it possible to bring this back up on a machine without waiting until the option you selected?  For example, if a user tells it to remind me tomorrow, but then decided that afternoon that they would like to install the upgrade because they decide it is a good time, is there a way to accommodate that?  Perhaps something that could be made available in self service that would force it to re-display?

[AJPinto · Accepted solution]

Your questions are getting rather detailed. I suggest making a new JAMF nation post rather than commenting on a post that is over a year old. You will get more replies. JAMF and softwareupdates have sucked for a very long time, and changes apple has made only exacerbate the issue with how poorly JAMF manages OS updates.

You question is more of a user agency than management action question.

My suggestion: If a user changes their mind and wants to run updates before their deferral just tell them to open system preferences > software update. If the user wants to run updates, empower them to run updates themselves.

As far as using self-service, your experiences will vary between Apple Silicon and Intel Macs.

• Apple Silicon – MDM can only push updates using MDM commands. JAMF teased about letting us use MDM commands in a policy last fall for OS updates. However, as many things they failed to deliver. Unfortunately, the only way to issue a software update command is from the JAMF console by an admin. You can get crafty with API, but I would not recommend it.
• Intel – You can create a policy using the softwareupdate binary and shove that in self-service. The command would be “sudo softwareupdate -aiR” (i = install / a = all / R=Reboot). You “can” do this with apple silicon, but it will prompt the user to enter their password.

Managed Software Updates - using deferrals via a m... - Jamf Nation Community - 249821

[bwoods]

If you don't want to prompt the user at all, you can make a bash or python script that runs the Download and Install Updates management command for you. Add the script to a user interaction policy  to give the user the option to defer the update. 

apiUsername="apiaccount"
apiPassword="apipassword"
jamfProURL="https://yourorg.jamfcloud.com"
macSerial=$(system_profiler SPHardwareDataType | awk '/Serial Number/{print $4}')
jamfProCompID=$(curl -s -u $apiUsername:$apiPassword -H "Accept: text/xml" "$jamfProURL"/JSSResource/computers/serialnumber/"$macSerial" | xmllint --xpath '/computer/general/id/text()' -)


/usr/bin/curl -s -X POST -H "Content-Type: text/xml" -u ${apiUsername}:${apiPassword} ${jamfProURL}/JSSResource/computercommands/command/ScheduleOSUpdate/action/install/id/${jamfProCompID}

[joseph_english]

This looks very promising, but I was wondering what kind of rights do you need to give the API user account and is there any concern about it passing that username and password in plaintext?

[bwoods]

https://docs.jamf.com/education-services/resources/20210729/Resources_300_Lesson11.html

[perryd84]

Been going round in circles with this for ages now but finally got something working.

https://github.com/PezzaD84/macOS-Patching

Made a script to prompt the user to available updates with the option to postpone the update for 4 days. Used to use this script before M1's ruined everything but added a nice function to run the MDM command via an API post if the device is M1.

[AJPinto]

This is a good looking script, I really hate how people are having to resort to API commands to shore up JAMFs inability or lack of desire to do anything with software update MDM commands in any reasonable amount of time.

This will still have problems if the Mac is having issues with OS updates via MDM commands. Which is unfortunately fairly common. As far as I can tell JAMF is still not using the StatusUpdate MDM command, so JAMF has no idea what is going on with updates once the MDM command goes out.

[daniel_ross]

Agreed this script looks like a winner for us.  As we need something that works sometimes with Catalina, Big Sur, Monterey and then M1/Intel.

Has this been tested on all of the above in your environments?  We've looked at Nudge but it has some issues sometimes were not a fan of.

[perryd84]

@daniel_ross This was mainly used for patching Catalina and Big sur as it basically just triggers the softwareupdate command. It was only when we got some M1 devices in that we noticed the issue that no reboots and installations were happening. So it should be all good for Catalina, big sur and monterey.

Feel free to reach out if you have trouble with it or find things to tweak I'm open to improvements. We all need to work together on this as patch management is a burden we all have to carry!😂🙈

[jamfjosh21]

@perryd84 Thanks for sharing this script! Can I ask what has your experience been running this on M1 Macs? I have just tested this on an M1 MacBook but keeps sticking at the prompt to 'Free up Disk Space' requiring 15gb of space but the MacBook has about 400GB free currently.

[perryd84]

Hi @jamfjosh21 I've changed the logic for the disk space now so it should work ok. The logic I had in the script was reliant on the main OS disk being disk1s1 but I have seen a few instances where it isn't. I've updated the script on git hub so it should work around this now. Let me know how you get on.

[bbarciz]

My experience on M1 machines is that the only way to get the software updates to install is using the mass action or management commands in Jamf.  I had no luck at all trying to use policies, scripts, etc and it sounds like that is by design.  Jamf has improved the MDM mass action commands by allowing you to select a version of the OS that you want to patch to.  The problem currently is that there is no scheduling capability.  This is a big issue for us in an education setup where we cannot tell it to update the OS overnight when machines are not in use.  I'm hoping to see some scheduling options soon, but won't hold my breath so far!

[bwoods]

@bbarciz you can schedule them with a combination of running the MDM mass action command via API and a user interaction or jamf helper policy. Take a look at @perryd84 's script above. Using the following API command will allow you to do this.

user=APIUSER
	passwd=APIPASSWORD
	serial=$(system_profiler SPHardwareDataType | awk '/Serial Number/{print $4}')
	ID=$(curl -u $user:$passwd -X GET "https://YOUR.JAMFSERVER.COM/JSSResource/computers/serialnumber/$serial" | tr '<' '\n' | grep -m 1 id | tr -d 'id>')
	curl -u $user:$passwd -X POST "https://YOUR.JAMFSERVER.COM/JSSResource/computercommands/command/ScheduleOSUpdate/action/InstallForceRestart/id/$ID"
}

[bbarciz]

Thanks for sharing.  Is the scheduling component done with the Jamf policy triggers than?

[bwoods]

If you use user interaction or the jamf helper (in a policy), the user can defer the update until you want it to force install. @perryd84 's script has a max deferral limit of 4 days. 

[bwoods]

FYI if @perryd84 's command doesn't work for you try using the one below.

apiUsername="apiaccount"
apiPassword="apipassword"
jamfProURL="https://yourorg.jamfcloud.com"
macSerial=$(system_profiler SPHardwareDataType | awk '/Serial Number/{print $4}')
jamfProCompID=$(curl -s -u $apiUsername:$apiPassword -H "Accept: text/xml" "$jamfProURL"/JSSResource/computers/serialnumber/"$macSerial" | xmllint --xpath '/computer/general/id/text()' -)


/usr/bin/curl -s -X POST -H "Content-Type: text/xml" -u ${apiUsername}:${apiPassword} ${jamfProURL}/JSSResource/computercommands/command/ScheduleOSUpdate/action/install/id/${jamfProCompID}

[emilh]

@bwoods and @perryd84 thank you for those commands/scripts. With a bit of work I've gotten them to pretty reliably trigger updates on Intel machines.
However I still can't get our M1 machines to actually install any system updates. While the MDM command is issued and received by the client, in the end the install fails to initiate.

What I keep seeing in /var/log/install.log are entries like this:

2022-02-09 14:40:47+01 TestMBA softwareupdated[575]: SoftwareUpdate: request for status for unknown product MSU_UPDATE_20G415_patch_11.6.3

2022-02-09 14:40:47+01 TestMBA SoftwareUpdateNotificationManager[983]: (null)：softwareupdated: Service connection invalidated!

[perryd84]

@emilh That error looks like it's not finding the 11.6.3 patch for some reason. I've seen this error on intel macs in the past going from Catalina to Big Sur, the MDM command gave that error and we had to upgrade them a different way by pushing the pkg to upgrade them.

[pipo81]

For some reason I was getting "Battery level is too low" when tested in a Mac Pro and iMac. It works fine if I click continue but I modified the battery level part to show the warning if a laptop is not connected to power source instead below 60% (No battery warning in the Mac Pro and iMac after)

# Check Battery level

if [[ "$(/usr/bin/pmset -g ps | /usr/bin/grep "Battery Power")" = "Now drawing from 'Battery Power'" ]]; then
echo "Computer is not currently connected to a power source."

"$Notify" \
-windowType hud \
-lockHUD \
-title "MacOS Updates" \
-heading "Plug in Power" \
-description "Computer is not currently connected to a power source.
Please connect to a power supply before continuing." \
-icon /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/AlertStopIcon.icns \
-button1 "Continue"
fi

[tzeilstra]

Just wanted to let folks in this thread know about Friday's Virtual Mac Admin Meetup from @rocketman .  The topic for this meeting is "going over the latest way to send macOS updates, with deferrals, through purely an MDM command that works on both Intel and M1 Macs."  Certainly worth a look!  (and for those reading this after the fact, they're typically recorded for later viewing.)

Details here: https://community.jamf.com/t5/virtual-mac-admins-meetup/february-virtual-mac-admin-meetup/ec-p/25714...

[timdambrosio]

For anyone sending MDM commands, either via GUI or API, how are you handling the delay from when it is sent to when it actually happens?  Using the softwareupdate binary in the past was far more predictable and easy to give on screen feedback.  Deploying updates via MDM is mixed bag of instant to 2 hours from my experience.