Not planned
Chrome Enterprise w/ Auto-Update Enabled
I realize I'm able to change the setting manually to enable Auto-Updates from Chrome. I also completely understand why you have it disabled by default (Updates should be managed from PDQ).
With that said, the reason I'm looking to have this as a separate package is for Auto-Deployments. As of now, I can't immediately approve the Chrome Enterprise updates since I have to go in and Disable the step to disable auto-updates. Is there a way you can duplicate your Chrome Enterprise package in the Package library an have Auto-Updates enabled by default. I would love to create an auto-deployment from that.
Thank you
1
Comments
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.
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 :)
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.
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.
Thanks Stephen, appreciate it. I'll give it a shot.
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%.
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:
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.
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.
I had thought about that, and it would probably work, but with the months-long migraine this issue caused us I dread touching anything!