Patch Management for Microsoft Office 2016

Office and Google Chrome sort of 'hijack' the user session until (in the case of Word or Powerpoint, for instance) the user makes a save/don't save decision. I wouldn't automate your user kickoff after 15-minutes unless you're really sure -- users who have abandoned their macs without making a save decision might lose work. In computer labs we can be a little more aggressive with 'kickoff' if it has been many hours since any activity has occurred, but with 1-to-1 user kickoff is riskier for sure.

Auto-Recover settings can mitigate some of that, but across many workstations, you'll see that quite a few users walk away from unsaved work.

Chrome also locks the session, just because that's how it's built --even if there's not a save decision to be made-- it still locks the session.

These are just my experiences of course, others may have another approach to it.

Have a look at MAU4 it is in beta at the moment but it is fantastic to update from the command line http://macadmins.software/mau4

I've been experimenting with the following script because of this issue:

#!/bin/bash

ps -ef|grep "$4"|grep -v grep|grep -v JAMF

if [ $? -eq 0 ]
then
  echo "$4 is running, better luck next time!"
  exit 0
else
  echo "$4 doesn't seem to be running! Lets run your custom trigger $5"
  jamf policy -event $5
fi

it takes in two arguments $4 and $5, $4 will be the app name, for example: Google Chrome.app
$5 will be the custom trigger that kicks of the update

If Chrome is running, it will not start the update and try again later. This script is in a policy that runs every check-in, scoping based on the patch management data. In theory this could work for any application. Keep in mind that if you do this for a big app like Microsoft Word, or even the entire office suite, it'll take time to download the installers to your machine. It's better to combine this with the JAMF caching mechanism and cache the packages on eligible machines beforehand.

I haven't been able to play with patch policies yet because of other patch related issues I'm having, but I've been using autopkgr for years and it checks if app is in use and won't update if it is. It keeps checking to see if app is in use on the every30 trigger & skips the update if app is in use. I also nag users who haven't restarted in 14 days because restarts are a good time for pending patches to restart before apps are opened.

I think our ideal jamf patching scenario would

• attempt to patch silently in background attempting to update if app is closed without interrupting user at all for say 3 days.

• if user never closes their apps so updates can't install and they still have patches pending, then nag them to close apps and install patches via self service or restart in order to install pending patches. Give user option to ignore restart nag for up to 3 times or delay the restart X hours, then force the restart, and have patch policies set to install at startup.

Is there a jamf feature request for a workflow like that? If not, I'm not sure we'll ever be able to really move to jamf patching policies.

Force quitting apps seems like a bad way to handle things, especially if it's not doing it gracefully.

@tjk wrote:

Have a look at MAU4 it is in beta at the moment but it is fantastic to update from the command line http://macadmins.software/mau4

+1

Thanks for the feedback and discussion everyone. I wanted to point you to a couple of open feature requests related to this. When you have a moment, please upvote so that Jamf has a better sense of what to prioritize going forward:

https://www.jamf.com/jamf-nation/feature-requests/6767/patch-management-grace-period-enhancements

https://www.jamf.com/jamf-nation/feature-requests/5378/include-maintenance-windows-in-patch-management

-Brandon

Thanks @frankxro for posting about this.

I created a new feature request because with this issue (non gracefully closing office apps), I don't see us being able to use patch policies. For us, short of adopting MAU4, restart is the best opportunity to update Office apps because they are unlikely opened yet.

My feature request is requesting better user interaction options for patch and other policies like Munki has had for many years now. I'd like to be able to prompt users with patches pending who haven't restarted to please restart with an option to defer that nag up to X hours or Y times before restart is forced. If patch policies run at startup (not sure they are), but it's a great opportunity to get patches installed before user opens apps.

Please consider voting up if something like this might help your workflow
https://www.jamf.com/jamf-nation/feature-requests/7190/better-options-for-user-interaction-and-deferral-for-patch-and-all-policies

Also give customers option for jamf patch policies to install at startup (when most likely office apps are still closed)
https://www.jamf.com/jamf-nation/feature-requests/7191/give-customers-option-for-jamf-patch-policies-to-also-install-at-startup