Issues after Google Chrome enterprise upgrade

I recently updated Google Chrome Enterprise version 84.0.4147.125 x64 to version 86.0.4240.111 x64. After the upgrade some users had issues. Users that had set Chrome as their default browser before the upgrade could not open URL’s anymore. Some shortcuts that we created to open a specific URL with Chrome by default even if the default browsers wasn’t Chrome didn’t work anymore. In this post I will explain what happened and how you can fix the issues if your would run into them.

What happened

The fist thing worth mentioning is that Google Chrome x64 installed the sources in Program Files x86 NOT in Program Files where 64 bits programs should install their sources. This was an issue that was reported but apparently Google didn’t see it as something to fix right away. Because al lot of versions of Chrome x64 kept installing the sources in Program Files x86.

However when Google announced Chrome version 85 they mentioned in the release notes that from version 85 they would change the installation directory (finally):

Chrome 64-bit on Windows will be installed in “Program Files” instead of “Program Files (x86)”

New installations of 64-bit Chrome will be installed in “%ProgramFiles%” on Windows instead of “%ProgramFiles(x86)%”. Existing installations won’t be impacted.

Sadly I didn’t read the release notes of 85 but i did of 86 (not reading anything about program files), so I deployed the Chrome version 86.0.4240.111 x64 with MECM and superseded and uninstalled the old version 84.0.4147.125 x64. After the upgrade users started mentioning the issues below.

Issues

Manually created shortcuts to Chrome.exe didn’t work anymore of course because chrome.exe was now in a different folder (Program Files), users would have to change or delete them and create new ones. I had to change some shortcuts created with a group policy in order to start certain URL’s with Chrome every time (Even if Chrome isn’t the default browser).

But a bigger issue was that some users who had Chrome as their default browser couldn’t open URL’s anymore. Nothing happened when opening a URL from Outlook or trying to start a VPN authentication webpage in order to use the vpn software.

Problem

The biggest problem was that in some cases the following rekey

HKEY_CLASSES_ROOT\CHromeHTML\shell\open\command

wasn’t set to the correct path:

“C:\Program Files\Google\Chrome\Application\chrome.exe” –single-argument %1

But it was still:

“C:\Program Files (x86)\Google\Chrome\Application\chrome.exe” –single-argument %1

Because of this URL’s didn’t open anymore.

Solution

In order to fix this regkey I created a Configuration Item in the MECM console and deployed it to all devices. A configuration Item is a collection of settings, values, and criteria that defines what is compared, checked, or evaluated on a target system. The CI can detect if the value of the regkey has got the correct value and if the correct value is not detected the CI knows what the correct value should be.

I created a Configuration Item (type Application) in the MECM console in this CI I specified a Discovery script and a Remediation Script (Powershell).


With a Configuration Baseline we can deploy a Configuration Item or more than one if you want to a collection and remediate the value if needed.

I exported the Configuration Item and the Configuration Baseline so you can import them in you MECM console.

Place the extracted Fix Chrome shell command path x64.cab on a location so that you can import it in your MECM console.

Open the MECM console and go to \Assets and Compliance\Overview\Compliance Settings\Configuration Items

Click on Import Configuration Data in the ribbon.

Click Add…

Select the Fix Chrome shell command path x64.cab and click Open.

Click Yes

Click Next >

Now you will see this import will create the Configuration Item AND the Baseline. Click Next >

Click Close

Now you can deploy the Configuration Baseline to a device collection.

Go to \Assets and Compliance\Overview\Compliance Settings\Configuration Baselines and select the Baseline Fix Chrome shell command path x64 and click Deploy in the ribbon.

Check Remediate noncompliant rules when supported (if you want to Allow remediation outside the maintenance windows if you use it select the checkbox)

Browse to the collection you want to deploy and set the evaluation schedule for the baseline. Click OK.

Now to see what happens on a device. Right click on the windows start button and select Run, type control smscfgrc and click OK.

Go to the tab Actions and Select Machine Policy Retrieval & Evaluation Cycle and click Run Now.

Now go to the tab Configurations and click Refresh, now the baseline you deployed will show, click Evaluate.

If you get an error you can click View Report, In this case MECM is not allowed to run unsigned scripts.

You can fix this error by changing a setting in the client settings, go to the console and go to \Administration\Overview\Client Settings

Open the client settings you deployed and go to Computer Agent, change the setting PowerShell execution policy to Bypass.

Go to the tab Actions and Select Machine Policy Retrieval & Evaluation Cycle and click Run Now.

Now go to the tab Configurations again and click Evaluate. You will see that the Compliance State changed to Compliant.

Select the baseline and click View Report. You can now see that the remidiated rule Found the incorrect value and set the correct value of the regkey.

INFO: I wanted this baseline only to run and remediate if Chrome 86.0.4240.111 was installed on the device, because only then the regkey value would have to be changed. The great thing about a Configuration item type application is that you can add a Detection Method. So I added the detection method: Detect a specific application and deployment type based on the Chrome 86.0.4240.111 application I deployed with MECM.

2 thoughts on “Issues after Google Chrome enterprise upgrade

  1. Thanks for spreading the news.

    I’d have done this slightly differently. I’d have used a Test-Path cmdlet in the discovery script so that the remediation only changes the registry data if the data is in fact wrong, it could lead to creating a problem otherwise.

    Regards,
    Dan

    1. Hi Dan, but the remediation does only change the register value if the register is wrong. I didn’t put in the screenshot of the compliance rules of the Configuration item but in this tab I have set the correct value the discover script should output and if the output is different it will remediate the value. Or did you mean something else?

Leave a Reply

Your email address will not be published. Required fields are marked *

Theme: Overlay by Kaira