Google Chrome on Citrix deep-dive

In this article, Google Chrome on Citrix deep-dive, I will show you how to deploy and configure Google Chrome on Citrix. Using a comprehensive PowerShell script we will automate the unattended installation and some initial configuration for Chrome. This article also deals with the various methods how to configure Chrome, including Microsoft Group Policies and preference files.

Change Log
22.07.2017: correction; add lines to the master_preference file to prevent the creation of (desktop) shortcuts.
25.07.2017: Chrome adds entries to the Active Setup registry keys. Learn how to execute this command line using a VBScript.
20.09.2017: added link to article Deploying Google Chrome extensions using Group Policy.

Table of Contents

Google Chrome on Citrix deep-dive (introduction)

Scripting the unattended installation of Google Chrome is a must in large environments. This article takes you through all the steps.

Fully automating your master images is best-practice, whether it concerns FAT clients, VDI or hosted-shared (e.g. Citrix XenApp, RDS, WTS). The installation and configuration of Google Chrome has always been somewhat difficult to manage though.

In May 2017, Google released the Google Chrome Enterprise Bundle. This bundle provides some improvement over past installations, but it still is not perfect. This article takes you through all the steps to successfully setup and configure Google Chrome in your environment. Also described in this article are the additional complexities when using Citrix XenDesktop, especially on hosted-shared ("XenApp").

An overview of the Google Chrome Enterprise Bundle

The Google Chrome Enterprise Bundle includes all components required to successfully install and configure Google Chrome (as well as the plugin Legacy Browser Support) in an enterprise environment.

The latest version can be downloaded here:
https://enterprise.google.com/chrome/chrome-browser/
.

You can choose to download the 32-bit or 64-bit bundle or the 32-bit or 64-bit standalone Chrome installer. If you choose to download the standalone installer, the ADM/ADMX files for your Group Policies have to be downloaded separately. The version of Chrome in the Enterprise Bundle released in May 2017 is 59. In this article, I work with the 64-bit version.

So, what exactly is included in this bundle? Well, after downloading and extracting the ZIP file GoogleChromeEnterpriseBundle64.zip, you will find three directories:

  • Configuration
    This folder contains the ADM and ADMX files, including multiple language files, which you can add to your Microsoft Group Policies. I strongly recommend to use the ADMX files instead of the ADM files. In my opinion, Google added the ADM files for legacy support only. See the section Using Microsoft Group Policies (preferred) in this article for more information. The folder Configuration also contains the master_preferences file. This file contains pre-configuration settings. For more information see the section Using preference files in this article.
  • Documentation
    As the name suggests, this folder contains documentation. The PDF file README.pdf provides a general overview on how to install, deploy and configure both Google Chrome and the Legacy Browser Support. In the various subfolders you find detailed documentation about all possible Group Policy settings (in multiple languages).
  • Installers
    This directory contains the MSI installation files for both Google Chrome and the Legacy Browser Support.

Google Chrome and Citrix

Is Google Chrome supported on Citrix hosted-shared (XenApp)?

I thought the answer to this question would be an easy one to answer, but it is not. There are many indicators that Chrome is indeed supported on hosted-shared (e.g. Citrix XenApp, RDS, WTS), but I am not able to find a definite statement on this matter from either Google, the Chromium organization nor Citrix.

Let's start with some of the indicators that could make you believe that Chrome is not supported.

First of all, when downloading Google Chrome (the "consumer" way), there is no mention of any server operating system, even in the section Download Chrome for another platform. This seems to me that Chrome is not supposed to run on a server operating system, which, if this were true, would mean that using it on Citrix hosted-shared or WTS/RDS is not supported.

Google Chrome on Citrix deep-dive - Download Google Chrome Google Chrome on Citrix deep-dive - Download Google Chrome

Also, no operating system is mentioned in the section See supported operating systems & system requirements in the official Google article Download and install Google Chrome.

Furthermore, on the Citrix Ready website, Google Chrome is not listed as a Citrix Ready product.

On the other hand, there are various articles from both Google/Chromium.org and Citrix with support information for Chrome on Citrix, for example:

As said in the beginning of this article, I cannot give you a definite statement if Chrome is truly 100% supported on server operating systems and Citrix ("XenApp"). You will have to draw your own conclusion. From a technical perspective, Chrome runs on both Citrix hosted-shared and VDI. A clearer stance on the matter of support from both Google/Chromium and Citrix would be appreciated though.

Roaming profiles

Google Chrome supports roaming profiles. For more information, please see the section Google Chrome and roaming profiles in this article.

Publishing Google Chrome in Citrix Studio/AppCenter

Publishing Google Chrome in Citrix Studio or AppCenter (XenApp 6.x) basically works the same as with any application. The command line contains the path and executable of Chrome (chrome.exe) and the parent folder is set as working directory:

  • Command line: C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
  • Working directory: C:\Program Files (x86)\Google\Chrome\Application

According to the official Chromium article Run Chrome as a virtual application, Chrome 58 and later automatically detect if it is running in a remote desktop environment and adjusts its settings accordingly. The Enterprise Bundle released in May 2017 contains version 59.
In case you use Chrome version 57 or below, Chrome may become unresponsive when started as a published application. To solve this issue, the chrome.exe should be started with the parameters --allow-no-sandbox-job --disable-gpu. For more information, see the Citrix article Google Chrome Becomes Unresponsive when Started as Published Application. The aforementioned Citrix article is obsolete for Chrome version 58 and higher.

Disabling Citrix API hooks for Chrome

In the previous paragraph we saw that according to the official Chromium article Run Chrome as a virtual application, Chrome 58 and higher automatically detects if it is running in a remote desktop environment and adjusts its settings accordingly. This automatic adjustment only refers to the (now obsolete) command line switches (--allow-no-sandbox-job --disable-gpu)! It does not refer to the exclusions for hook injection. Let me explain.

Depending on your Citrix version, you may experience problems when launching Chrome. Besides the issue with the command line switches as described in the previous paragraph, you may also need to add the executables chrome.exe and nacl64.exe to the exclusion list for hooks injection as described in the Chromium article Run Chrome as a virtual application and the Citrix article How to Disable Citrix API Hooks on a Per-application (CTX107825). The official bug report (Chromium) can be read here: https://bugs.chromium.org/p/chromium/issues/detail?id=432595.

On the 24th of July 2017, Citrix released a new article called Chrome fails to launch in a published desktop. This article relates to Chrome errors such as "Aw, Snap!" page crashes and gray screens without any message. The solution to solve these errors is the same as above; the processes chrome.exe and nacl64.exe need to be excluded from the Citrix API hooks.

So what exactly does Chrome install on the local system?

Google Chrome and the Legacy Browser Support install the following components on your system:

  • Application files:
    • Chrome:
      • C:\Program Files (x86)\Google\Chrome (64-bit), including the master_preference file located in the directory C:\Program Files (x86)\Google\Chrome\Application.
      • C:\Program Files\Google\Chrome (32-bit), including the master_preference file located in the directory C:\Program Files\Google\Chrome\Application.
    • Legacy Browser Support:
      • C:\Program Files\Google\Legacy Browser Support (32-bit and 64-bit)
  • User files in the directory C:\Users\%User Name%\AppData\Local\Google\Chrome.
  • A shortcut to Google Chrome on the public desktop. The path is %Public%\Desktop\Google Chrome.lnk, which by default is C:\Users\Public\Desktop.
  • Two services:
    • Google Update Service (gupdate)
    • Google Update Service (gupdatem)Google Chrome on Citrix deep-dive - Google Chrome services
  • Two scheduled tasks:
    • GoogleUpdateTaskMachineCore
    • GoogleUpdateTaskMachineUAGoogle Chrome on Citrix deep-dive - Google Chrome scheduled tasks
  • Computer specific registry entries in the key HKEY_LOCAL_MACHINE\SOFTWARE\Google
  • User specific registry entries in the key HKEY_CURRENT_USER\SOFTWARE\Google
  • Active Setup entries (see also this section in this article):
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\{8A69D345-D564-463c-AFF1-A69D9E530F96}

Scripting the unattended installation of the Google Chrome Enterprise Bundle with PowerShell

Installing Google Chrome and the Legacy Browser Support

The basic installation procedure for both the Google Chrome and the Legacy Browser Support is a piece of cake. The command line to install both components is as follows:

msiexec.exe /i "C:\GoogleChromeStandaloneEnterprise64.msi" /qn /norestart /l*v "C:\Logs\GoogleChromeStandaloneEnterprise64.log"

msiexec.exe /i "C:\LegacyBrowserSupport_4.7.0.0_en_x64.msi" /qn /norestart /l*v "C:\Logs\LegacyBrowserSupport_4.7.0.0_en_x64.log"

However, you still may run into some troubles when Chrome cannot reach the Internet. The installation may hang and end in an error. This can be fixed with the MSI parameter NOGOOGLEUPDATEPING=1. As per Google:

"I'm trying to install behind a firewall, and the install is timing out and failing.
The problem is that by default, Google Update is attempting to check for an update on install and fails at the firewall. When passed a special parameter, the installation will not do this check, and should install regardless of outside connectivity. The special parameter is "NOGOOGLEUPDATEPING=1", and is used like this:"

msiexec.exe /i "C:\GoogleChromeStandaloneEnterprise64.msi" NOGOOGLEUPDATEPING=1 /qn /norestart /l*v "C:\Logs\GoogleChromeStandaloneEnterprise64.log"

For more information concerning installation issues, please see the article Common Problems and Solutions from the Chromium projects.

Currently, I am not aware of any other available product specific MSI parameters.

At the end of this article I have prepared a complete installation and configuration script based on my installation template. This script does NOT include the NOGOOGLEUPDATEPING=1 parameter! This script has been created for Windows Server 2008 R2 and higher. I have tested it on Windows Server 2016 only.

To successfully install Google Chrome and the Legacy Browser Support using this script, please follow these steps:

  • Create an installation directory on the local computer or on a file share (UNC path). For example: C:\Temp\Google\GoogleChrome.
  • Create a subdirectory called Files.
  • Download and extract the latest version of the Chrome Enterprise Bundle to the folder Files in the installation directory.
  • Copy the complete PowerShell script at the end of this paragraph to a new PS1 file (e.g. Install_GoogleChrome.ps1) and add this file to the root of your installation directory (not in the subdirectory Files).
  • Execute the PowerShell script:
    powershell.exe -file C:\Temp\Google\GoogleChrome\Install_GoogleChrome.ps1

In case you get a security warning, set the execution policy to allow the script to run:
powershell.exe -executionpolicy bypass -file C:\Temp\Google\GoogleChrome\Install_GoogleChrome.ps1.

To uninstall Google Chrome and the Legacy Browser Support, execute the script as follows:

powershell.exe -file C:\Temp\Google\GoogleChrome\Install_GoogleChrome.ps1 Uninstall

Log files are created in the directory C:\Logs\GoogleChrome, but you can change this to any directory you want (see lines 529 to 530).

Reference:

Deploying the "master_preference" file

User settings can be managed using Microsoft Group Policies and preference files. The master_preference file contains pre-configuration settings (the default settings) for any new user who starts Chrome on the local computer. This paragraph explains how to deploy this file; for more information on how to use and configure the master_preference file, please see the section Using preference files in this article.

In the previous paragraph Installing Google Chrome and the Legacy Browser Support, we created the directory C:\Temp\Google\GoogleChrome and the subdirectory Files. Add your customized master_preference to the subdirectory Files.

In the complete installation script at the end of this article, the customized master_preference file is copied to the directory C:\Program Files (x86)\Google\Chrome\Application. See line 594.

The actual function DS_CopyFile is located between lines 525 to 396 in the complete script.

Disabling services and scheduled tasks (disable auto-update)

On a Citrix worker, whether it concerns hosted-shared ("XenApp") or VDI, applications should not automatically update themselves. There are many reasons for this:

  • Changes to your productive virtual machine and/or golden master image should be 100% in control of the administrator. Unplanned (and especially untested) changes can cause problems. The administrator should always be aware of changes to the system for which he or she is responsible.
  • Application updates should be tested before going into production. Again, this is to ensure stability and to be able to guarantee continuity in the functionality of the application.
  • Disabling auto-updates is a must for some environments, for example when Provisioning Server is in use. Any changes to the virtual machine would end up in your RAM, assuming that's where your write cache is pointing.

To prevent Chrome from automatically updating itself, the administrator can disable the Group Policy setting Update policy override in the section Computer Configuration \ Policies \ Administrative Templates \ Google \ Google Update \ Applications \ Google Chrome. For more information on Chrome Group Policies see the section Using Microsoft Group Policies (preferred) in this article.

Note: please be aware that Google does not recommend disabling auto-updates (as described in the article Install and update Google applications).

Even with the auto-update policy disabled, Google's update services and scheduled tasks are still present on the local system. I choose to disable the services Google Update Service (gupdate) and Google Update Service (gupdatem) and to remove the scheduled tasks GoogleUpdateTaskMachineCore and GoogleUpdateTaskMachineUA.

The complete installation script at the end of this article disables the update services and removes both scheduled tasks.

In lines 598 to 603, the functions DS_StopService and DS_ChangeServiceStartupType are executed to stop and disable both services:

The DS_StopService (lines 183 to 245) obviously stops the service, but the function also checks for potential depend services. In case other services depend on the service you want to stop, these services are stopped first. The last service to be stopped is the one you specified when calling the function. In this particular scenario, there are no depend services.

In lines 607 to 610 the scheduled tasks are removed:

Removing scheduled tasks actually requires two functions. The function DS_GetAllScheduledTaskSubFolders retrieves all functions in all (sub)folders. The function DS_DeleteScheduledTask actually deletes the scheduled task (see lines 433 to 519). Part of the code I got from the Microsoft Script Center repository (https://gallery.technet.microsoft.com/scriptcenter/Get-Scheduled-tasks-from-3a377294). The code of the two functions is as follows:

Removing the public desktop shortcut

The complete installation script at the end of this article includes the removal of the public desktop shortcut. The shortcut, Google Chrome.lnk, is located in the directory %Public%\Desktop, which by default points to C:\Users\Public.

In line 615 I execute the function DS_DeleteFile:

The DS_DeleteFile function contains detailed logging and error handling, but the main command within this function is a simple one:

The shortcut (the name of which is stored in the variable $File) is deleted.

For most applications, this action would be sufficient to prevent the desktop shortcut from being created for new users. Unfortunately, not for Google Chrome (many thanks to Tommy Kozlowski for bringing this to my attention).

Some lines need to be added to the master_preferences file to prevent shortcuts from being created for new users:

  • "create_all_shortcuts": false,
  • "do_not_create_desktop_shortcut": true,
  • "do_not_create_quick_launch_shortcut": true

Here is a screenshot of the custom master_preferences file shipped with Chrome 59, including the three aforementioned lines.

Google Chrome on Citrix deep-dive - master_preferences prevent creation of shortcuts

I have added two blue arrows to remind you to correctly set the commas. All grouped items within a JSON segment end with a comma; except for the last item in the segment.

Seamless applications, Active Setup, StubPath and logon script

Note: many thanks to Bruce Spies for bringing this issue to my attention!

Google Chrome adds a command line to the Active Setup registry keys, located here:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\{8A69D345-D564-463c-AFF1-A69D9E530F96}\StubPath

The command line, shipped with Chrome version 59, is as follows:

"C:\Program Files (x86)\Google\Chrome\Application\59.0.3071.115\Installer\chrmstp.exe" --configure-user-settings --verbose-logging --system-level

A command line in a StubPath registry entry (located within the Active Setup registry keys) is executed at logon. However, when starting a seamless application, the Active Setup keys are not executed. The same goes when you have disabled Active Setup, for example by renaming the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components.

So how to solve this issue? One way is to use a logon script. The following example is a small VBScript which you can execute by itself or add to your own logon script. For logon scripts I recommend using VBScript, because it loads faster than a PowerShell script. What this script does is the following:

  • Read the command line from the Chrome StubPath entry in Active Setup. The main reason for this is that the command line contains the Chrome version. By reading the command line directly from the registry, the command line is not hard-coded in the VBScript, keeping it flexible for future updates of Chrome.
  • Execute the command line.
  • Write a flag entry in the user's registry (HKEY_CURRENT_USER) to ensure that the command line is only executed once.

The VBScript does not contain true logging; please replace the lines starting with "wscript.echo" with your own logging function. The error handling is all there.

To change the location of the flag entry, please change lines 23 to 25.

Execute the script using cscript.exe, for example: cscript.exe C:\InitializeGoogleChrome.vbs

Different ways how to configure Google Chrome

There are three ways how to manage Google Chrome settings:

Using Microsoft Group Policies (preferred)

The recommended method to manage Chrome settings is through Microsoft Group Policy. As per Google: "For Windows, it is recommended to use Group Policy vs. preferences files because only Group Policy can be enforced". The same statement is made in the Chrome Deployment Guide: "Use Windows Group Policies (GPO policies) and cloud policy over preferences when possible. Unlike policies, preferences do not apply to previous installations of Chrome and are only applied to a single profile. Policies also override any preferences settings for a feature. Also note that the master_preference file can be changed and not enforced like group policies can".

The use of preference files is explained two sections below.

Google provides both ADM and ADMX files to manage its various products. I strongly recommend you to use the ADMX files only. Before you can use Microsoft Group Policies to configure Google Chrome, you first need to import the Google Chrome ADMX files in your Group Policy Central Store.
The ADMX files, as well as the ADMX language files, (*.ADML) can be found in the directory Configuration\admx of the Chrome Enterprise Bundle (after extraction the ZIP file).

In case you are not familiar with the Central Store for Group Policies or you require more detailed information, please see the official Microsoft article How to create and manage the Central Store for Group Policy Administrative Templates in Windows.

Google provides the following four ADMX files:

  • chrome.admx
  • google.admx
  • GoogleUpdate.admx
  • LegacyBrowserSupport.admx

The purpose of each of these ADMX files is quite self-explanatory in my opinion, except for the ADMX file google.admx. This file only has one purpose, which is to define the shared “Google” folder in the Group Policy editor. This folder ensures that all Google policy settings (whether for Chrome or another Google product) are grouped under one header.

Google Chrome on Citrix deep-dive - Google Chrome Microsoft group policies

The Group Policy Central Store is located on your domain controllers. The ADMX files are located in the root of the store and the language files, the ADML files, are located in a language-specific subdirectory:

  • Central store root (containing the ADMX files):
    \\%LogonServer%\sysvol\#DomainName#\Policies\PolicyDefinitionsGoogle Chrome on Citrix deep-dive - Group Policy Central Store
  • Central store subdirectories for the language files:
    \\%LogonServer%\sysvol\#DomainName#\Policies\PolicyDefinitions\#language-country#

Copy the ADMX files here:Google Chrome on Citrix deep-dive - Group Policy Central Store ADMX files

Copy the English ADML files here:Google Chrome on Citrix deep-dive - Group Policy Central Store ADML files

Make sure to copy non-English ADML files to their appropriate directories. The correct directory name for your specific language can be found in the directory Configuration\admx of the Chrome Enterprise Bundle (after extraction the ZIP file).

Now that you have copied all required files, you can start configuring your settings using a Group Policy editor (such as the Group Policy Management Console).

In case you do not want to update your central store right away, you can first perform some tests by using the local ADMX repository on a server. The local repository on a Windows server is located here: C:\Windows\PolicyDefinitions. The same procedure for copying the ADMX and ADML files applies as with the central store. Use the local Group Policy editor to configure your settings (gpedit.msc).

Important: future versions of Chrome will have updated ADMX and ADML files. Please remember that your Group Policy settings are NOT affected when you update ADMX files. Your settings are stored in different files within each individual Group Policy itself:

  • Registry.pol -> contains group policy settings
  • *.xml (e.g. Files.xml) contains your group policy preference settings

The path to an individual group policy is as follows:
\\%LogonServer%\sysvol\#DomainName#\Policies\#PolicyGUID#

After configuring your Chrome settings you can see if your Chrome policies are being applied by entering chrome://policy in the Chrome address bar. This will show you all Chrome settings that are applied for your machine and user.

Google Chrome on Citrix deep-dive - Chrome applied policy overview

User settings can either be mandatory or recommended. Mandatory user settings are configured here:

User Configuration \ Administrative Templates \ Google \ Google Chrome

Recommended user settings are configured here:

User Configuration \ Administrative Templates \ Google \ Google Chrome - Default Settings (users can override)

On the local server or client, the Chrome computer and user policies are stored in the following registry keys:

  • HKEY_CURRENT_USER \ SOFTWARE \ Policies \ Google \ Chrome
  • HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Google \ Chrome

For more information concerning the centralized managing of Chrome extensions please see the article Deploying Google Chrome extensions using Group Policy.

Using parameters

Google provides a very long list of command line switches for the chrome.exe executable file. These switches allow an administrator to change the behavior of the application.

For a complete list of all available switches, please see the following article: https://peter.sh/experiments/chromium-command-line-switches.This article seems to be the official list, since this link is referred to in the Chromium article Run Chromium with flags.

I do recommend caution when using these switches, because they can only be used together with shortcuts. In case users have other ways of starting Chrome (e.g. via the command line), no shortcuts are used and therefore no switches will be applied. This can result in unplanned behavior.

Using preference files

The main and preferred method to manage Chrome settings is through Microsoft Group Policies. However, Chrome also includes a so-called master_preference file which contains settings that are either not supported by a policy or settings you as an administrator may want to pre-configure at installation time. At logon time, the master_preference file is copied to the user's profile in the directory C:\Users\a\AppData\Local\Google\Chrome\User Data\Default. The file is also renamed to Preference. The file is only copied in case the user does not have a preference file yet (so normally at first logon). As soon as the user starts working with Chrome, the user's settings are stored in the preference file.

As per Google/Chromium: "When users start Chromium / Google Chrome for the first time, they do not yet have any Preferences file. A file named "master_preferences" located next to chrome.exe or chromium executable, is used as a template for what becomes users' Preferences file. On a system with Chrome installed from an MSI, this will be C:\Program Files\Google\Chrome\Application\master_preferences".

So when do you as an administrator configure user settings using a preference file or Group Policies? First of all, in most cases, it will not be necessary to change anything in the master_preference file. For most configurations, you will use the preferred method Group Policies to manage your settings. For the most part, you will only need to modify and deploy the master_preference file if you want to configure certain initial settings, for example if you want to prevent shortcuts from being created. Please see the article Configuring Other Preferences for more information.

The master_preference file and the user specific preferences file are just text files that contain JSON markup. JSON is similar to XML, but with various advantages such as being light-weight, easily readable for humans and language independent. For a quick overview, please see the following article. You can use any text editor (e.g. Notepad) if you want to change the configuration of the default master_preference file. The default file is located in the directory Configuration of the Chrome Enterprise Bundle (after extraction the ZIP file). See the Chromium article Default user preferences for more information.

According to Google, policies always take precedence over preference files. In my experience however, I had some issues with my user specific preference file and the Chrome user policies which users can override.

Google Chrome on Citrix deep-dive - Chrome policies default settings users can override

You see, the settings in the "normal" Chrome user policies, in the section Google Chrome, above Google Chrome - Default Settings (users can override), cannot be changed by the user. These are true policies. The settings in the section Google Chrome - Default Settings (users can override) are preferences. They are not mandatory and can be overridden by the user.

The issue I had was the following. I enabled the setting Show Home button on toolbar in the section where the user can override this setting. I did not have this setting enabled anywhere else (e.g. in a local machine policy). The home button never appeared in my browser. In both Chrome (chrome://policy) and in the resultant set of policy (gpresult /r) I saw that the policy setting was applied, but I did not see the home button. I then checked my preference file in my user directory and discovered that show_home_button was set to false (in the screenshot it is set to true). As soon as I set the value to true in the preference file all worked fine.

Google Chrome on Citrix deep-dive - Chrome user preference file extract

I have to honestly admit that I am still not sure why this problem occurred, but in case you experience similar issues, please make sure to check the user specific preference file.

Disable Google Chrome auto-updates

Please see the section Disabling services and scheduled tasks (disable auto-update) in this article regarding disabling Chrome updates.

Google Chrome and roaming profiles

The combination of Google Chrome and roaming profiles is a bit of a confusing topic. So far, I have discovered three ways to roam user settings.

Roaming profiles (AppData\Local)
By default, Google Chrome stores all user data in the directory C:\Users\%User Name%\AppData\Local\Google\Chrome\User Data (see also the Chromium article User Data Directory). One way to synchronize the user data is to include this directory in your roaming profile configuration (as far as it is excluded).
By default, Citrix User Profile Manager includes the directory C:\Users\%User Name%\AppData\Local. On the other hand, Windows roaming profiles, by default, excludes this folder (as well as all such as the History, Temp, and Temporary Internet Files).
Although Citrix User Profile Management includes the Appdata\Local folder, Citrix recommends to exclude the following four subfolders:

  • Appdata\Local\Google\Chrome\User Data\Default\JumpListIcons
  • Appdata\Local\Google\Chrome\User Data\Default\JumpListIconsOld
  • Appdata\Local\Google\Chrome\User Data\Default\Cache=
  • Appdata\Local\Google\Chrome\User Data\Default\Cached Theme Images=

However, in the Chromium article Common Problems and Solutions, it is recommended not to use roaming profile due to potential problems such as mismatched profiles and Chrome versions. The recommendation is to use Google Sync instead.

Google Sync can be used to synchronize data across devices. See the article Sync Chrome data across devices for more information. Google Sync requires that you are signed in with your Google account when using Chrome. Your configuration is stored in your Google account and replicated to other Chrome instances (again requiring you to be signed in of course).

Roaming profiles (AppData\Roaming)
Google Chrome offers a special option to be used in combination with roaming profiles. As explained in the article Using Chrome on roaming user profiles, settings such as bookmarks, auto-fill data, passwords, per-computer browsing history, browser preferences and installed extensions can be stored in a file called profile.pb. This file is stored in the directory:
C:\Users\%User Name%\AppData\Roaming\Google\Chrome\User Data
(= %AppData%\Google\Chrome\User Data\Default).

By default, all profile solutions synchronize the directory %AppData%, thus ensuring that the file profile.pb is synchronized as well. There are three methods how you can enable the creation of the profile.pb file:

  • Add the command line flag --enable-local-sync-backend to the Chrome.exe in the Chrome shortcut. See the article How to specify command line flags for more information.
  • Change the registry value RoamingProfileSupportEnabled with value 00000001 in the registry key HKCU\Software\Policies\Google\Chrome as described in the section in the section RoamingProfileSupportEnabled in the article Policy List on Chromium.org.
  • Enable the Group Policy setting Enables the creation of roaming copies for Google Chrome profile data in User Configuration \ Policies \ Administrative Templates \ System \ User Profiles.

So which solution should you use? The correct answer is: "it depends". For example, if you keep your Chrome versions the same across your devices and you create one roaming profile per Windows-based operating system (thus not using the same roaming profile for multiple operating systems), the settings in the default directory AppData\Local can be synchronized without problems (at least in my experience). This is the case for most Citrix environments I would imagine.
In case you want to provide users with the same settings on all devices and all operating systems with potentially different versions of Chrome, I would go for Google Sync.
In case you want to provide users with the same settings on all devices on a variety of Windows-based operating systems with the same version of Chrome, you can use the option of creating the Chrome profile.pb roaming profile file. This method can also be used in your Citrix environment in case it is better suitable than synchronizing the entire AppData\Local folder.

It goes without saying that the above suggestions first need to be tested in your environment before implementing any of them in production.

Complete script for installing and (partially) configuring Google Chrome

In case you use my installation template, this is what the complete script, including logging and error handling, looks like.

This script has been created for Windows Server 2008 R2 and higher. I have tested it on Windows Server 2016 only.

You can change the base logging directory and the package name (which is used to construct the log file name) in lines 529 to 530.

Make sure to prepare for the installation directory as described in the section Installing Google Chrome and the Legacy Browser Support.

Execute the script as follows, for example:
powershell.exe -file C:\Temp\Google\GoogleChrome\Install_GoogleChrome.ps1

In case you get a security warning, set the execution policy to allow the script to run:
powershell.exe -executionpolicy bypass -file C:\Temp\Google\GoogleChrome\Install_GoogleChrome.ps1

Log files are created in the directory C:\Logs\GoogleChrome, but you can change this to any directory you want (see lines 529 to 530).

Conclusion

Scripting the unattended installation of Google Chrome is not easy, but manageable. I hope this article helps you to get your own installation and configuration up-and-running without any headaches.

Share this post:
Dennis Span on EmailDennis Span on LinkedinDennis Span on Twitter
Dennis Span
Dennis Span

Dennis Span works as a Senior Citrix Architect for a large insurance company in Vienna, Austria. He holds multiple certifications such as CCE-V, CCIA and CCEA. In 2017, Dennis became a Citrix Technology Advocate (CTA). Besides his interest in virtualization technologies and blogging, he loves spending time with his family as well as snowboarding, playing basketball and rowing. He is fluent in Dutch, English, German and Slovak and speaks some Spanish.


27 thoughts on “Google Chrome on Citrix deep-dive

    • Thanks a lot for the link, but in all honesty, I already found and read that article. It certainly seems that Citrix and especially "hosted-shared" is supported, but unfortunately I cannot find any official confirmation. To me, "official" means a clear confirmation of support on either google.com, chromium.org or citrix.com. Thanks once again for your input! I appreciate it.

  1. Pingback: Detailed Change Log – Carl Stalhood

  2. Pingback: EUC Weekly Digest – July 15, 2017 – Carl Stalhood

  3. Hi Dennis,
    This is a great article !

    However, the desktop icons are still created, even when deleting the link from the Public profile.
    You will need to use the master_preferences file for this and add these lines :
    "create_all_shortcuts": false,
    "do_not_create_desktop_shortcut": true,
    "do_not_create_quick_launch_shortcut": true,

  4. What do you suggest for the scenario where Chrome is published as a seamless application (XA 6.5) and Active Setup's do not run? there is an Active Setup being added by the installer, and that will not run unless the Desktop is loaded. I would normally disable that, and replace it with something in the login script to run the command (just once). However the stubpath for this new active setup points to a version specific folder, which tells me it could change as Chrome is updated and then my login script 'hack' would stop working. That is just a guess but I think a risk.

    Thanks!

    • Hi Bruce,

      First of all, thanks a lot for your input. I completely missed the Active Setup keys I must admit. I have just updated my article with this input. I think that you will be especially interested in the VBScript I added. The way to solve your issue is to directly read the command line from the registry (from the StubPath value). This way, you do not have to add the command line hard-coded into your logon script, which means no issues with future versions of Chrome.

      You can find the updated section here: http://dennisspan.com/google-chrome-on-citrix-deep-dive/#StubPath

      Good luck!

  5. Hi Dennis,

    We are having performance related issues with our XenDesktop VDI's. Will excluding Chrome exe's improve this at all? The external articles refers more to XenApp.

    • Hi Yusuf, my apologies for the late reply. I was on holiday. Perhaps you can be more precise on the kind of performance issues you are experiencing. Is the Chrome.exe consuming too much CPU? Or RAM? Do you have GPU acceleration enabled? Excluding the Chrome.exe from the Citrix API hooks can help to solve certain issues (also on VDI), but I doubt that you will experience a better performance. But give it a try I would say.

      • Hi Dennis,

        I hope you had a nice holiday. Yes, as suggested chrome.exe is hammering the RAM. Also some users are getting infamous "Aw snap" errors.

        The GPU acceleration is already disabled.

        Best regards
        Yusuf

        • Hi Yusuf,

          Thanks, the holiday was great!

          I am sure that you already searched for a possible solution using Google. There are many articles out there describing a great number of potential solutions. In my experience, one of the main causes for extensive RAM usage relates directly to the number of tabs simultaneously opened in Chrome. In my case, the extension called "The Great Suspender" helps a lot, because it suspends open tabs. The plugin can be downloaded from the Chrome Web Store (https://chrome.google.com/webstore/detail/the-great-suspender/klbibkeccnjlkjkiokjodocebajanakg). You can configure the time after which an open tab is suspended. I did a test with 20 open tabs, using up 1,1 GB of RAM. After the plugin suspended these tabs, only 335 MB of RAM was used. This is quite a significant reduction.
          Use the Windows Task Manager and the internal Chrome task manager (Settings \ More Tools \ Task Manager) to monitor the RAM usage. Install the aforementioned plugin and do some tests of your own. In case the plugin solves the issue, you can use a Group Policy to distribute the plugin to your users (https://support.google.com/chrome/a/answer/188453?hl=en).
          As I said before, there are many other tweaks you can use to try to minimize Chrome's RAM usage, but you can easily find these with a search on Google.

          Regarding the "Aw Snap" errors, there is an official Google page with some potential solutions: https://support.google.com/chrome/answer/95669?co=GENIE.Platform%3DDesktop&hl=en. Also watch out not to mix default roaming profiles with various versions of Chrome (see also the section in my article http://dennisspan.com/google-chrome-on-citrix-deep-dive/#GoogleChromeRoamingProfiles). Also check your Microsoft EMET settings in case you are using EMET. You may have to exclude Chrome.

          I hope my suggestions are of help to you. Good luck!

          Bye,

          Dennis

          • Hi Yusuf, one more thing, regarding the "Aw Snap" errors, Citrix released the following new article on the 24th of July: "Chrome fails to launch in a published desktop" (https://support.citrix.com/article/CTX226044). The solution is to exclude the processes "chrome.exe" and "nacl64.exe" from the Citrix API hooks. Please don't be fooled by the description in the section "Problem Cause". This description is not accurate; excluding Chrome from the Citrix API hooks and adding the parameters "--allow-no-sandbox-job --disable-gpu" to your published application are two different things. You may be confused in thinking that Chrome version 58 and higher automatically includes these two processes in the registry, which is not true. What is new in Chrome 58 and higher is that you can publish the "chrome.exe" without adding the parameters "--allow-no-sandbox-job --disable-gpu".

  6. Pingback: Site Updates – July 2017 – Carl Stalhood

  7. Pingback: Deploying Google Chrome extensions using Group Policy - Dennis Span

  8. Pingback: Published Applications – Carl Stalhood

  9. Hi dennis. I also try chrome in citrix. For me it is not clear how to deploy extensions for all users. I try adblock i add extension id in gpo but what is with the downloaded installer for the extension? Have you here also a good docu. Thx for the great article. Regards frank

  10. Hi,

    I am trying to deploy Google Chrome for Enterprise for XenApp within Windows 2008R2 - VDA 7.6 CU3. For normal windows roaming profile users, no problem. But for some Citrix users with UPM - I get the following message. "Your profile can not be used because it is from a newer version of Google Chrome. Some features may be unavailable. Please specify a different profile directory or use a newer version of Chrome". The current version installed on XenApp is 58.

    Would I also need to add the API hooks on the XenApp gold image?

  11. I am attempting to run your script as posted without changing anything, and am receiving the following error when running on a test box:
    Join-Path : Cannot bind argument to parameter 'Path' because it is null.
    At C:\Temp\Google\GoogleChrome\Install_GoogleChrome.ps1:566 char:26
    + $FileFullPath = Join-Path <<<< $StartDir $FileSubfolder
    # Concatenate the two directories $StartDit and $InstallFileFolder

    • Hi Louis,

      In line 566, where the error occurs, two directories are concatenated (merged); the directory defined in the variable $StartDir and the directory defined in the variable $FileSubfolder. The variable $StartDir is automatically determined by the script in line 533. The $FileSubfolder variable is defined in line 565. By default, this directory is called "Files". I assume that this subdirectory is missing in your installation path or called differently. In case you used a different name, enter the correct name in line 565 (replacing the value "Files"). That should fix your problem. Good luck!

Leave a Reply

Your email address will not be published.

*