We have done testing and can say for sure, it's was still broken software and not ready for Business in v24. Version 25 was working with workarounds and later they broke Flash, but fixed it first in Version 54 with below solution. Currently it works fine, but may break again at any time in future as they always forget about Enterprise needs.
With version 15 Google seems to have published the very first version of Google Chrome for Business that seems to work in an Enterprise environment with Roaming Profiles and redirected AppData folders. Yes - You have read correctly - they are at version 15 and this is the first version that may work. They claimed in december 2010 with Version 11 that Chrome is Ready for Business. The only thing that was ready - was a very limiting MSI wrapper that is not a full-fledged MSI setup. These version 11 was not ready for Business and the only important functionality was the installation to %ProgramFiles% folder, but this does not make Chrome ready. It's still only a suxxx MSI wrapper around the normal installer and as one example - it does not allow you to customize the shortcuts.
Some Google Developers seems also not aware of the best practice rules for roaming profiles and have not understood some fundamental Windows basics and still do per user installations of Google Chrome into LocalAppData. From my point of view and with more than 15 years experience in Roaming Profiles, many broken applications appeared after Google started to do this bullsh** and some braindead guys may think - what Google does - cannot be wrong. I have no words for them except - GOOGLE DEVELOPERS ARE WRONG!
What is the best practice and minimal policy configuration required to run Google Chrome?
Google has provided some policies for Chrome that need to be enabled with roaming profiles. If you don't enable the user data directory redirection - your users will loose all their Chrome settings data/bookmarks/plugins with every logoff! The Google developers still do not have fixed their application bugs in version 15 and still default the user data directory to the local application data folder (BUG). Please understand that these are only workarounds provided by Google. These are not fixing the design flaws that the user data should reside below AppData\Roaming folder by default.
- Download the latest policy templates for Google Chrome.
- Copy the ADMX templates to
\\[adsrv1]\sysvol\[example.com]\Policies\PolicyDefinitions where [adsrv1] is the name of one of your domain controllers hosting the active directory.
- Create a per User GPO with the following settings
- Set disk cache directory
${local_app_data}\Google\Chrome\User Data\Default
- With this setting we tell Google Chrome to save all temporary files to local disk. The user benefit from faster page loading and caching as long as he do not logoff. If the user logs off all this data gets excluded from roaming and is deleted from disk for cleanup reasons. These data get's intentionally lost on logoff.
- Set user data directory
${roaming_app_data}\Google\Chrome\User Data
- This is the most important policy at all. This keeps all user settings inside AppData\Roaming folder. If you are using redirected AppData\Roaming folders or not, this should be the default for Chrome in all cases.
- The default behaviour is a major design BUG in Google Chrome, but the policy can workaround the bug.
- Only make sure your Chrome is deployed in the same version on every computer. Google says it could destroy the user data if not.
${roaming_app_data} used, but with v24+ you can workaround and set this to U:\AppData\Google\Chrome\User Data where U:\ is the users HomeDrive.
- Create a per Machine GPO with following option to disable pepperflash updates to user home drive:
. This works with Chrome 54+.
- Run Flash Player PPAPI for Chrome enterprise deployment (MSI) to install Adobe Flash global to windows. See Flash Player enterprise deployment and Adobe Flash Player Distribution for more information.
Looking forward to see some bugs closed:
- Issue 2423: Windows Roaming Profile support, opened Sep 17, 2008
- Issue 68519: Change MSI from a wrapper to "full" MSI
- Google AdWords Editor has the same bugs (NOT FIXED)
History
- 27/09/2016: The ability to disable binary component updates is coming in Chrome 54, 624128 Enterprise control to disable (binary) component updates. This should solve the PepperFlash on network drive issues reported in issue 572131.
- 20/07/2015: Issue 572131: PepperFlash updated to user network drive, but DLL not used / NPAPI error with flash content
- 27/02/2013: Issue 174337: Cannot open profile on first startup is fixed in v25.0.1364.97
- 27/02/2013: Issue 174289: Flash applets are not loading is fixed in v25.0.1364.97
- 05/02/2013: v24.0.1312.57 does not longer show chrome.exe: unknown software exception 0x800000003 with "Set user data directory" policy, but Flash is now broken. See Issue 174289: Flash applets are not loading. Sum up - the exception is suppressed, but Flash is not working - as before. Sandbox protections denies addon install as user data directory is on UNC path may not solved, but it does not cause failures if the home drive is referenced with a drive letter e.g. U:\AppData\Google\Chrome\User Data
- 15/08/2012: Software is still broken in v21, see Application error, A breakpoint has been reached, exception 0x800000003 and several other show stopper exists, too.
- 05/07/2012: Renderer process hangs when starting from a network hosted location documents that command line argument
--no-sandbox may be a workaround, but cannot recommended security wise. --single-process crashes chrome for me.
- 29/06/2012: v20 is still broken and shows chrome.exe: unknown software exception 0x800000003 with "Set user data directory" policy.
- 15/05/2012: Issues should be fixed in v20. One remaining issue with concurrent browser sessions is not fixed.
- 04/01/2012: Postponed from v17 to v20 after several milestone changes in past months.
- 11/01/2011: Addons are broken. Cannot installed as user data directory is on UNC path.
- 10/28/2011: Chrome 15 starts up, basic functionality seems working, furter testing required