Does anyone have thoughts on "best practices" for deploying updates to (primarily third-party) applications (e.g. TextWrangler, Office, VLC, whatever) in an environment where the use of Self-Service is not encouraged?
- How do you avoid updating apps at the time that they are in use by the end user?
- Do you cache then install, or just install directly from the DP?
- Do you present any kind of UI, or just install silently in the background?
- What do you recommend to use for a trigger to install the updates? Startup, login, logout, etc?
I'm aware of Patchoo, of course... is that what people would recommend for this particular scenario?
Would AutoPkg/AutoPkgr be appropriate to leverage here?
Or should we wait for the mythical JSS patch management solution? :)
We install silently and directly from the DP via HTTP. I have a script that checks if the process is running in the background and if it's not then it will call the policy custom trigger to install the app. This does mean having at least 2 policies for each app.
AutoPkg may be something to look into.
@georgecm12 it mostly depends on the app and how it handles being patched. For the most part I patch in the background whether the app is open or not, and then pop a message up using cocoaDialog letting the user know the app was patched and that they should restart the app. The only app that I've really seen have an issue with it is Chrome. For some reason if you update Chrome in that manner it looses the connection to the internet and people get "page not found" errors.
WIth larger packages, like Adobe apps, I cache first and then install. Of course, I do not patch our Adobe apps this way, I use RUM to do that and I tend to do that at logout.
To answer your bullet points (which I have already done to a degree):
And I leverage the heck out of AutoPKGr. It's saved me a lot of time packaging up apps. I even use the Customized workflow for Firefox so that I can add a CCK config in to disable update notifications.
@georgecm12 In the case of desktops, we have the users log out and patch in an evening maintenance window.
In the case of laptops, we use the "script to check if process is running, then install" method. Notifications to the users is important in this case so they know whats going on, or coming up.
In the majority of cases we see users handling basic app updates themselves (as most are admins), so we are normally just worrying about OS and security patching.
I'll jump on the "It depends" bandwagon. Office tends to be the trickier one, but we run a script to check against it being open then it gets pushed. Generally, I don't have to as we actively encourage the use of Self-Service. I won't bother asking why you folks discourage it's use but hey, to each their own.
P.S> @quedayone I'm going to continue holding my breath, crossing my fingers, toes and every velcro strap I can find.
Another "it depends" here as well.
For smaller apps I prefer to do a stealth install without them even knowing. I call it Ninja style, we go in, drop the app, and leave. I try not to bother the user unless really necessary.
For bigger things like Office or somethingt that requires a reboot, we plan ahead. We'll let the users know an update is coming via email (which, lets face it, most people ignore). Then depending on the size of the application we might cache it on the machine first. I usually like to offer the application in Self Service as well, but thats optional. Then after a certain amount of time we push it the user. I use User Interaction section of the policy to let the users know whats going on. If a reboot is needed, I usually them to reboot after the install is done.
If you really wanted to get creative you could write a script that basically checks to see if app is open and if it is, sleep for X minutes, rinse and repeat until app is closed and then run update. But with laptop users you runt he risk of them being offline.