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.

Please test! But this may be the answer must be run as a script:

/usr/sbin/softwareupdate --install --all --include-config-data --restart --force

I'm not sure what difference the --include-config-data flag is supposed to make (not seen that before) but in testing that doesn't make any difference for me.

On an 11.5.2 machine which can see it has the 11.6 update available it still fails to restart and you can see

softwareupdate[14222]: SUOSUUpdateController: Failed to issue software update restart

in install.log the same as it was doing previously

Ian

Try adding this to script: 

#!/bin/bash



# get the currently logged in user

currentUser=$( echo "show State:/Users/ConsoleUser" | scutil | awk '/Name  { print $3 }' )

echo $currentUser



# get the current user's UID

uid=$(id -u "$currentUser")



# convenience function to run a command as the current user

# usage:

#   runAsUser command arguments...

runAsUser() {  

  if [ "$currentUser" != "loginwindow" ]; then

    launchctl asuser "$uid" sudo -u "$currentUser" "$@"

  else

    echo "no user logged in"

    # uncomment the exit command

    # to make the function exit with an error when no user is logged in

    # exit 1

  fi

}





# main code starts here



# run the softwareupdate command as logged in user

echo Downloading software update now...

echo Running policy as "$currentUser"

runAsUser softwareupdate -d



#give time for software update to download (30 minutes)

sleep 1800



# run restart as root

echo Running restart...

/usr/sbin/softwareupdate --install --all --include-config-data --restart --force

I think adding the top part of script makes sure the Root user is running it. Please let me know if it works. 

I'm not sure what difference the --include-config-data flag is supposed to make (not seen that before) but in testing that doesn't make any difference for me.

On an 11.5.2 machine which can see it has the 11.6 update available it still fails to restart and you can see

softwareupdate[14222]: SUOSUUpdateController: Failed to issue software update restart

in install.log the same as it was doing previously

Ian

The test I did was as root, doesn't make any difference I'm afraid. It's not down to permissions the binary just can't do the reboots any more for some reason.

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.

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

Thanks for that, @jtrant .
We currently have a practice that "works" but is overly complicated and I'm trying to simplify.

Right now we use a two-pronged approach:

1) If available SWU count is > 0 they get a jamfHelper notification stating that they have a week to apply the update. JamfHelper gives a cancel button, or a button that takes them to Sys. Prefs to apply the update. This also has a payload for #3, below.
2) They also get a daily reminder/nag notification that there are updates available.
3) After 6 days, they get a JamfHelper notification, which they cannot close that has a 24 hour countdown timer. Only button is "apply and restart". They can press it, or it will happen automatically at the end of the countdown.

We're adopting a standard approach for any other items that need reboots (firmware pw. changes, anything else that comes up) and wondering about just using the same notification for "hey, you have updates that need a reboot". Simpler, and more consistent with our other practices, but...

I'm looking to simplify my process. The way my org wants updates deployed, I have set up 3 different config profiles with different deferment dates (o days, 7 days, 30 days) and 3 policies to apply updates. I have each policy set to notify the user the the policy is going to run and install any updates, and they can defer for up to 3 days. I'm not sure if that is the "best" approach, but its what I came up with given the requirements.

I've had to resort to just using the Jamf Helper to notify users that updates for Big Sur are available, and to manually install them. I've set up a smart group so that any Big Sur machines not on 11.4 will get the notification.

As a college, none of the staff or students are admins on any of our systems. If I presented them with software updates, there will be one of several responses...
Ignored totally.
Updates applied.
Helpdesk ticket for the popups happening.
Updates applied as a means to avoid working.

As a norm up to now, I use a Saturday as the time to run all of my updates. Adobe, Microsoft and Mac OSX. Reboots can happen at this time as there are no classes. I used to run some of the updates early in the mornings, but slow connections can make the reboot delay until after classes start, which seriously impacts on teaching and learning time.

For me having the ability to install updates at a specified time would be the ideal, and having the server do this for me is the obvious choice. Why do something yourself when you can have a server do it for you.
If I cant schedule it, then how about having it as one of the Mass action options? At least then I can sign in to the server on a Saturday and then hit the button to download and install updates, for all of a given group of Macs.
M1 Macs are going to be whole new problem, as they have to have user approval to install updates I cant update them with no user logged in. So this year, it will be around 50 M1 macs for us, next year it will be an additional 200 going M1. Does this mean I will need to spend my weekends sitting in front of a computer, signing in to and updating Macs. That is if Apple will allow it to be done via a remote session??

So to JAMF I ask for the ability to apply updates to Macs that have no user logged in, at a time of my choosing. If the MDM command can do the updates, please put it in a place where I can actually use it. The simplest solution would be a Mass Action item, with a schedule, run now, run tomorrow, run on the weekend, run at nine o'clock.

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.

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 

 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.

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