Skip to main content
Question

Ideas for multi-stage driver update?

  • December 19, 2014
  • 1 reply
  • 21 views
chris_kemp
Forum|alt.badge.img+20

Hi all,

I need to upgrade a proprietary driver on our Macs. The process is to run a command-line uninstaller, reboot, then install the new driver from a pkg. and reboot again.

I'm trying to figure out the best way to attack this, especially since some of our machines are in use pretty much 24/7. I've thought about having some of the users do it via Self Service, although they've not yet been trained to do so (we haven't employed it on these machines, although it's in place). This would be some sort of two-stage process, I imagine: run the uninstall script from Self Service and maybe deposit a placeholder file to identify the machine as in-process; then when it comes up again have them go back to Self Service and run the new installer.

This would be fine, except frankly I don't trust all of our users to do it - and since they are also sharing the machines among shifts, we don't want users spending time trying to upgrade a machine that's already been done, or assuming it's been done & blowing it off...

So I'm also trying to figure out a way to automate it and do it in the off hours (at least some of the machines have "down time" of sorts). Ideally, it would operate like a post-image install after the initial reboot, with a notice saying something like "Software is being installed, please wait" while in process. Not sure offhand how to do this, though, in a way that the user cannot ignore.

Alternatively, perhaps there is a better way that I'm not seeing - so, I put the question to the wonderfully intelligent folks of the Nation. :) How would you handle something like this?

    1 reply

    mm2270
    Forum|alt.badge.img+24
    • mm2270
    • Legendary Contributor
    • December 19, 2014

    I would consider dropping the installer into a custom location as part of the first policy doing the uninstall. IOW, after it successfully uninstalls via the script, drop the new installer into a location like /private/var/installers/ or whatever. Then also use either a first run type of script that would kick off a jamfHelper full screen message after reboot and run the local installer using installer -pkg /path/to/package.pkg -tgt / or something, then kill the full screen lock and reboot again. You could also deploy a custom LaunchDaemon and script combo that would call the cached installation, and the jamfHelper full screen message as an example.
    You'd need to ensure the first run script or LaunchDaemon won't get called again of course, so do a cleanup as part of the script that does the installation at the end.

    The main question here really is, how do you kick this all off? Self Service? If so, you'd probably want to have a nag screen come up at least once a day letting end users know they need to do this. If you nag them enough hopefully they'll just put aside the time to get it done and out of their face. I would think whatever you choose to do it will need to be user interactive since it will disrupt any workflows, so if you can get users to actually do it, that would be best.

    I have a custom script using cocoaDialog we sometimes use for purposes like this. The script sees cached installers in a specific location, then pops up a screen letting them know an update is ready to be installed. If they click "Install Now" it runs the installation straight away and shows an actual progress bar as it installs, and then a final message when its done so they know they can get back to what they were doing. Doing it this way means they don't have to launch Self Service. it pops up, they can click Later and it sets a deferral flag, but if they choose to do it then and there it just does the installation. Something like that might work for you.

    Terms & ConditionsCookie settingsAccessibility statement