Brad Dickinson

Admin Essentials: Configuring Chrome Browser in your VDI environment

The content below is taken from the original ( Admin Essentials: Configuring Chrome Browser in your VDI environment), to continue reading please visit the site. Remember to respect the Author & Copyright.

As a Chrome Enterprise Customer Engineer, I often get asked by administrators of virtual desktop infrastructure (VDI) environments what our best practices are for backing up user profiles. For example, many ask us how to minimize backup size to speed up user log-in and log-off into the Windows environment and reduce impact on the overall user experience.

Like any browser, Chrome has cache directories. This is where data is temporarily stored for faster future site loading, cookies are saved in order to provide seamless authentication on websites, extensions cache various resources, and more. Chrome stores all of its caches in folders in the user profile directory. 

VDI administrators may prefer to back up the entire Chrome user profile directory, but the more sites a user accesses, the more the size of the cache folder increases, and the number of small files in those folders can become quite large. This can result in an increased user profile folder backup time. For users, this can lead to slower startup time for Chrome. 

Although we’ll cover different scenarios today, Google Sync is still our recommended method for syncing browser profile data between machines. It provides the best experience for both the user and the administrator as users only need to sign in. However, there are some environments where this option isn’t suitable for technical or policy reasons. If you can’t use Google Sync, there are a few approaches that can be used to minimize the backup size.

Moving the cache folders

One option is for administrators to move the cache folders outside of Chrome’s user profile folder. The VDI administrator will need to identify a folder outside of the Chrome user profile directory where the caches will be stored. Caches should still be in the Windows user’s directory, and keeping them in hidden directories can also reduce the risk of the cache being accidentally deleted. 

Examples of such folder shortcuts would be:

  • ${local_app_data}/Chrome Cache

  • ${profile}/Chrome Cache

The user data directory variables can help you specify the best directory for your caches.

Once the folder location has been decided, administrators need to configure the DiskCacheDir policy that relocates the cache folders. This policy can be configured either via Group Policy or registry. Once the policy configuration has been applied onto the machines, Chrome will start storing the cache directories into the newly defined cache folder location. The administrator might have to do a cleanup of older caches from the user profile folder the first time after enabling this policy as the policy does not remove the old caches.

Then, continue using the standard Chrome user profile directory. This should result in faster startup times for Chrome, as less data will be copied when a user signs-on or signs-off. It’s important to note that this approach will not allow simultaneous sessions from different machines, but it will preserve session data.

Enabling Roaming Profile Support

A second option is to enable the Chrome Roaming Profile Support feature. This will also not allow simultaneous sessions from different machines, and it won’t save a user’s concurrent session data. However, it will enable you to move the Chrome profile into network storage and load it from there. In this scenario, network performance could impact Chrome’s startup time.

To enable Chrome Roaming Profile Support: 

  • Switch on the ​Roaming​Profile​Support​Enabled policy.

  • Optional: Use the RoamingProfileLocation policy to specify the location of the roaming profile data, if this is how you’ve configured your environment. The default is ${roaming_app_data}\Google\Chrome\User Data.

  • If you have been using the UserDataDir policy to relocate the regular Chrome profile to a roaming location, make sure to revert this change.

Advanced controls

While the solutions above will work for most enterprises, there are organizations that want more granular control of the files that are backed up. The approach below allows for more control, but comes at a higher risk, as file names or locations can change at any moment with a Chrome version release. A granular file backup could introduce data corruption, but unlike the other options, it will preserve session data. Here is how to set it up: 

  • Set disk cache to ${local_app_data}\Google\Chrome\User Data with the DiskCacheDir flag.

  • Set user profile to ${roaming_app_data}\Google\Chrome\User Data with the UserDataDir flag.

  • Back up the following files in your VDI configuration:

    • Folder location: AppData\Roaming\Google\Chrome\User Data\.

    • Files: First Run, Last Version, Local State, Safe Browsing Cookies, Safe Browsing Cookies-journal, Bookmarks, Cookies, Current Session, Current Tabs, Extension Cookies, Favicons, History, Last Session, Last Tabs, Login Data, Login Data-journal, Origin Bound Certs, Preferences, Shortcuts, Top Sites, Web Data, Web Data-journal.

Even though this approach preserves session data, it will not enable simultaneous sessions from different machines. 

There you have it—three different approaches IT teams can take to store Chrome caches in VDI environments. Keep in mind that there are a few ways an administrator can push policies onto a machine. For all desktop platforms, Google offers the Chrome Browser Cloud Management (CBCM) console as a one-stop shop for all policy deployments and it allows the admin to set one policy that can be deployed on any desktop OS and Chrome OS. For Windows, the admin can also use GPO or registry settings. For Mac, they can use managed preferences. These templates and more info can be found at chrome.com/enterprise.

If you’d like to learn more about the management options that we make available to IT teams, please visit our Chrome Enterprise web site.

Exit mobile version