Re: Enforcing Apple software updates in the year 2021.

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?

1 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

View solution in original post

184 REPLIES 184

It is under Restrictions. Here is also an example of a naked profile. If signed and uploaded JAMF does not alter anything. (You have to calculate your own UUIDs in this example)

<?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">
  <dict>
    <key>PayloadUUID</key>
    <string>E61CEEFB1921B511F6</string>
    <key>PayloadType</key>
    <string>Configuration</string>
    <key>PayloadOrganization</key>
    <string>Company</string>
    <key>PayloadIdentifier</key>
    <string>E61CEEF861921B511F6</string>
    <key>PayloadDisplayName</key>
    <string>Apple Software Updates</string>
    <key>PayloadDescription</key>
    <string/>
    <key>PayloadVersion</key>
    <integer>1</integer>
    <key>PayloadEnabled</key>
    <true/>
    <key>PayloadRemovalDisallowed</key>
    <true/>
    <key>PayloadScope</key>
    <string>System</string>
    <key>PayloadContent</key>
    <array>
      
      <dict>
        <key>PayloadUUID</key>
        <string>2451A00F-6F87A6219DDE</string>
        <key>PayloadType</key>
        <string>com.apple.applicationaccess</string>
        <key>PayloadOrganization</key>
        <string>Company</string>
        <key>PayloadIdentifier</key>
        <string>2451A00F-86E9-4621-921D-6F87A6219DDE</string>
        <key>PayloadDisplayName</key>
        <string>Restrictions</string>
        <key>PayloadDescription</key>
        <string/>
        <key>PayloadVersion</key>
        <integer>1</integer>
        <key>PayloadEnabled</key>
        <true/>
        <key>forceDelayedSoftwareUpdates</key>
        <true/>
        <key>forceDelayedAppSoftwareUpdates</key>
        <true/>
        <key>enforcedSoftwareUpdateDelay</key>
        <integer>7</integer>
        <key>enforcedSoftwareUpdateMinorOSDeferredInstallDelay</key>
        <integer>7</integer>
        <key>enforcedSoftwareUpdateNonOSDeferredInstallDelay</key>
        <integer>7</integer>
        <key>forceDelayedMajorSoftwareUpdates</key>
        <true/>
        <key>enforcedSoftwareUpdateMajorOSDeferredInstallDelay</key>
        <integer>90</integer>
      </dict>
  
    </array>
  </dict>
</plist>

Configuration Profiles > +New > Restrictions > Functionality > Scroll all the way down.

for those following this thread: read this blog post for the sorry state of managing softwareupdates in 2021...:-(
https://travellingtechguy.blog/demystifying-macos-big-sur-updates-and-jamf-pro-10-29/

@maurits-pro wrote:
for those following this thread: read this blog post for the sorry state of managing softwareupdates in 2021...:-(
https://travellingtechguy.blog/demystifying-macos-big-sur-updates-and-jamf-pro-10-29/five nights at freddy's

Thank for your sharing.

@KSibley See here

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.

@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

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

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?

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.

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.

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.

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.

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?

@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

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.

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.

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
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
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.
(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.
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.

@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.

@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.

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

@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?

@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.

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

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

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.

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

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?

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

Apply a Configuration Profile

Which will enforce all settings including installing macOS updates

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.

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.

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

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.

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

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.

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.

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?