Google Chrome Browser Adds Enterprise Features: Review

Google Chrome looks ever more ready for IT-sanctioned use on enterprise Windows PCs, as Google delivered new enterprise-ready installation packages and configuration options allowing administrators to centrally manage availability, freshness and operational behaviour of the browser.

Last month, Google simultaneously released a pair of enhancements to Google Chrome that should make the up-and-coming browser more palatable for use in the enterprise, delivering a new Windows installer package compatible with standard enterprise software deployment tools, along with a set of new policy templates that provide centralised management over some aspects of the browser’s capabilities and security.

New MSI package

As is the case with Chrome when installed as part of the Google Pack, the new MSI package (GoogleChromeStandaloneEnterprise.msi, downloadable from http://www.google.com/chrome/eula.html?msi=true) installs the browser within the Windows Program Files directory, making the browser accessible to all local or domain-based user accounts on the computer. Contrast this to Chrome’s typical web-based installation process, which installs an instance of the browser within the interactive user’s personal Windows profile in Windows XP, Windows Vista or Windows 7.

I deployed the MSI package to both Windows XP Professional SP3-based and Windows 7 Professional-based client virtual machines – each configured as domain clients in a Windows Server 2008 R2-based Active Directory domain. Using AD (Active Directory) Group Policy, I deployed the software to all members of an AD OU (Organisational Unit), and after manually forcing a refresh of Group Policies on each client, the software installed successfully on each machine at next reboot.

After installation, I found that Chrome recognised every iteration of the browser installed within user profiles. The next time each user with Chrome already installed tried to access their instance, Chrome popped a notification that the new systemwide version would replace the user-level instance. The user’s bookmarks and saved passwords are migrated to the new version in the process, but I found extensions are not automatically moved at the same time, requiring the user to reinstall them manually instead.

Because the systemwide version is installed into a part of the client operating system where Standard (limited) rights Windows users cannot make modifications, Google documents that the MSI package includes a systemwide iteration of Google Updater that will automatically upgrade the browser when new revisions are released, no matter the effective Windows permission level of the user. I was unable to verify this capability, however, as Google released no new versions during my test.

Aside from the installer, Google at the same time released Group Policy Administrative Templates for Windows. This feature allows IT workers to centrally control some aspects of the functionality and security of Google Chrome instances deployed throughout the domain.

Group policy templates

The initial templates shipped by Google include 36 policy items. Among the available policies, I found I could control proxy server use and settings, preset default tabs and homepages, change the search provider, blacklist some or all browser extensions and control password saving behaviour.

The complete list of policies can be found here http://www.google.com/support/a/bin/answer.py?hlrm=en&answer=187206.

From Windows’ GPMC (Group Policy Management Console), I configured and applied a Chrome policy that blacklisted a few extensions, kept Chrome from displaying the user’s history, and enabled the website password manager while denying the user the ability to see saved passwords in clear text. I also set a couple of default-tab homepages, and changed the search provider to Bing.

Once linked to an AD object, I found the policies worked exactly as described although two of the policies required a bit of tinkering. Specifically, I needed to adjust the search string set in Group Policy to match the format expected by Bing. Meanwhile, to blacklist specific extensions, I found I needed to locate each extension ID. Unfortunately, the only way I found I could discover that ID number was to install the extension within an existing version of Chrome, then look up the value by typing chrome://extensions in the search bar. Administrators can easily issue a blanket extension blacklist without this step, however.

Google delivers the Administrative Templates in both ADM and ADMX flavors, so administrators will be able to configure Chrome behaviour on both legacy Windows XP systems and newer systems running Windows 7 or Windows Vista. The policies contained within each template format are the same, but as is customary with Group Policy, administrators would implement and deploy each in a slightly different manner. While ADM templates are appended to each individual Group Policy Object that will use Google’s policy controls from the GPMC, administrators can publish ADMX templates (and their associated language files) directly to a central store within the AD SYSVOL (System Volume) using Windows Explorer.

Configuration

Administrators can choose to use the ADM-based templates to manage Vista- or 7-based machines, but will lose any benefits conferred by the newer format – like international localisation of language files and reduced SYSVOL bloat caused by excessive policy and object replication in a large domain.

The Group Policy templates also do not need to be used exclusively with the MSI version of Chrome, as I found in my tests that most applied policies also take effect on user-specific iterations, as well.

Administrators should note that all these policies are AD Computer Policies, so any defined policies applied to a given workstation will be in effect for all users of that computer regardless of the user’s rights or privileges.