Google Chrome Auto Update

jebS
New Contributor III

Has anyone actually been able to disable auto updates in a chrome package? - I was Able to create a new mdm configuration profile and upload an edited com.google.Chrome.plist file with a few policy settings. this worked great. I followed the instructions here: https://support.google.com/installer/answer/147176?hl=en&ctx=go

but I am still able to update chrome. as a matter of fact, - I even went as far as changing and even deleting the GoogleSoftwareUpdate folder under user/library/google - and it just builds a new one

I know in windows, it's one reg key and you get "Updates are disabled by the administrator"

can it really be this difficult?

1 ACCEPTED SOLUTION

jebS
New Contributor III

@CasperSally you were right on target!

I actually added a script to create the folders right after the Chrome package is installed. if launched, it can't access these folders and does not update - Thanks2379cb6c15ea4a6e8bfbb43468aa8644

!/bin/sh

mkdir -p ~/Library/Google/GoogleSoftwareUpdate
chown root ~/Library/Google/GoogleSoftwareUpdate
chmod 644 ~/Library/Google/GoogleSoftwareUpdate

View solution in original post

49 REPLIES 49

calumhunter
Valued Contributor

check out this post, has some useful info about it

https://groups.google.com/forum/#!msg/munki-dev/nBkPLR81lDw/w72GFkHxABAJ

pblake
Contributor III

You have to remove the keystone launch agents to avoid auto updating.

Aziz
Valued Contributor

I added:

<key>DeviceAutoUpdateDisabled</key>
                                <true/>

to my configuration profile and updates will fail when the user clicks on 'Update Chrome'. It also stopped Chrome from autoupdating.

My new issue is how can I suppress the yellow bar saying "Google chrome might not be able to keep itself updated" during first launch?

jebS
New Contributor III

Thanks - but that didn't stop the update - Here is what I have:

2e2153059d094fcd81b31284ee70654c

CasperSally
Valued Contributor II

This is what I run at login ongoing. In my testing, in the last year or so Google started putting the GoogleSoftwareUpdate bundle back even if you manually removed it. To get around this, I removed it from current logged in user, then put back a dummy file with permissions that Google can't put its bundle back.

You could get away with once per user probably if you mainly had one user per machine, but we have student machines in carts where many login to the same machine.

Edit: this stops the auto update mechanism, I'm not sure if it stops updates if user goes to settings/about, you'd have to test that. For us, the issue was more about the error from config profile app folder restrictions stopping the SoftwareUpdate.bundle from launching and less about the actual updating happening. I'd probably allow auto updates if they weren't trying to launch out of the User Library folder.

#!/bin/sh

rm -rf /Users/$3/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle
touch /Users/$3/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle
chown root /Users/$3/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle
chmod 644 /Users/$3/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle

CasperSally
Valued Contributor II

@Abdiaziz - in my testing with config profile set to DeviceAutoUpdateDisabled to true, it still tries to run the GoogleSoftwareUpdate.bundle on launch of the app. The chromium site only mentions support for Chromium on this, not OSX, not sure if that's why

if I go to Chrome://policy it doesn't show that setting coming down, though it is listed in the plist in HD/Library/Managed prefs - think it doesn't apply to OSX unfortunately.

jebS
New Contributor III

@CasperSally you were right on target!

I actually added a script to create the folders right after the Chrome package is installed. if launched, it can't access these folders and does not update - Thanks2379cb6c15ea4a6e8bfbb43468aa8644

!/bin/sh

mkdir -p ~/Library/Google/GoogleSoftwareUpdate
chown root ~/Library/Google/GoogleSoftwareUpdate
chmod 644 ~/Library/Google/GoogleSoftwareUpdate

CasperSally
Valued Contributor II

@jebba glad i could help.

GabeShack
Valued Contributor III

My problem is that when using the google apps it will always tell the user that the browser is out of date, so then I get inundated with requests to update chrome because they feel it is needed. If I could disable that message that google puts at the top of the page would be even better!

Gabe Shackney
Princeton Public Schools

Gabe Shackney
Princeton Public Schools

CasperSally
Valued Contributor II

I haven't seen that prompt yet. We do update Chrome every month though, just on our schedule after testing.

luke_j_nelson
New Contributor II

I'm a little late to the game here. I created a script that will be used as a postflight script in the Chrome pkg that I upload to Casper Admin. The script runs the ksinstall -nuke command from all user directories as well as from the app directory in case it got installed in a system directory.

#!/bin/bash

usernames=`/bin/ls /Users`

for user in $usernames
do
    usrloc="/Users/$user/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/ksinstall"

    if [ -f "$usrloc" ]; then
        $usrloc --nuke
        chown root:wheel /Users/$user/Library/Google
        chmod a-rwx /Users/$user/Library/Google
    fi
done

apploc="/Applications/Google Chrome.app/Contents/Versions/43.0.2357.132/Google Chrome Framework.framework/Frameworks/KeystoneRegistration.framework/Resources/ksinstall"

if [ -f "$apploc" ]; then
 $apploc --nuke
fi

exit 0

kcalderw
New Contributor

Is it possible to apply this in Munki or even a postflight script for Deploystudio?

bpavlov
Honored Contributor

@kcalderw it's just a script so why not? A nopayload pkg with just a postinstall script or any other mechanism that Munki may use to execute scripts outside of packages if its allowed. I would be sure to test that script out though. It's hardcoding a folder with a version number which may be out of date by this point. You might need to improve upon the script.

AVmcclint
Honored Contributor

I'm glad this thread popped back up again. I've been using the

defaults write com.google.Keystone.Agent checkInterval 0

command provided by Google to stop the updates and I can unequivocally say it flat out does not work at all. I tried the script from @luke.j.nelson and so far that seems to do the trick.

mconners
Valued Contributor

I have to ask and I hope I'm not the only one blanking out on this one.

I see the phrase, post flight script being used above, related to having a post flight script in the Google package.

I created a script that will be used as a postflight script in the Chrome pkg that I upload to Casper Admin.

Does this mean you have the script added to the package policy and have it set to run AFTER everything else is finished? I have always been a little fuzzy about pre and post flight scripts.

When working with scripts, there are options to run before or after other items have been run. I have assumed that these are post flight and pre flight but now I am questioning my assumption on that.

Can someone help explain this?

Thank you.

Mick

luke_j_nelson
New Contributor II

@bpavlov Yes I made this script for a specific version on the fly. Here's an updated script that should look at the latest version:

#!/bin/sh

usernames=`/bin/ls /Users`

for user in $usernames
do
    usrloc="/Users/$user/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/ksinstall"

    if [ -f "$usrloc" ]; then
        "$usrloc" --nuke
        /usr/sbin/chown root:wheel /Users/$user/Library/Google
        /bin/chmod a-rwx /Users/$user/Library/Google
    fi
done


if [ -e /Applications/Google Chrome.app ]; then
    latestver=`/bin/ls /Applications/Google Chrome.app/Contents/Versions | /usr/bin/sort -n | /usr/bin/tail -1`
    apploc="/Applications/Google Chrome.app/Contents/Versions/$latestver/Google Chrome Framework.framework/Frameworks/KeystoneRegistration.framework/Resources/ksinstall"

    if [ -f "$apploc" ]; then
        "$apploc" --nuke
    fi
fi

exit 0

mm2270
Legendary Contributor III

@mconners Postflight, preflight, postinstall, preinstall scripts, and a couple of others technically refer to an embedded script within a .pkg or .mpkg installer. While some folks might use those terms interchangeably with a script run in a Casper Suite policy in a "Before" or "After" state, those aren't actually pre/postflight scripts, although they can kind of act like ones.

Also to note, a DMG cannot use an embedded postflight or preflight script. Only .pkg and .mpkg formats can have those. And yes, you create them in an application like Composer or Packages and they ride along with the package itself, so its self contained, not reliant on some other mechanism to deploy the script down from a share.

As further explanation, "post" scripts mean they run after the main payload of the package is deployed down, if there is a payload (see payload-free package for more on that) These are often used as "cleanup" kind of scripts, where some changes are made to the items just laid down, or, in some cases, to install something. A simple example of this would be dropping a .mobileconfig file into /tmp/ and then using a postflight script to actually install the Profile to the Mac. Another example would be loading a new LaunchDaemon/Agent that was just installed, so it starts working right away.

A "pre" script is run before the main payload is laid down, so for example, a simple use case would be to rename a directory, or delete an old version of an application, prior to installing the new one contained in the package itself.

Hopefully that helps explain things a bit.

AVmcclint
Honored Contributor

@luke.j.nelson I modified the line:
apploc="/Applications/Google Chrome.app/Contents/Versions/43.0.2357.132/Google Chrome Framework.framework...
to say:

apploc="/Applications/Google Chrome.app/Contents/Versions/*/Google Chrome Framework.framework...

and that works too as long as Google doesn't change their folder structure.

luke_j_nelson
New Contributor II

@AVmcclint That doesn't quite work out, the next part:

if [ -f "$apploc" ]; then
    "$apploc" --nuke
fi

returns false because it is looking for * as a character, not a wildcard, and ksinstall --nuke doesn't run. If you test it with the #!/bin/sh -x header you can see verbose results in the command line, here's how it compares.

with *:

+ '[' -e '/Applications/Google Chrome.app' ']'
+ apploc='/Applications/Google Chrome.app/Contents/Versions/*/Google Chrome Framework.framework/Frameworks/KeystoneRegistration.framework/Resources/ksinstall'
+ '[' -f '/Applications/Google Chrome.app/Contents/Versions/*/Google Chrome Framework.framework/Frameworks/KeystoneRegistration.framework/Resources/ksinstall' ']'
+ exit 0

with version variable:

+ '[' -e '/Applications/Google Chrome.app' ']'
++ /bin/ls '/Applications/Google Chrome.app/Contents/Versions'
++ /usr/bin/sort -n
++ /usr/bin/tail -1
+ latestver=48.0.2564.109
+ apploc='/Applications/Google Chrome.app/Contents/Versions/48.0.2564.109/Google Chrome Framework.framework/Frameworks/KeystoneRegistration.framework/Resources/ksinstall'
+ '[' -f '/Applications/Google Chrome.app/Contents/Versions/48.0.2564.109/Google Chrome Framework.framework/Frameworks/KeystoneRegistration.framework/Resources/ksinstall' ']'
+ '/Applications/Google Chrome.app/Contents/Versions/48.0.2564.109/Google Chrome Framework.framework/Frameworks/KeystoneRegistration.framework/Resources/ksinstall' --nuke
+ exit 0

AVmcclint
Honored Contributor

yeah I just discovered a serious problem with the way I did it. The fans on all the Macs have spun up to full blast constantly and the system.log file is filling up with hundreds of entries every minute like this:

Feb 24 10:18:31 COMPUTERNAME com.apple.xpc.launchd[1] (com.google.keystone.user.agent[59949]): Service setup event to handle failure and will not launch until it fires.
Feb 24 10:18:31 COMPUTERNAME com.apple.xpc.launchd[1] (com.google.keystone.user.agent[59950]): Could not find and/or execute program specified by service: 2: No such file or directory: /Users/tturner/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/GoogleSoftwareUpdateAgent.app/Contents/MacOS/GoogleSoftwareUpdateAgent
Feb 24 10:18:31 COMPUTERNAME com.apple.xpc.launchd[1] (com.google.keystone.user.agent[59950]): Service setup event to handle failure and will not launch until it fires.
Feb 24 10:18:31 COMPUTERNAME com.apple.xpc.launchd[1] (com.google.keystone.user.agent[59951]): Could not find and/or execute program specified by service: 2: No such file or directory: /Users/tturner/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/GoogleSoftwareUpdateAgent.app/Contents/MacOS/GoogleSoftwareUpdateAgent

Every Mac has HUNDREDS of copies of the system.log file filled with this entry over and over again.

OOPS

AVmcclint
Honored Contributor

Something still isn't right. I fixed my script to resemble yours @luke.j.nelson and I ran it on a freshly imaged system where I logged in as a user and launched Chrome to let it create the folders it usually does. Then I ran the script and within a few minutes, the fans spun up to full blast and the CPU was pegged out and the system.log file was filling up every couple minutes with the same errors as above. It looks like setting the ~/Library/Google/ folder permissions to 000 really upsets the keystone agent.

I really wish Google would provide a working method of stopping the autoupdate.

JayDuff
Contributor II
Something still isn't right. I fixed my script to resemble yours @luke.j.nelson and I ran it on a freshly imaged system where I logged in as a user and launched Chrome to let it create the folders it usually does. Then I ran the script and within a few minutes, the fans spun up to full blast and the CPU was pegged out and the system.log file was filling up every couple minutes with the same errors as above. It looks like setting the ~/Library/Google/ folder permissions to 000 really upsets the keystone agent. I really wish Google would provide a working method of stopping the autoupdate.

I just installed the script, as @luke.j.nelson wrote it, and applied to a MacBook Air, running 10.10.5, and had no issues. Works great! Thanks, Luke!

Maybe a fresh copy/paste into your script is in order?

Now, if I can just figure out how to disable Incognito mode....



Edit - our test device's fan hasn't sped up or anything, but the log is definitely filling up with complaints from keystone. I'm going to undo the script, darn it.

gabriel_martine
New Contributor III

After foolishly running the script posted above: !/bin/sh
mkdir -p ~/Library/Google/GoogleSoftwareUpdate
chown root ~/Library/Google/GoogleSoftwareUpdate
chmod 644 ~/Library/Google/GoogleSoftwareUpdat

I am having the fan issues on all my machines. Console is reading out the error Feb 24 10:18:31 COMPUTERNAME com.apple.xpc.launchd[1] (com.google.keystone.user.agent[59949]): Service setup event to handle failure and will not launch until it fires.
com.apple.xpc.launchd[1] (com.google.keystone.user.agent[59950]): Could not find and/or execute program specified by service: 2: No such file or directory:

I am still relatively new to this game. Could anyone please please help me out. What do I need to do to get this script undone?

AVmcclint
Honored Contributor

@gabriel_martinez I did the same thing. I ended up doing this to fix it

#!/bin/sh

rm -rf /Users/$3/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle
mkdir -p /Users/$3/Library/Google/GoogleSoftwareUpdate/
touch /Users/$3/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle
chown root /Users/$3/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle
chmod 644 /Users/$3/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle

Then after all the dust settled and the fans spun down, I went into /var/log/ on each computer and saw HUNDREDS of system.log.* files. I deleted all but the most recent. I still don't know if this is really stopping the autoupdate, but we shall see.

donmontalvo
Esteemed Contributor III

Just sayin'...

--
https://donmontalvo.com

AVmcclint
Honored Contributor

@donmontalvo The problem is that many users aren't admins and can't make changes to /Applications. When chrome repeatedly keeps trying to update and throws a few dozen "Google Chrome" mounted disk images on the desktop, it's guaranteed to generate a helpdesk call. Giving regular users admin rights to change anything in /Applications is a bigger risk than not updating Flash.

donmontalvo
Esteemed Contributor III

AVmcclint
Honored Contributor

I can definitively say that isn't true. I've even tried it on my unmanaged Mac at home using a fresh install of an old version of Chrome that I had saved on a USB stick and a non-admin user just created for the purpose of testing this. I launched that old version of Chrome and let it sit. After a few hours it mounted the Google Chrome disk image but it sure as heck does not update /Applications/Google Chrome.app I let it sit for a week and a half without touching it and not only did it never update, I found another 6 or 7 instances of the Google Chrome disk mounted on the desktop.

bpavlov
Honored Contributor

@donmontalvo Yea that's definitely not true. And if that's what others are experiencing I'd like to hear more. I wish it were actually the case, but definitely not so. Anyways, I find it's much quicker to just deploy the latest version through Casper anyways.

Chris_Hafner
Valued Contributor II

Works on our campus, mostly. Actually, our helpdesk's method for fixing those users who's chrome doesn't autoupdate is by replacing the .app with a fresh version. Honestly it was simple enough that I haven't really dug into why. The one thing I will say is that I DO NOT modify or distribute any files or settings into chrome preferences or library locations so that we don't nuke any user settings/bookmarks etc.

FYI, we're an edu campus where students are NOT admins and in general, the ones using chrome regularly are being updated (I'm counting at least ~50 of them, small potatoes I know but 50-ish none-the-less). I'm sure there's a give and take and I'm sure there's also a reason why. Let's just be careful with how 'definitive' we're calling things. We are all microcosms after all.

P.S> Safari and Firefox are our recommended browsers and so less attention is paid to Chrome at the moment.

AVmcclint
Honored Contributor
Let's just be careful with how 'definitive' we're calling things. We are all microcosms after all.

Fair enough. I can definitively say that in the home environment and my work environments in which I exist, it is not true. :)

Chris_Hafner
Valued Contributor II

@AVmcclint Nice!

Chris_Hafner
Valued Contributor II

I'm slowly moving around to test this further... because. I'm noticing that my simple versions of Chrome installed during imaging are not updating (error 12). However, one installed or updated via Self-Service will update on it's own moving forward. This is a small sample test and I've not yet dug into it but I figured that I'd throw this up.

Jeff-JAMF
New Contributor

Note that Ben Toms posted info on his MacMule blog regrading changes in the minimum OS requirements for Google Chrome v50

GOOGLE CHROME 50 OS REQUIREMENT CHANGES

Chrome now requires Mac OS X 10.9.x,10.10.x, 10.11.x

jhom
New Contributor

@AVmcclint I'm trying to use the same method as you.

What execution policy did you use? I have a phobia of ongoing... but it seems like the ideal frequency.

Thanks

jhuls
Contributor III

Digging this up as I see some saying they're going to try things but I don't see any results. How are people blocking Chrome updates now?

Eastman
New Contributor

I seem to be missing something on this topic. I have copied the script above and ran it as a policy on a test computer... the policy shows that it goes through and completes, however the chrome never updates :) To clarify, I'm extremely new to this and I'm not even green when it comes to writing scripts. If I can't copy it from you guys, I don't use it!

Thanks

Jeff-JAMF
New Contributor

Patrick,

Check out this discussion on the topic Disabling Chrome auto-update under OSX?

mconners
Valued Contributor

Hi Folks,

As I prepare for updates for our summer deployments, Chrome is on my list of things to lock down, if possible.

I too would like to know more about what people are doing to actually lock down the update process. Any luck out there? Please share your story.

Thank you