Hey,

Just a snippet from my and @ChewtonTown code

RestartCheck=softwareupdate -l 2>&1 | grep restart

if [[ "$RestartCheck" == "[restart]" ]]; then

restartRequired="yes"

else

restartRequired="no"

fi

So we call softwareupdate -ia to install all updates, if restartRequired is yes then it calls shutdown -h now to invoke it and works fine

I'm having issues with the AppleUpdateDefer1.sh script. I was able to follow the instructions in the Readme file and everything works beautifully except for the fact that it doesn't seem to calculate the remaining deferrals. Each time I click on Defer the next day it still continues to show 3 Days (my default). Can someone help point me in the right direction. Thanks!

@Taboc741 @samuelbrown
I too was having the issue where when running the script on my computer that has no updates it was force rebooting the computer.
the camelcase on line 44 and 70 is messed up
they reference shutdownRequired instead of shutDownRequired

that resolved the issue for me.

I'm to the point where I may as let Apple manage the updates and simply check boxes in the system preferences using MDM or scripts.

Sorry - but has any option to post the script that works with the new kind of update apple forces with reboot ?. There are many variations of the script and just wondering if we could have a working 10.14.4 added

@jameson I'm going off of https://github.com/taboc741/MacScripts/tree/master/A-Kinder-macOS-Update but the scripts are not yet perfect. Note the changes on the softwareupdate script I posted yesterday:
the camelcase on line 44 and 70 is messed up
they reference shutdownRequired instead of shutDownRequired

@strayer your CamelCase issue was fixed in the Git a couple days ago.

Currently for 10.14.4 I am looking at just junking the whole intelligence around shutdown and forcing all to use softawareupdate -iar despite the lousy delay experience for non shutdown type reboots. Really annoying that apple didn't tell me straight on how they were going to flag these shut down type updates. more to come once I get some more testing in.

As there can never be too many of these, here is what I have been working on:
https://github.com/ryangball/nice-updater

Maybe this will help somebody.

somehow a mac I was testing this on is in a constant boot loop after installing updates.

Seems to wait about a minute or so then restarts again. Only happens after logging in. High Sierra.

I've attempted to use the built-in updater through the app store, so I know it's not our netSUS server.

Anyone else seeing this behavior?

Edit:

I see at the end of the update script, there is a line

#!/bin/sh



jamf reboot -minutes 1 -background -startTimerImmediately & sendToLog "Script exit"

wonder if this is getting stuck somehow.

Also, for users who want to just use their self service icon, you can just do this:

##Path to icon used in user messaging.  

LoggedInUser=`who | grep console | awk '{print $1}'`

icon=/Users/$LoggedInUser/Library/Application Support/com.jamfsoftware.selfservice.mac/Documents/Images/brandingimage.png

The software update script already has this, so you can move the icon= variable down after the command to capture the icon, as I think it needs to be after to run correctly.

@jbellez in theory the existing icon variable is there for customizing to whatever icon you want, but the script does check to make sure the icon is real (ie didn't get deleted or something) because otherwise the JamfHelper windows look really funny. That is all the validation should be doing, of course I use the system icon so if that isn't how that code block runs give me a shout or file a bug on the git and I'll see what I can figure out.

For everyone else I have some very lightly tested script labeled as SoftwareUpdate4-beta.sh on the GIT that should tackle how Apple is implementing Shutdown based updates. It is working on my VM's and I'll be taking it to my testers internally this week, but I know a few people are dead in the water with the old broken script and I have been laid up with being super sick so the patch has been slow to roll from my finger tips. @Cayde-6 Your solution is probably simpler and more resistant to Apple changes in the future. I considered giving up on letting my users work while the update installs and going your route, but I did clooge a way out so the inevitable has been delayed a little while longer.

Thanks all for helping keep me honest in my script. the github in question

@jbellez re-your boot looping issue. I assume you can check if the jamf binary call is stuck by looking at the jamf logs. All I am using in the shell there is a canned Jamf call to the binary to give a nice but enforced reboot process. My thought process here is with the binary doing the shut down we have a shot it won't kill itself until after it's submitted it's logs back to Jamf. I obviously could be wrong here, but that was my thought process. You absolutely could trade that line for a shutdown or reboot command and achieve the same effect. Though you might want to pass a sleep in there as well to give Jamf a chance to save and submit it's logs.

unfortunately, it was rebooting so fast I couldn't do much except wipe the machine.

Luckily it was a test machine, so no harm done.

Strangely enough, it did start working later, no real changes to the system/script. Maybe there was an issue how jamf was passing the logs as you said, since that 1 minute timeout was pretty quick.

I was trying to review the script, but did not see anything to reset the number of deferrals after a successful installation. Did I miss it, or was there a line of code that says to set something like:

defaults write com.YourOrg.SoftwareUpdate.Deferral remainingDeferrals $default

Currently, I am testing the deferral part through self service and can get the count down to decrease each time it runs. However, the next time you run it after a successful patch, it immediately starts with no deferrals left.

@jbellez That looks to be a good find there. I am not sure how I didn't find this earlier. I fixed the zero issue by adding a check for 0 in the deferral calculation. I also added your line there after the install script triggers complete (multiple places in the script). This does introduce the risk of a user somehow killing the update script after the deferral process and getting a free number of $default deferrals again. Jamf is usually pretty obnoxious about hiding scripts though so the risk is probably pretty small.

@Taboc741 Could you ever create a Github item for this script with documentation and images of the workflow.

@Taboc741 I'm just thinking most users won't know how to even get that far.

The reset counter to default will only be on any successful or no updates found situations. Pretty low risk otherwise.

EDIT: Actually, I think you need to create another variable for $default, as I don't think that value is in the actual update script, only the deferral side.

@kerickson My script does in fact live on a git now. You can find it here: https://github.com/taboc741/MacScripts/blob/master/A-Kinder-macOS-Update

Feel free to shout if I've missed something.

When I get back to a real computer I will add it to the original post. Seems like at this point it is pretty hard to read the whole post and find the occasional reference.

hmm I just looked at your updated defer script.

Wouldn't checking for 0 just make it reset to default after you hit zero?

I feel like the reset should be handled from the update script side.

##Check if $remainDeferrals is $null or 0

    if [ $remainDeferrals = "" -o $remainDeferrals -eq 0]; then

deferral=$default

Thank you for this!!!

so i did make some edits to the software update script and what i mentioned about resetting the remaining deferrals does appear to work.

default= (number of deferrals) ##only need to define this during the variables

defaults write com.YourOrg.SoftwareUpdate.Deferral remainingDeferrals $default ##needs to be added to each completion step

I added this after what appeared to be the update completion steps. I had additional pending updates on a machine and it looks like the counter went back to my default of 3 deferrals.

I also figured out when the system will enter a reboot loop state. Something happens if you try to interrupt the software update script where i think it's always trying to run the last reboot command after 1 minute. I think we may need to rethink how this is being executed, as I think it's getting stuck as an else/catch all statement, then continually restarting because of it, as it never hits the exit command.

My only fix to not destroy the machine was to uninstall jamf using the removeframework command via terminal. this stopped the rebooting. None of the flush commands would clear the running task, unless someone knows how to do so otherwise. I was using sudo jamf XXXXX. where XXXXX was the various flush commands. You had to be quick, because after 1 minute, the computer would restart again.

Rolled this out to a few hundred of our users, and somewhere between 5 and 10 % of them have an issue where they restart to an installation error that prompts them to select their startup disk.

Has anyone else seen this?

Yes, you need to modify your script to perform a shutdown rather than reboot

@strayer Not to hijack the topic but that sounds suspiciously like the same issue we've seen on campus with High Sierra systems. In almost every case it's been after applying the security update. Some users who had the issue claim that they hadn't applied updates but I didn't get to personally look into the situation to confirm. Simply selecting the startup disk gets them back up and going again though.

In all of these cases there was not any script being used. When updates were applied, it was the user kicking them off. I mentioned this to our Apple SE months ago and isn't aware of anyone else having this issue. This all started last summer and we still have some High Sierra systems doing this. We had two just in the last week.

@jhuls We've had that happen a few times randomly as well. But it's been a few one off's here and there for us. But in rolling out this update policy after 10.14.5 came out on friday we had 12 people yesterday.

@Cayde-6 I removed the jamf reboot command and the script now only shutsdown with shutdown -h now so hopefully that'll prevent those issues

I was just about to post regarding the shutdown needed for T2 Macs. I modified the end of the script with this. (credit goes to kish.jayson from the macadmin's slack)

echo ""

    echo "User "$LoggedInUser" is logged in and restart is required."

    OUTPUT=`softwareupdate -ia --no-scan | grep -e halt`



    echo "Informing "$LoggedInUser" of pending restart."

    /Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper -windowType hud -lockHUD -heading "$heading" -description "$description" -icon "$icon" > /dev/null 2>&1 &

    echo ""



    if [ "$OUTPUT" != "" ]; then



        echo "Shutting down the system immediately."

        halt



    else



        echo "Restarting the system immediately."

        reboot



    fi



elif [ "$LoggedInUser" == "" ] && [ "$restartRequired" != "" ]; then



    echo ""

    echo "No user is logged in and restart is required."

    OUTPUT=`softwareupdate -ia --no-scan | grep -e halt`



    if [ "$OUTPUT" != "" ]; then



        echo "Shutting down the system immediately."

        halt



    else



        echo "Restarting the system immediately."

        reboot



    fi



else



    echo ""

    echo "Restart is not required."

    softwareupdate -ia --no-scan



fi



exit 0