Hi ​@aRByCM ,

I use a Bash script to close an app, which I run with the 'Login' trigger — when a user logs in to a computer. The script closes Google Chrome and then reopens it. When the user logs in, they won’t notice that Chrome was closed, as it will open again as usual.

​@agungsujiwo that is a great strategy, thank you for this idea. I will try this.

I suggest you also look at a configuration profile to deploy the auto-update settings.  It’s going to attempt to handle it more gracefully than the script method (but I also leave the script method as a fallback). Their documentation is here - https://support.google.com/chrome/a/answer/7591084?hl=en.  The other thing I do with my script that performs the force updating of chrome is limit the policy’s execution window to avoid 9a-4p m-f.  In theory that’s outside “meeting hours” for us.  You can also do the same with the chrome keystone plist.

Just give them a week for the deadline.  If they can’t find time within a week to quit the app for it to install, that’s on them.

You can click on End User experience within the Chrome Mac App you have set to patch and change the update deadline to a number that works for you. This will give users a notification and a count down that Chrome needs to update in X hours before it will be auto updated. 

I use an extension attribute that detects if the app is currently running, then exclude the smart group that sorts to.

#!/bin/bash

PROCESS="Google Chrome"
number=$(ps aux | grep -v grep | grep -ci "$PROCESS")

echo "The Process "$PROCESS" is "$number"."

if [[ $number -ne 0 ]]; then
#       echo "Running"
       echo "<result>Running</result>"
else 

#       echo "Not Running"
        echo "<result>Not Running</result>"
        
fi

This feels like a bad approach since it is, by design, running at a massive delay.  If the user’s inventory updates, the next possible time for the Chrome update to go out would be on next check in.  By default that’s 20 minutes, and it’s very possible the user would open Chrome in that chunk of time. 

Probably better off running this as a script in a policy and, if <app name here> not open, calling the policy with the <app name here> installer in it directly.  That would require two policies per app, or one if you just use Installomator for the script.  Still, it’d avoid the weird delay introduced by relying on EAs for process checking.

This feels like a bad approach

You’re absolutely correct, and I’m aware that there’s a potential for error due to the lag time. Fortunately, my Users aren’t so precious.

I posted it in the hopes that someone could modify the use and potentially get the results they desire, much like you suggested.

This is what the notifications are for. Unfortunately you can't make users read. Just make sure that you have notifications enabled in the App Catalog or Policy (whichever you are using) and have a configuration profile deployed fording those notifications to be visible.

From here allow an appropriate deferral window, and if they are not reading the notification that is on them. You can manage your way around user behavior.