@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.
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.
@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.
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.
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. :)
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.
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
@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
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?
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
Patrick,
Check out this discussion on the topic
Disabling Chrome auto-update under OSX?
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
@AVmcclint 's solution just worked for me:
#!/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
Had been having an issue where every time Chrome was opened got a popup window saying "macOS wants to update," when admin credentials entered in it just flashed Chrome or filled the desktop with Chrome images. After doing above it doesn't happen and if I go to About Chrome the autoupdate immediately fails.
How we can achieve this for every newly logged in user. need a script help.
Thanks
Vijju
Disabling the auto update is almost imperative. Today I manually updated to Chrome 58 on my Mac and then discovered that I couldn't establish a secure connection to many of our internal servers. These servers aren't using self-signed certs, but they are issued from our internal CA. It also affects Chrome 58 on Windows machines too. This page kinda explains the problem but I dont know where the solution lies.
Meanwhile I made sure to not push the Chrome 58 update to the Macs until this is resolved. If I had autoupdate enabled, things could get really nasty.
oh yeah. The workaround that was offered up back then really was a temporary band-aid because Google said that it would only work through version 65 (I think) after that, all certs would need to be properly built. We had to scramble to get all our server certs updated.
@AVmcclint yep, the real solution is to red internal PKI certs to include SAN.
I had trouble with Google Backup and Sync overriding even with above script in place, so I modified it to not allow write permissions on the whole software update folder. So far so good. I also disabled the launchagent runatload.
#!/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 -R root /Users/$3/Library/Google/GoogleSoftwareUpdate
chmod -R 644 /Users/$3/Library/Google/GoogleSoftwareUpdate
Edit: I removed the LaunchAgent part of the script since it was causing issues in our environment.
I use the Jamf Pro Restricted software option to nuke Chrome from updating and it seems to work across the board till Google renames a process. So under Restricted Software create like this;
Display Name: Google Software Update Agent
Process Name: GoogleSoftwareUpdateAgent.app
Restrict exact process name: checked
Delete Application: Not checked
Send email notification on violation: Not checked
Kill process: checked
Scope: All managed clients
End users will get an error when they try to update, they can still manually download a Chrome installer but never update it as long as they are managed by the JSS.
All, looks like as of Chrome 62, keystone.plist can be managed via a profile (this had been deprecated, I think, but is now back it appears). I'm working on testing this now. Great news if it works, I'd love to get away from these scripts to stop the tool from running!
Relevant post
Google reference
Edit: in my testing, the profile stops the ksadmin prompts but not the GoogleSoftwareUpdate prompts :(
Please let me know if anyone has a different experience? Thanks!
Edit: I posted this in the wrong thread. These prompts apply if you restrict where apps can launch from. We don't allow apps to launch out of /Users and hence the prompts. It's possible the profile works fine if you're wiling to let GoogleSoftwareUpdateAgent bundle launch.
More info (star if you'd like to see Chrome stop launching app out of /Users): https://bugs.chromium.org/p/chromium/issues/detail?id=889150
