Enforcing Apple software updates in the year 2021.

sdamiano
Contributor

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?

116 REPLIES 116

dstranathan
Valued Contributor II

Some of my frustrations with Software Update deferments:

-Deferments are located in the Restrictions profile - not in the Software Update profile.

-You can only have 1 Restrictions profile per device, so it's easy to get into messy situations with multiple instances of the profile scoped to multiple groups of Macs.

-Deferment options are limited to 1, 7, 30, 45, 60, and 90 days. The 'sweet spot' for me is 14 days - which isn't possible.

tzeilstra
New Contributor III

@dstranathan

Check out this JNUC 2019 video by Matthew Mitchell about editing Configuration Profiles to not only apply only those settings you want to apply (and not every other option available on that part of the interface) but also to set specific values that might not otherwise be available in the interface. We've used this method to set deferrals of three or ten days. We also configured a screen lock to a custom value of 15 mins when the interface would otherwise only permit 10 or 20 minute intervals.

https://www.youtube.com/watch?v=tqF4ls823ig

k3vmo
Contributor

Does anyone just force the updates to download and install with enabling everything in a config?

How would you address this with the end-user? They reboot and unexpectedly have to wait 20 minutes..

It's a heavy-handed approach although management is pushing for us to do it that way.

We're not doing it that way. I currently use a heavily modified version of the defer or install that allows the user to postpone during the workday

harsha
New Contributor III

Hi k3vmo,

May I know how do we do Force update if the users don’t install from self service? Can you plz give me the solution?

perryd84
Contributor

So I finally got a solution working which is running well and giving us good results with patching, which is bringing us inline with our windows estate.

I set up the following:

  • Config profile to stop auto updates and stop users running updates.
  • An Extension attribute pulls in the software updates to the Operating system inventory (I made this as there is no default way to get updates into a smart group)
  • Smart group then looks at this and if it sees anything like "macOS" or "Security" then it falls into an OS updates policy
  • The Policy runs weekly and runs a script which does the following:
    Notifies the user via jamfhelper that updates are available
    lets the user postpone or continue (if postponed a date stamp is added to the mac and used to force the update after 5 days)
    if the user continues then the script will run softwareupdate -i -r -R (which runs recommended updates)
    The user gets another jamfhelper popup to tell them whats happening and then the computer reboots if needed

  • The postponed macs fall into another policy which runs daily and runs the same mac updates script as above but with some added logic to check the date stamp on the mac and force it after 5 days.

We also roll this out in patching waves which again is another piece of scripting which is applied when we provision our macs. They basically get assigned to one of 3 static groups (patching waves) and then updates are rolled out to different waves to avoid potentially bricking all systems if there is a bad update.
we have:
Admin macs
Pilot users
Wave 1
Wave 2
Wave 3

These are all in the exclusion scope of the update policy and removed weekly each month to run through each wave until the whole estate is patched.

Bit long winded but its working really well so far and our estate is in a much healthier place.

Musicmaker
New Contributor III

Thanks for your information. Could you share the extension attribute code with us? Maybe also an example of the smartgroup, policy and jamfhelper?

How do you handle updating lab Macs that may not have a user logged in for weeks? 

I actually used Apple Remote Desktop and logged in as a user and went to System Preferences and hit Restart. At least having the update download was a huge help, hitting Restart was a nuisance but doable. 

harsha
New Contributor III

Hi perry84,

May I know how did you add the settings in jamf pro for giving the time limit to user to install the updates? And also what settings should I need to add to get the notification to user when software update is avaliable? Can you plz help me with this ?

Hi @harsha 

So when the update policy first runs it puts a txt file in a hidden location which has a date stamp. The script then runs daily and queries the txt file and if it finds the date stamp is over 5 days old it forces the user to update. Once it's run, the update policy deletes the date stamp file so the next month it can run again.

harsha
New Contributor III

Hi perryd84,

so can we extend the time more than 5 days? We will give the time limit in the script? or by creating a policy in jamf at that time we will give the time limit?

Hi @harsha 

The time is set from the script just using the date command and writing that to a file.
This is the command I use to check that 5 days are up 

date -j -f %y%m%d -v+4d $FirstCheck +%y%m%d

 the "-v+4d" is the check that 4 days have passed and it will run on the 5th. You can change the number to how ever many days you want. The $firstcheck is a variable which pulls in the original date stamp from the txt file.

harsha
New Contributor III

Hi perryd84,

Thanks for the information. I have few points that i am unable to figure it out.

1.In patch management we will add the software like(11.6, 10.15.7 versions of mac) and what is meant by patch policy in patch management.

2.If we add this version in patch management, then how it is going to users?

3.In policies tab also we have the package tab, should we add the package they also or if we deploy in patch management, it redirects to package?

4.If suppose we deploy the package,then what is the next process?

AJPinto
Contributor III

@harsha You cannot use patch management to install updates anymore, you can just report on what Macs are on what version of macOS. With Big Sur Apple stopped providing Combo and Delta updates to download, so you cannot package them for JAMF to deploy. You can still do this for Catalina while it lasts, but I would not rely on it.

 

Historically updates would have been managed with a script using the softwareupdate binary. Apple has broken this on Apple Silicon but it still works fine on Intel Macs. JAMF absolutely refuses to deal with OS updates directly.

 

As far as your original question with deferrals and notifications. If you are using a policy (and script) you can just bake that in to the policy, or add flags with a script. However I strongly recommend getting away from using softwareupdate in any way shape for form. Apple added forceDelayedSoftwareUpdates to macOS with 11.3 but JAMF has yet to add that switch to the softwareupdate management command. Honestly I recommend talking to your JAMF Advisor. Apple is for the most part where they need to be, JAMF on the other hand just like in the past is refusing to do anything relevant with software updates.

https://developer.apple.com/documentation/devicemanagement/restrictions 

harsha
New Contributor III

Hi AJPinto,

I have few points to know can you please help me with these points,

1.Notify when the new system and security update is available

2.Need to push on 1 system first

3.Need to alert users 2 or 3 times to install the new updates

4.Finally we need to force install the updates if the users don’t take action on installing the updates manually.

Can I know each point how to deploy or how to see in jamf pro so that I can enable it and show it to my team, but i am unable to figure out these.

AJPinto
Contributor III

As I mentioned before the best advice, I have is to get with the JAMF Success rep. Your Apple CA may also be able to provide some information.

 

  1. For security updates subscribe to Apple Email list https://lists.apple.com/mailman/listinfo/security-announce/
    1. If you have OS patch management setup JAMF will notify you when a new built of macOS is released if you have patch management notifications enabled
  2. Always start with a manual install, do that however you wish but the GUI is best. Then use the update management command in the inventory record within JAMF.
    1. To automate if it’s an intel Mac you can use softwareupdate -aiR scripted however you like
    2. If its Apple Silicon the Management command is your only option.
    3. https://docs.jamf.com/best-practice-workflows/jamf-pro/managing-macos-updates/Introduction.html
  3. If it’s an intel Mac you can use a script and policy with softwareupdate -aiR
    1. Deferrals and notifications can be done by policy, just like with any other policy.
    2. Deferrals can also be done by script with flags and nags, but it’s very complicated. https://github.com/ryangball/nice-updater covers it fairly well
    3. Again, Apple is retiring the softwareupdate workflow, DO NOT USE THIS IF YOU DO NOT ALREADY HAVE A WORKFLOW IN PLACE, YOU ARE WASTING YOUR TIME.
  4. (3 again I suppose) If it’s an Apple Silicon Mac the Schedule an OS update management command is your only option to automate updates.
    1. JAMF has not added the keys to allow deferrals or user notification beyond the mac telling the user an administrator is attempting to run updates.
    2. JAMF has not added the force key, so if something prevents the mac from rebooting the update won’t run.
  5. Get with JAMF. They have not added the force install flag to their OS update management command workflow yet.

 

All roads with your questions point you directly to JAMF. Apple is in the middle of changing how they are allowing users to manage macOS updates. The old way is no longer viable so how any of us are doing it is irrelevant. The new way JAMF is dragging their feet at supporting.

taugust_ric
New Contributor III

@AJPinto I'm not going to discourage anyone from following your advice, because it's sound, and I agree this is the direction Apple is going... however, I've been surprised to notice in testing that in macOS Monterey, including the latest release candidates (and in the public betas before it), softwareupdate --install -all --restart is now working to fully install OS updates without a user being logged in at the GUI.

I still need to test using a script or as a command run from Jamf (which will in turn means it runs as root instead of a logged in user over SSH like how I've been testing), but it seems to be at least restored some functionality to the softwareupdate tool in Monterey.  I don't have my hopes up yet though!

@taugust_ric Is your testing on Intel Macs or Apple Silicon? The softwareupdate command works as it did before on Intel Macs regardless of the version of macOS. However considering the only new Intel Macs you can get are the 2020 27in iMac, the 2020 Mac Mini, and the Mac Pro the options are limited on devices that will function with that going forward. I have not tested managing OS updates on Monterey yet as JAMF is notoriously slow to accommodate any OS update management. 
 
 
If Apple did revert their behavior and is allowing bootstrap tokens to run updates again I would be as thankful as everyone else on this thread.

taugust_ric
New Contributor III

@AJPinto testing is on an Intel 2019 iMac.  The majority of the fleet I manage at the moment is Intel so I do my testing there first.  It wouldn't surprise me things are still "broken" on the Apple Silicon side of things.

The softwareupdate command was not working for me on Intel Macs in Big Sur.  Unless a user was logged into the GUI, the command would not complete the install - it would download only.  Only once an account had logged into the system did the softwareupdate command install the macOS updates successfully - however non-OS updates (Safari, Video Codecs, etc) would install fine.  I believe there's some other threads on Jamf Nation about that issue.  I had experimented with some policies that enabled an account to automatically login, run the softwareupdate command, then disable automatic login, but it was very unreliable and sometimes left the systems in a logged in state.  I work in higher ed and a third of the installed systems are in labs where systems are not assigned to end-users.

ianatkinson
New Contributor III

I'm in higher education and we have the same situation with Big Sur and Intel, the softwareupdate stopped working for system updates from about 11.4 onwards I think.

Sometimes when people say they aren't having issues I think it's because they're referring to staff who maybe have admin privileges running policies. In education the requirement for managing updates is always going to be full automation of large amounts of machines with no users logged in and no admin users logging in that can be done to a non disruptive schedule.

I had to get 11.6 on to everything to fix an issue with scanners not working (we're an arts university so have hundreds of them). The only way I could do it was to push out the whole Big Sur installer to every machine and use that to patch which worked OK but it's an awful lot of network traffic so not really the sort of thing you can just push all at once.

I'm hoping as well that in Monteray the binary works again, the M1 machines are a separate headache but we still have 600+ Intel ones at the moment to consider.

Ian

dstranathan
Valued Contributor II

@tzeilstra I attended Matthew Mitchell's session I think. It was pretty handy, and I have a few custom profiles that leverage what he demonstrated.

Correct me if I am wrong, but I don't I can break out the software update deferral times (forceDelayedSoftwareUpdates) into a custom MDM profile because the preference domain for the forceDelayedSoftwareUpdates key/value pair is com.apple.applicationaccess - which is used by a ton of other restrictions that I also need to be managed. You can't have multiple profiles managing the same preference domain, can you? I know the most restrictive setting (usually) takes priority when conflicts occur, but this would be rather messy to manage.

Here is a listing of most of the key/value pairs in the com.apple.applicationaccess preference domain:

allowCloudDocumentSync
llowCloudDesktopAndDocuments
allowSpotlightInternetResults
allowMusicService
allowCloudKeychainSync
allowCloudBTMM
allowCloudFMM
allowCloudBookmarks
allowCloudMail
allowCloudCalendar
allowCloudReminders
allowCloudAddressBook
allowCloudNotes
allowFingerprintForUnlock
allowPasswordSharing
allowPasswordAutoFill
allowPasswordProximityRequests
allowCamera
allowContentCaching
forceDelayedSoftwareUpdates
forceDelayedAppSoftwareUpdates
enforcedSoftwareUpdateDelay
allowAirPrint
forceAirPrintTrustedTLSRequirement
allowAirPrintiBeaconDiscovery
allowScreenShot
allowRemoteScreenObservation
forceClassroomUnpromptedScreenObservation
forceUnpromptedManagedClassroomScreenObservation
forceClassroomUnpromptedAppAndDeviceLock
forceClassroomAutomaticallyJoinClasses
forceClassroomRequestPermissionToLeaveClasses
allowActivityContinuation
allowDeprecatedWebKitTLS

In my environment, I need (3) scopes for Software Update deferrals

0 days = Me & fellow Mac admin's Macs
7 days = IT Macs
30 days = Production Macs

Also, If I'm not mistaken, I can't set the value of enforcedSoftwareUpdateDelay to 14. I think it MUST be 1, 7, 30, 45, 60 or 90, otherwise, macOS will not honor the key/value pair, correct?

tzeilstra
New Contributor III

@dstranathan I'm pretty sure you can have multiple Profiles addressing the same Preference Domain as long as they're not both trying to set the same key/value pair. I know we certainly use several different profiles for several different PPPC and Notification payloads. I can also confirm that you don't need to stick to the values specified in the GUI for the delays. One thing you do need to confirm is that the profile is signed BEFORE you upload it back to Jamf. if you don't sign it first, Jamf will attempt to "correct" it and exactly what happens next is anyone's guess.

dstranathan
Valued Contributor II

Thanks, @tzeilstra - Ill play with it and see what I can come up with.

k3vmo
Contributor

@dstranathan Was Matthew's session something that was public - or was this a training class you were in? I'm intrigued.

Schmidty
New Contributor III

Is there a way to block Big Sur from checking for updates and users seeing that updates are available? I know that's not the ideal solution but working in a 6-12 school making sure students, especially the younger ones, keep their macs updated and not update it during the school day stresses me out.

dstranathan
Valued Contributor II

@k3vmo This was a JNUC session in Minneapolis a couple years ago. It’s still available on YouTube.

fernando_gonzal
Contributor

Are MDM update commands in Big Sur unreliable?

I tried sending an MDM command to an 11.4 Big Sur Mac to download update, install and restart but while it seemed to download from the management history, and it even rebooted, nothing occurred (still at 11.4 instead fo 11.5). Nobody was logged into this machine. 

 

Any suggestions?

Screen Shot 2021-07-22 at 10.09.52 AM.pngScreen Shot 2021-07-22 at 10.16.33 AM.png

Yes, I concur with you MDM commands are unreliable with Big Sur and even worse all the logs say everything is working. 

I think in the end we are going to try to simply try to enforce check updates on our Macs but provide a deferral period.

So basically we are going to take the Apple shipping default below

Screen Shot 2021-08-06 at 10.15.54 AM.png

Apply a Configuration Profile

Screen Shot 2021-08-08 at 10.38.26 PM.png

 

Which will enforce all settings including installing macOS updates

box-image.png

This will auto download and will initially just notify a user that there is an update available and whether they want to install now or later.

box-image (1).png

If they ignore this message then a day or two later the computer will simply alert them that the update will install later that night.

download (2).png

Though if they have any unsaved worked it will stop the reboot process so there is safety for that.

download (3).png

Next time they try to restart the computer the update will finally apply.

 

For additional safety a Defer Update Configuration Profile can be used. This one below is set for 15 days. 

I didn't want to use the built in Restrictions Config Profile from Jamf since it has too many settings.

So @takayuki helped me with this part to create a custom one that only does the defer update.

Screen Shot 2021-08-08 at 10.36.23 PM.png

 

 

Seems to work well on Big Sur Intel though I haven't tried to see what the behavior is on M1

snovak
Contributor

They still aren't working well for me; getting very frustrating as I approach the school year and am on the brink of upgrading my Fac/Staff stations.

snovak
Contributor

And then you see stuff like this in /var/log/install.log and you just die a little: 2021-07-22 15:55:52-05 CAC301-MD-TS softwareupdated[368]: SoftwareUpdate: request for status for unknown product MSU_UPDATE_20G71_patch_11.5

Jamf Pro recommend using Mass Action Feature which can NOT be scheduled and KILL the network. I tried this on just 25 iMacs and my network was completed flooded and this was at night. It also worked on some and did not work on others. Very inconsistent.

the Policy running softwareupdates -i -a -R says is works in the logs but nothing happens as well. I can't believe the answer is to turn on Apple Automatic Updates or run manually. 

    • Log in to Jamf Pro.

    • Click Computers at the top of the page.

    • Click Smart Computer Groups.

    • Select the name of the smart computer group you created.

    • Click View at the bottom of the pane.

    • Click Action at the bottom of the pane.

    • Select Send Remote Commands.

    • Click Next.

    • Under Remote Commands, select Update OS version and built-in apps (v10.11 or later computers enrolled with DEP only).

    • At the bottom of the pane, select one of the following for Update Action:

      • To download the update on computers for users to install themselves, select Download the update for users to install.

      • To download and install the update on computers automatically, select Download and install the update, and restart computers after installation.

I'm thinking it might be possible to schedule it using scripts. My current thought is to write a script to hit the API to get the computer ID and then hit the API again to send the Install updates command.

 

And it doesn't help at all that Apple released a patch for a 0-day and we admins have zero reliable ways to deploy said patch.

#!/bin/bash
# Variables used by Casper
USERNAME="" #Username of user with API Computer read GET and Computer Group PUT access
PASSWORD="" #Password of user with API Computer read GET and Computer Group PUT access
JSS_URL='https://jss.my.com:8443' # JSS URL of the server you want to run API calls against
Headers="Accept: application/xml"


# Variables used by this script
JSS_ID_PATH="/tmp/comp_id" # Text file with one JSS ID per Line
IFS_OLD=$IFS
IFS_TEMP=$'\n'

IFS=$IFS_TEMP

## Functions
#################################################################################################### 
# Include DecryptString() with your script to decrypt the password sent by the JSS
# The 'Salt' and 'Passphrase' values would be present in the script
function DecryptString() {
    # Usage: ~$ DecryptString "Encrypted String" "Salt" "Passphrase"
    PASSWORD=$(echo "${1}" | /usr/bin/openssl enc -aes256 -d -a -A -S "${2}" -k "${3}")
}

function GetComputerID() {
	# Get the computer ID
	SERIAL=`system_profiler SPHardwareDataType | awk '/Serial/ {print $4}'`
	URL="https://jss.my.com:8443/JSSResource/computers/serialnumber/$SERIAL"
	RESPONSE=$(/usr/bin/curl -H "$Headers" -u "$USERNAME:$PASSWORD" --url $URL) > /dev/null
	JamfId=$(echo $RESPONSE | xpath -e '//computer//general/id' 2>&1 | awk -F'<id>|</id>' '{print $2}') > /dev/null
    /usr/bin/defaults write /Library/Preferences/com.my.systeminfo JamfId "$JamfId"
	echo "$JamfId" > /tmp/comp_id
}


# This uploads the $JSS_XML_INPUT file to the JSS
function RunMDMCommand() {
	curl -k -v -H "$Headers"  -u "$USERNAME":"$PASSWORD" "$JSS_URL/JSSResource/computercommands/command/ScheduleOSUpdate/action/install/id/$JamfId" -X POST > /dev/null
	echo "$?"
	echo "Done"
}

function CleanUp() {
	rm $JSS_ID_PATH
}
	
	
## Script
#################################################################################################### 
# Script Action 1
ENCRYPTEDSTRING="$4"
SALT=""
PASSPHRASE=""
DecryptString "$ENCRYPTEDSTRING" "$SALT" "$PASSPHRASE"
GetComputerID
RunMDMCommand
CleanUp

I'm trying out this script I wrote/rewrote to see if it will handle reboots too.

fernando_gonzal
Contributor

The MDM command seems to work but only really when a user is logged in? I thought I remember someone saying that a user had be to be logged in for the Download and install the update MDM command to work. Could someone confirm?

And I just tried this yesterday, and it prompted for my user password before it installed..

Was this on an Intel or M1 Mac?

jamfjosh21
New Contributor

I have spent the last couple of days working with a colleague testing out various methods of trying to update Big Sur on our Intel iMacs since we noticed that the Software Update payload policy we had setup was doing nothing. These are iMacs in a higher education shared lab environment where our users are not logged on at the time we would like to action updates (ideally run automatically overnight).

We have tried the following...

  1. Deploying the ‘softwareupdate -i -a -R’ command as a script via a policy in Jamf which was the initially advised workaround by Jamf Support. This was unsuccessful.

  2. Deploying the ‘softwareupdate -i -a -R’ command in the Files & Processes payload in a Jamf policy. This was suggested by Jamf Support during a support call and we are advised this is the working “workaround”. From the logs this states that it completes and from the log details looks successful as it downloads the latest update and advises it’s restarting but this is actually a false positive the restart never occurs. The update downloads but the restart does not occur unless a user is logged in at the time the policy runs. The only way to kick off the update is by logging in and restarting manually from either software updates or running the ‘softwareupdate -i -a -R’ command in the terminal.

  3. Deploying an additional policy with the Restart Options payload configured to ‘Restart if a package or update requires it’ and is set like this for both the No User Logged In Action and User Logged In Action. Hoping that with the software update being downloaded to the machine this would issue a restart and install the update that requires it. This did not work.

  4. Deploying an additional policy with the Restart Options payload configured to ‘Restart Immediately’ for both the No User Logged In Action and User Logged In Action. Again hoping that the restart would trigger the installation of the downloaded update. It did not.

  5. Resetting the NVRAM of some of the devices and trying to deploy the ‘softwareupdate -i -a -R’ command in the Files & Processes payload again. This was a bit of a shot in the dark but seeing some other admins advise that their devices were stuck on the black screen with the Apple logo looking like it was installing and doing this resolved it and installed the update. The Macs still would not restart automatically and required a user to be logged in.

It is pretty clear that updates for Big Sur cannot be managed automatically without some user involvement. On intel Macs a user needs to be logged in for Jamf's advised workaround (I use this term loosely...) of using the 'softwareupdate -i -a -R' command. M1 devices are another kettle of fish that we are going to have to deal with soon as well.

This is quite ridiculous to say the least. This OS came out 8+ months ago with advertised zero-day support yet here we are. Surely we can't be the only higher education organisation that will have to stick with macOS Catalina for the start of term unless we can get a working solution.

Thank you for your detailed account of exactly what is happening in our
environment as well.
--
Debbie Michels
Apple Specialist
ITS Information Technology Services
Bergen Community College
Pitkin Building - Room A236
400 Paramus Road, Paramus NJ 07652

dmichels@bergen.edu
(O) 201-879-1694

*STAFF/FACULTY* Working Remotely Instructions at Bergen:
https://bergen.edu/REMOTE

*STUDENTS* Self Service
https://bergen.edu/self-service/

Thank you for your detailed account of exactly what is happening in our environment as well. It has been too long for there not to be working fix.