Updates

markc0
New Contributor III

Hello All

Just throwing this one out there (sorry if its been discussed before).
Im currently throwing out application updates using the jss and logout policies however users are complaining about the time it takes to re-start the mac.
Im quite intrested then in chnaging this to install the updates whilst the user is logged in, however i know i would need to do some checking on whether the application that is to be updated is open or not.
Anybody else doing this?

13 REPLIES 13

sprattp
New Contributor II

Hello,

We currently run updates both OS and Applications whether the user is logged in or not as we have a large laptop estate and this is the only way to keep things more up to date.

For OS: We use script to detect is someone is logged in and if no restart is required then the update is applied, otherwise a user prompt is initiated asking them to install the update and then logout so a restart can happen.

For Applications: Using snapped DMG, allows you push out updates even if the application is running, although Outlook may be a concern, i had no problems so far. You can also use this for some OS updates as well

There are a lot of handy scripts in the Jamf Discussions, to help with this

markc0
New Contributor III

Many Thanks, however i googled snapped DMG and did not get any hits.
Is this downloadable by github or something?
thanks

sprattp
New Contributor II

Sorry should have expanded more, you use Composer to create the .dmg's

markc0
New Contributor III

yes, sometimes other times i place the pkg straight into casper admin

dpertschi
Valued Contributor

Have a look at this thread

markc0
New Contributor III

strange i got a 404 error on that page dpertschi

dpertschi
Valued Contributor

Why do the simple things escape me sometimes…

https://jamfnation.jamfsoftware.com/discussion.html?id=13056

markc0
New Contributor III

Thanks i see this, is there anyway possible to have both the script & the package within the same policy?
not keen on two policies for each application

bpavlov
Honored Contributor

Upload the script and set it to run BEFORE and also add a package to the same policy.

markc0
New Contributor III

Hi & Thanks however i have done this and what happens is the package just runs anyway regardless of whther the application is running or not.
i removed the package to check the script and the script (below ) works fine (yes i did set the script to before).
Any ideas why its running anyway?

!/bin/bash

process="$4"

processrunning=$( ps axc | grep "${process}$" )
if [ "$processrunning" != "" ]; then echo "$process IS running, try again tomorrow."
else /bin/echo "$process IS NOT running, will try to update it now." /usr/sbin/jamf policy -trigger "$5"
fi

bpavlov
Honored Contributor

Sorry I missed the context of what you were trying to accomplish. Unfortunately, policies aren't smart enough to determine when it should stop itself. It runs through all the items/actions in the policy regardless of the status. There's a feature request that asks for this: https://jamfnation.jamfsoftware.com/featureRequest.html?id=3453

I want to say I have also seen a feature request that would hopefully implement a way for Casper to detect running processes before proceeding with an install, but I can't recall it and may very well just be confusing it to linked thread you already saw.

mm2270
Legendary Contributor III

Yeah, because Before Scripts can't actually tell any items coming after it in the policy workflow to run or not run. This is one thing about how policies work that I've had a real issue with for years now. Basically, every item in a policy workflow is more or less blind to what comes before it or after it. Its like they are just disparate items thrown together in a sequence, but not with much intelligence in how they operate. So you can't, for example, have a script run as Before send an exit code to the package portion of a policy to stop it from installing. The only possible way I can think of to do it would be to put an actual exit code into the script when the application is running, as in exit 1 This may stop the package part of the policy, but actually I don't even think that will work. It might still install the package but then report a failure to the policy log anyway because of the exit 1 in your script. Ugh.

All this being said, I know I will be going against the norm here, but I've come to believe that the issue of needing to close open apps before updating them is basically a waste of energy and a non-issue. I've updated many applications while running, including Office 2011 using a choices.xml file to suppress the all quit function, and have never had a problem with any of this. The apps don't miss a beat and do not get corrupted. I had once thought that it was a complete necessity to quit Office apps before running any of the updates, but in working with this now for about a year, it really isn't needed. Same is true for all other products - browsers, media apps, FTP apps, plug-ins, etc. - that I've done this with. YMMV of course.

The only actual concern I have is that of course the new application code is not running until the user quits and relaunches the updated application(s). But we can notify the user that an update was just applied to their open applications using several different methods, like Notification Center (Management Action.app or terminal-notifier), jamfHelper, Applescript dialogs, cocoaDialog, etc. This still involves some scripting, checking for the app running before the update is installed and setting an appropriate flag beforehand so the notice is sent up later, but since we're looking at scripting anyway to detect the open apps, I'd rather put my scripting effort into getting the updates applied and then notifying the user to quit/relaunch them if they were open at the time.

The other way to do it is to put this all into Self Service and have a script that checks the open apps list and alerts the user to quit them before clicking OK. If they do quit them, great! If they don't quit them, update them anyway!

markc0
New Contributor III

Thanks Everyone, i now have a better idea on what i need to do
I like the last comment mike made about updating the application and notifying the user to restart the application is what i will be going for