Greg can you check what's the deal with that one?

Hi. Are you using the stock Google Chrome .msi or a customized one? Could you look for C:\Windows\Temp\chrome_installer.log and attach it? Thanks.

Log file attached

Deleted: chrome_installer.log 152 KB

chrome_installer.log 152 KB View Download

We're using the stock MSI

The logs indicate that the failure is a result of trying to install 58.0.3029.110 onto a machine that already has 59.0.3071.86. This is working as intended. Is it truly your intention to downgrade?

In this case the currently installed version of Chrome is 59.0.3071.86, and the version of the MSI that's been loaded into SCCM is 58.0.3029.110. Our plan is to keep auto-update enabled to avoid having to re-package the installer in SCCM every time Google updates Chrome. We may do so periodically, but it should not be unusual for the SCCM installer to replace an existing installation that's at a higher version. Once installed, the auto-update should bring it back to the current version. The use-case for this would be if a user has a version of Chrome they installed in their profile, we would come behind and install the version from SCCM, replacing the version in their profile with a version in Program Files. I believe that's part of the intended native functionality of this installer.

Installing 58 (for example) into %ProgramFiles(x86)%\Google\Chrome while 59 is installed in %LOCALAPPDATA%\Google\Chrome should "work" in the sense that the older version of Chrome will be installed. There is a caveat, however: Chrome does not support downgrading like this -- whenever a breaking change is made to any of the data stores in %LOCALAPPDATA%\Google\Chrome\User Data, users will see this message upon launching the older version of Chrome:

"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."

This is the reason that the installer will not downgrade a Chrome 59 install to Chrome 58.

Can you add some logic to your update strategy to either ignore failures when a newer version is already installed, or not even try to install when there's already a newer version on the system?

If you're able to introspect into the registry after a failed install, you can detect this "HIGHER_VERSION_EXISTS" error by checking that HKLM\Software\Wow6432Node\Google\Update\ClientState\{8A69D345-D564-463c-AFF1-A69D9E530F96}\LastInstallerError = 4. (Note: if you're able to, omit "Wow6432Node" and instead use the KEY_WOW64_32KEY flag when accessing the registry.

There's 2 parts to this deployment strategy. The first is for users that have an existing installation in their profile. We want to push the MSI to them to have their installation replaced with an installation in Program Files. It's likely the version in their profile is up to date, but we want to standardize on the location so if a new version is released after we package in SCCM then we would be pushing a downgraded version. The auto-update should come behind and bring it up to date but there would be a lag between installation and updating.

The other portion of this deployment would be ongoing. If a user wants Chrome for the first time then they will hopefully install via SCCM. The version in SCCM will again likely be behind the current version but the auto update should take care of that post install. If a user installs from the web and they are not an admin then the first scenario would again apply.

We can include logic in the deployment to only install via SCCM automatically if the installation directory is NOT program files, but placing version logic would cause us an issue as we really don't want to have to re-package every time Chrome has an update released since that occurs quite frequently.

So this error would only be seen by users who try to install Chrome via SCCM without realizing that they already have it installed? Can you provide some messaging to these users on error instructing them to look for Chrome in their Start Menu?

I just completed some testing of various scenarios. Here are my results of what happens when I try to install via the SCCM installer:

Deploy SCCM Chrome onto a machine with an existing installation of 32-bit Chrome that was installed by a non-admin into the Application Data folder - SUCCESSFUL, installation replaced local install with installation into Program Files

Deploy SCCM Chrome onto a machine with an existing installation of 64-bit Chrome that was installed by a non-admin into the Application Data folder - SUCCESSFUL, installation replaced local install with installation into Program Files so it is now running 32-bit

Deploy SCCM Chrome onto a machine with an existing installation of 32-bit Chrome that was installed by an admin into the Program Files folder - FAILED

Deploy SCCM Chrome onto a machine with an existing installation of 64-bit Chrome that was installed by an admin into the Program Files folder - FAILED

Note that in the instances where it was successful, the version of Chrome that was running out of Application Data was higher than the version in SCCM. This indicates that the installer doesn't look at the version number when making the conversion from Application Data to Program Files. In that instance it will install a lower version, and then allow the auto-update function to bring it to current. Only when the existing installation is in Program Files and the existing version is higher than the packaged version does it fail.

Given the above, the only scenario that could potentially remain unaddressed is if a user installed a 64-bit version of Chrome into Program Files and we would like to standardize all machines onto 32-bit. In that case we would have no way of achieving that standardization via SCCM.

In response to the question: "So this error would only be seen by users who try to install Chrome via SCCM without realizing that they already have it installed? Can you provide some messaging to these users on error instructing them to look for Chrome in their Start Menu?"

- The scenario I'm envisioning is a user has intentionally installed Google Chrome as an admin, and we write a deployment in SCCM to push our installer to all machines with an existing version of SCCM. In this case the deployment would fail for the user I specified.

Hi. My apologies for the delay in my response. Here's where we are at the moment:

- Chrome's installer takes care not to allow downgrades, as they can lead to the errors mentioned in comment 7. A an attempt to downgrade results in a HIGHER_VERSION_EXISTS installation error.

- An exception to the above is that Chrome's installer does not check for a higher version in %LOCALAPPDATA% when installing into %ProgramFiles(x86)% because such a check cannot be done reliably. Installs into %ProgramFiles(x86)% are often done as SYSTEM rather than as an interactive user. It's not an easy thing to chieck all users' %LOCALAPPDATA% directories for a higher version (roaming profiles, for instance, make this especially challenging if not outright impossible).

- If I understand correctly, the problem you're having is that some of your users have installed Chrome on their own accord and you wish to push a lower version of x86 Chrome via SCCM. This triggers the HIGHER_VERSION_EXISTS error for those users.

- Chrome's enterprise installer (the .msi) has a feature to allow downgrades. This feature is supported for G Suite and Chrome Browser Assist customers only (see https://support.google.com/chrome/a/answer/6351685?hl=en). This feature comes with a big caveat in that it auto deletes user data on the Chrome launch following the downgrade to avoid the errors mentioned in comment 7. Is this suitable for you?

Ping for cwspot@gmail.com

Closing due to lack of feedback. Feel free to reply if you require further assistance. Thanks.