Simple Apple Software Update Script with Deferral

mbezzo
Contributor III

Hi All,
I've searched and searched and while I've seen the really really cool scripts (patchoo and mm270's come to mind) I'm really looking for something pretty simple: I want to use built-in Apple dialogs so I don't have to install CD or anything else, and I just want it to prompt the user that updates are running, and IF a reboot is required it prompts them again with the option of x number of deferrals before forcing the reboot. Before I start down the path of rolling my own - anybody have something similar that they're willing to share?

THANKS!
Matt

12 REPLIES 12

RobertHammen
Valued Contributor II

Short answer you won't like: what you're looking for doesn't exist.

Honestly, dig into @mm2270's script and work from there.

mm2270
Legendary Contributor III

@mbezzo By "Apple dialogs" are you saying Applescript windows? Because otherwise I'm not clear what Apple dialogs means. The software update mechanism no longer uses the separate Software Update.app. Its all now contained within the App Store. So I'm making the assumption you want to have something that uses OS built in dialoging tools. Is that right?
If so, I think the base of my software update script could certainly be used and heavily modified to only show a list of updates that are going to be installed (with an Applescript window) and then install them (no progress bars of course without something like cocoaDialog) In fact, I plan on releasing a change to that script that doesn't use the checkbox windows but just shows a list of updates that will be installed when the Install button is clicked. its been a request with that script and I plan on adding that in as an option in the future.

As for something that only uses Applescript windows, that goes a bit beyond the focus of my script, but I can see that being done. Its definitely possible.

Have you considered using some of the built in Casper Suite tools, like jamfHelper and/or Management Action?

mbezzo
Contributor III

Hi Mike,
Yeah, sorry - AppleScript windows is what I was referring too. And yes, I've been thinking about diving into your awesome script and customizing it, just wanted to throw this out and see if somebody had already done a bit of the work. :) I'm eagerly awaiting your changes, but know you're a busy guy!

Our current script does use Management Action but our issue is that there's a bug (JAMF has acknowledged) that when a policy that requires a reboot runs with other policies at the same time (something which would be VERY difficult to isolate) the reboot is cancelled! So we get the situation often enough where updates have run that require a reboot and the system slowly sorta falls apart and of course the user is clueless as to what's going on.

I'm also hesitant to dive into this because I really feel like Casper might ACTUALLY flesh this out a bit? I dunno, maybe just wishful thinking on my part! :)

Thanks all!
Matt

alexjdale
Valued Contributor III

If you are looking to solve the restart issue in a policy, you can take a look at my script that forks a restart timer with progress bar (requires CocoaDialog though). https://jamfnation.jamfsoftware.com/discussion.html?id=14940

mbezzo
Contributor III

@alexjdale Very cool - thank you!

mbezzo
Contributor III

Alright so I've been staring at mm2270's code and the patchoo code and I think I'm gonna test patchoo for a bit. (Thanks @loceee!) Question though - which CocoaDialog version are people going with these days? I see loceee has a forked version, there's the 3.0 beta 7 and the release 2.1.1 version. Does it matter? Are any of them more compatible than others? A large majority of my Macs are on 10.11 and I hope to be getting 10.12 started here soon. I've always just used AppleScript dialogs so CD is all new to me.

Thanks!
Matt

millersc
Valued Contributor

3.0 beta 7 is working on our fleet of 10.11.x with no issues currently. Keep us posted on how your testing goes!

mm2270
Legendary Contributor III

cocoaDialog 3.0 beta 7 is actually relatively stable, despite the "beta" name. No major issues with it that I've seen under everything from 10.8 through 10.11. * (other than 2 small ones - see below)
@jhbush1973 had reported on the huge software update trigger thread that he was seeing issues with the progress bar window format under 10.12. However, some basic testing I did under 10.12.0 showed no problems. progressbar continues to work as far as I can tell. My guess is the method I'm using in the script to start and feed the progress bar may be the issue and not cocoaDialog itself, so I'm doing some more tests under 10.12 to see what may need to be adjusted, assuming I can even reproduce the problem that is.

* The only small issues you may see with 3.0 beta 7 under 10.11 (and maybe 10.10) is that it will sometimes generate a generic error about not being able to set or read some preference settings. Its likely using some very outdated code that the new OSes don't like much. It doesn't stop anything from working, but the error messages end up showing up in the policy log, usually. More of an annoyance than an actual problem it seems.
The other issue is the one that @loceee's fork works on, namely that it can't be called to run over the login window. His fork works on addressing that, but I tend to see other strange errors show up when I've used his fork, so I tend not to use it in favor of the original release myself.

mbezzo
Contributor III

Great! 3 beta 7 it is. Thanks for the info @millersc and @mm2270!

glee_edin
New Contributor

In case it helps anyone in future, I have a script which does pretty much this using just jamfHelper. It allows the user to defer updates that require a reboot for 'x' days after they are first seen. After 'x' days it sets the update to install on logout and just displays a 'reboot' button - it could easily be made more brutal and actually enforce the reboot, but we like to be kind to our users, at least until we see what sort of compliance rates we get.

Use At Your Own Risk etc...

https://github.com/UoE-macOS/jss/blob/master/coreconfig-softwareupdate-run.py

It's known to work on 10.11 and 10.12

kadams
Contributor

@glee_edin , how do we specify quiet hours start and end? How does it know if its AM or PM. What time do you typically install updates at login window?. What are your quiet hours?

glee_edin
New Contributor

Hi @kadams the quiet hours are given as integers in the 24hr clock, and are supposed to be the times that you DO want unattended updates to occur. For example, if you set:

QUIET_HOURS_START to 2300
QUIET_HOURS_END to 0600

you'd be saying you want updates to occur only between 11pm and 6am. Our original intention was to allow users to set their own quiet hours through self-service, in the same way that they can on our Windows desktop, but we haven't got that far yet - at the moment it's just a demo, really. If you're interested in the functionality I'd happily help you get it working.