Recently I was asked to investigate how to manage Google Chrome for Work in a corporate environment. The customer involved is using Google Cloud Services intensively. This means that in order to receive an optimal user experience, the Google Chrome browser is needed. I decided to investigate and come up with some thoughts and ideas on how to do it.
Managing applications consists of two activities:
In an ideal scenario, those activities are completely separated. The result will be that the installation of the application can be done using the default settings while the configuration will be taken care of elsewhere. Fortunately, Google provides a few methods of configuring Google Chrome. The most well-known are:
- Editing the master_preferences file
- Using Group Policy
For the sake of this blog, the corporate environment consists of Windows 8.1 devices which are domain joined. This means we can consider using Group Policy. Using Group Policy will meet the initial goal of keeping deployment and configuration separate. I was able to use the following reference to see how to use Group Policy to manage Google Chrome: https://support.google.com/chrome/a/answer/187202
As we can see, the policies are machine driven. This provides another challenge how Google Chrome for Work needs to be installed. Google has the following deployment guide to get started: https://docs.google.com/document/d/1iu6I0MhyrvyS5h5re5ai8RSVO2sYx2gWI4Zk4Tp6fgc/preview?pli=1&sle=true
In this guide, I found the following passage critical for my investigation:
Chrome installations from an MSI package are installed at the system level and are available to all users. As a result, any user-level installation of Chrome, (i.e. a user’s own Chrome installation), will be overridden.
It looks like Google has revised the approach of installing Google Chrome quite dramatically since it was possible to install Chrome in the user context. This allowed end users to install Google Chrome without administrator privileges which can be considered a security officer’s true nightmare, not to mention the configuration management and release management processes in a corporate environment.
In order to investigate how to do it, I’ve set up a lab environment with the following machines:
- 1 Windows Server 2012 R2 domain controller
- 1 System Center 2012 R2 Configuration Manager site server
- 1 Windows 8.1 x64 client
Knowing that Google Chrome will always be installed in the system context means we can make it part of an Operating System Deployment Task Sequence. But first an application needs to be made.
To create the application just import googlechromestandaloneenterprise.msi and create a standard Deployment Type, nothing fancy.
Really nothing fancy…
Adding this to a Task Sequence is nothing fancy either…
There you go. I created an MDT 2013 Task Sequence with an unattended Windows 8.1 x64 deployment since it’s not relevant to build a Windows 8.1 x64 image first.
Configuring Google Chrome is a bit more challenging. It really depends on requirements and processes to determine how Google Chrome for Work should be configured. This is what I did first:
- Create a separate GPO for Google Chrome and link it to a OU where my client machine resides
- Import the chrome.adm template
I’ve decided to configure just a few settings the GPO provides:
- Setting Google Chrome as the default browser
- Configure the start page
Configuring the Start Page requires 2 GPO settings
What about Extensions?
Admittingly, I find it great to manage Extensions by GPO. It does require some detective work before they can be automatically added to Google Chrome. Fortunately, nothing has to be downloaded in advance once you know the Extension ID. In my example I added a list of so called force-installed Extensions.
And here’s the list itself
Once the configuration is in place and the machine is deployed, the result will look this
Starting Google Chrome with my Start Pages
And the Extensions specified are also in place.
Finally, Google frequently updates Chrome. You can manage the update behavior by configuring Google Update by Group Policy, the following website can be used as a reference: https://support.google.com/chrome/a/answer/3204698
This requires to import the GoogleUpdate.adm template to configure the update behavior.
In this investigation, I configured the following update settings:
- Automatically check for updates every 60 minutes
- Enable auto updating of Google Chrome
Here are the GPO’s needed to configure it.
Updating Google Chrome for Work works great, if you’re an administrator. Unfortunately, when a user accessed the ‘About’ tab in Chrome it will trigger an update check. For a standard user this will immediately trigger User Account Control asking for credentials for elevation in Windows Vista or newer. Because Google Chrome is installed in the system context (installed in the %PROGRAMFILES% directory), administrator rights are required to make changes to the computer initiated by a user. This behavior is by design.
Especially in Windows 8.1, it is absolutely not recommended to turn off UAC since it will break a lot of functionality of Windows itself. Giving users administrator privileges should not be recommended either. To maintain a strict configuration management and release management process, it’s recommended to disable updates to prevent users who do have administrator privileges install updates by themselves.
This means a different method needs to be used to deploy an updated version of Google Chrome for Work. To me, the Application model of Configuration Manager is the most suitable environment since it allows to supersede applications. This also means the Task Sequence may be edited frequently as well. Alternatively, a 3rd party update tool such as Secunia can be used as well if the organization has a license for that.
I can conclude that Google has done the right thing to have Google Chrome for Work installed in the system context and manage it by using Group Policy.