Best Practices for Deploying Application Updates to users (without using Self-Service)

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):

• I don't avoid it, I update while they are open
• Cache for larger packages (above 200mb), otherwise direct from DP
• A cocoaDialog window in the upper right by Notification Center asking them to relaunch the app
• I use recurring check-in primarily, but I sometimes use login if it is a quick patch

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.

Or should we wait for the mythical JSS patch management solution? :)

Yeah, I am gonna go head and hold my breath.

I understand JAMF wants to get this right, but I also see Munki and Patchoo already doing it.

@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.