Posted on 04-20-2015 01:28 PM
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?
Solved! Go to Solution.
Posted on 04-29-2015 12:13 PM
@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 - Thanks
mkdir -p ~/Library/Google/GoogleSoftwareUpdate
chown root ~/Library/Google/GoogleSoftwareUpdate
chmod 644 ~/Library/Google/GoogleSoftwareUpdate
Posted on 04-20-2017 08:36 AM
@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.
Posted on 04-20-2017 08:48 AM
How we can achieve this for every newly logged in user. need a script help.
Thanks
Vijju
Posted on 04-20-2017 09:05 AM
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.
Posted on 07-11-2017 10:51 AM
@AVmcclint pretty sure you found this already but just in case...
https://www.chromium.org/administrators/policy-list-3#EnableCommonNameFallbackForLocalAnchors
Posted on 07-11-2017 10:55 AM
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.
Posted on 07-11-2017 11:02 AM
@AVmcclint yep, the real solution is to red internal PKI certs to include SAN.
Posted on 09-04-2018 10:39 AM
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.
Posted on 09-05-2018 09:30 AM
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
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.
Posted on 09-25-2018 09:55 AM
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!
Posted on 09-25-2018 11:49 AM
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