We're using that installer, and Group Policy. We're redirecting the user's "User Data" folder into their roaming "Application Data". We're finding that Chrome is storing 10MB of DLL files there (gcswf32.dll being the big offender). We're also seeing the same behavior as described in this posting: http://productforums.google.com/forum/#!topic/chrome/xvd0gSJ...
Chrome installs a gcswf32.dll file into "Program Files" but it appears to be downloading a new one for each user, stashing it in their user data folder, then failing to load it properly on subsequent sessions because it's stored on a network path.
The DLL you're asking about is a component update. In this case, we used it to push an emergency Flash security update. These are stored in the user's profile because the component updater is built on top of the extensions subsystem. However, I expect the enterprise team can investigate segregating some of this from UserDataDir.
The thread you referenced should actually be resolved in Chrome 21. That said, it refers to a scenario where parts of the profile are remapped to a network share. It's important to understand that this is not a supported configuration for Windows profiles in general, and is known to break applications other than Chrome. Whereas standard roaming profiles should work fine in all applications, and are the configuration supported by Windows.
I've been down this road with other application development firms before. "Application Data" folder redirection is necessary for us because the roaming user profile grows an inordinate number of files in the AppData folder, which in turn causes logons to be _exceedingly_ slow when users logon to a computer that doesn't have a cached copy of their profile (such as computer labs where machines are frequently re-imaged, which is our pain point).
I don't know where you're getting the phrase "... this is not a supported configuration for Windows profiles in general". Unsupported by whom? Microsoft has been shipping Application Data Folder Redirection as feature of Windows Group Policy since Windows 2000. ) and not some kind of "registry hack" or unsupported (by Microsoft) tweak. I've yet to find any Microsoft developer documentation advising that this feature is "unsupported". I _have_ seen multiple applications broken by using this feature (including Microsoft applications) but I don't think that makes the feature "unsupported" by Microsoft. It seems like this feature is "unsupported" by applications because they make assumptions about how Windows behaves and don't engage systems administrators in their development process.
In the case of Chrome I _really_ want to use it in enterprise situations-- it's my favorite browser, personally. The attitude of installing into folders writable by individual users seems to pervade even the enterprise distribution of Chrome, however. I would argue that, in an enterprise environment, updates should only be applied to the computer's copy of Chrome and not into individual user folders. This creates pain and frustration for sysadmins. It sounds, to me, like the "component updater" doesn't take into account installs where there is a computer-wide copy of Chrome and needs some re-architecting.
Alternatively, we would be able to completely circumvent this problem and just leave the user's Chrome "User Data" folder in their local profile if we could use "Chrome Sync" with our SAML SSO that we use for Google Apps for Education. I haven't looked at it for 6 months, but the last time we looked Chrome Sync did not support authenticating via our SSO, so we had to scrap that idea and go with using a redirected user data folder to allow users to have their Chrome data "follow" them between computers.
Chrome installs a gcswf32.dll file into "Program Files" but it appears to be downloading a new one for each user, stashing it in their user data folder, then failing to load it properly on subsequent sessions because it's stored on a network path.