Chrome Enterprise w/ Auto-Update Enabled

Not planned

Comments

9 comments

  • Official comment
    Katie Sorenson

    Aside from the fact that we disable auto updates wherever possible, there's actually a good reason for disabling Chrome's auto updates. It's less that we want to manage your updates and more that Chrome behaves weirdly when it's allowed to manage its own updates.

    The package installs Chrome Enterprise, which labels the versions in a different way from the non-enterprise version. When left to its own devices, Chrome will auto update itself and you can see inconsistent results with the version numbers. In addition, the updated version of Chrome will sometimes swap to the per-user version, installed in the current logged on users' AppData folder, instead of the per-machine version, installed in Program Files or Program Files (x86).

    https://support.pdq.com/hc/en-us/articles/220509607-Deploying-Google-Chrome-Enterprise

    It doesn't always cause problems for everyone, but we see it frequently enough to recommend against disabling the auto update. 

    Comment actions Permalink
  • Stephen Valdinger

    Why don't you use a Post-Deployment Step on the auto-deployment package to enable the auto-update bit? That way you can leverage autodeployments. Just my 2 cents :)

    0
    Comment actions Permalink
  • John J. DAquino

    I saw the option in the Auto-Deployments to add Pre and Post Steps. Do those carry over between versions? As I'm asking this I realize they must since only the package is updated and not the entire Auto Deployment is re-created. I certainly try that.

    0
    Comment actions Permalink
  • Stephen Valdinger

    Yes the Pre/Post steps do carry over. Give it a shot, I think that is exactly what you'll need and saves them having a rather duplicitous package in the library.

    0
    Comment actions Permalink
  • John J. DAquino

    Thanks Stephen, appreciate it. I'll give it a shot.

    0
    Comment actions Permalink
  • John J. DAquino

    Thanks Katie. My initial request stemmed from my supervisor seeing "updates have been disabled by your administrator" and wanted me to allow updates... I pleaded my case that everything is up to date because of how my Auto-Deployments are configured. I'll pass on your information and see if I can change his mind. I'm with you 100%.

    0
    Comment actions Permalink
  • Scott S

    Last spring we had an issue with Chrome taking 30-60 minutes to open on a fresh launch for most of our users. After months of investigation, including tickets with both Google and PDQ support, I determined it was PDQ's package disabling auto-updates that caused some sort of conflict with other Google apps relying on Google Updater. I believe our experience to be relatively unique, as factors not described here likely contributed to our experience, but I wanted others to be aware of potential conflicts.

    We are a Google Apps shop and rely heavily on both Chrome and the Google tool for syncing email to Outlook, GSSMO (Google Apps/G Suite Sync for MS Outlook). The Chrome Ent package's auto-update steps disable Google Updater system-wide, which means other Google apps, like GSSMO, also do not update. I have custom packages for GSSMO and the Outlook pst migration tool, which i periodically update and deploy. I believe they write to the same subkeys. I can't explain, or don't remember, exactly why this was a problem, but the result was almost as if Chrome would open and spend 30-60 minutes running in the background and timing out trying to check Google servers for an update, before failing and finally loading Chrome. To the end user it meant they would power on their PC in the morning, launch Chrome, then use IE for an hour until Chrome finally appeared.

    Re-installing Chrome would fix the issue until the next reboot (ie until Chrome checked for another update upon the next fresh launch), which meant nobody shut down/rebooted their PCs. After extensive testing fixing this issue required exactly the following:

    1. Uninstall Chrome (sometimes it was borked so hard it couldn't be uninstalled via Add/Remove Programs)
    2. Purge each user's Chrome's profile (%localappdata%\Google\Chrome)
    3. Delete registry keys for Chrome and Google Update
      • HKEY_LOCAL_MACHINE\SOFTWARE\Google\Chrome
      • HKEY_LOCAL_MACHINE\SOFTWARE\Google\Update
      • HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Google\Chrome
      • HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Google\Update
    4. Reinstall GSSMO (uninstall not required)
    5. Reinstall Chrome Ent via PDQ (package modified to disable the steps that disable auto-update)

    Fortunately every user is signed into Chrome so their profiles cloud sync. Even more fortunately, though, is reinstalling GSSMO does not require a new Outlook profile be created. The process was relatively quick and painless after creating an Inventory registry scan profile to identify impacted clients. I could have created a Deploy package to speed up the actual fix but I ended up doing it manually since i found some troubling variances between clients and wanted the visibility.

    My team and I made great strides this year (and got great reviews!) but between this and MS's June update that borked Outlook's search/indexing for the entire company we really took a hit to our reputation. End users don't care why something broke, only that we're responsible for it. Never mind that we were almost entirely immune to petya/notpetya weeks before the outbreak- no one cares about that- except the people signing our paychecks, of course ;)

     

    Suffice to say, I would love a second Ent package with the update steps disabled so I can make Chrome an auto-deployment.

    0
    Comment actions Permalink
  • John J. DAquino

    You should be able to create an auto deployment with the package you have already added the post steps to. I have an auto download of Chrome and just added a post step to re-enable the auto update feature. Then I attach that to my "maintenance" schedule and it's a walk in the park from there. If you require different settings on an alternate download, you can download another auto download of Chrome and configure it's post steps differently if need be.

     

    0
    Comment actions Permalink
  • Scott S

    I had thought about that, and it would probably work, but with the months-long migraine this issue caused us I dread touching anything!

    0
    Comment actions Permalink

Please sign in to leave a comment.