HKEY_LOCAL_MACHINE\SOFTWARE\Google\Update.HKEY_LOCAL_MACHINE\SOFTWARE\Google\Chrome.Delete registry keys for Chrome and Google Update.Purge each user's Chrome's profile (%localappdata%\Google\Chrome).Uninstall Chrome (sometimes it was borked so hard it couldn't be uninstalled via Add/Remove Programs).After extensive testing fixing this issue required exactly the following: 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. 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.
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. I believe they write to the same subkeys. I have custom packages for GSSMO and the Outlook pst migration tool, which i periodically update and deploy. The Chrome Ent package's auto-update steps disable Google Updater system-wide, which means other Google apps, like GSSMO, also do not update. 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). 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. 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. Last spring we had an issue with Chrome taking 30-60 minutes to open on a fresh launch for most of our users.
0 kommentar(er)
