Have UAM verify new installer's hash before uninstalling application

Avatar
Peter Yasuda

This is in reference to Request 101385. This is an edge case, but it happened to us 1/15/2025, the day after a new version of Chrome was released. It looks like our timing was unlucky, and UAM may have seen a new version of Chrome before it was available to download on all CDN sources. My request is for UAM to be modified to download the installer and verify the hash before uninstalling the old version of the application. 

This is what I put in the request: 

The latest version of Chrome stable channel Windows was released yesterday. This morning, during our maintenance window (2 - 3 AM), UAM ran on 5 hosts in a pool. 3 hosts didn't see the new version of Chrome, so did nothing. 2 hosts saw a new version of Chrome available, uninstalled Chrome, then failed to install the new version, because there was a mismatch in the installer hash, maybe because of the timing of when particular CDN servers were hit. Can the logic be changed so that the hash can be verified before the installed version is removed? Also, if UAM policies check every 15 minutes, why wasn't Chrome installed later in the maintenance window? There was also a host in a different host pool that wound up without Chrome. Here's the relevant JSON code:
{"Skipped":false,"Success":false,"Log":"Detect application [Google.Chrome]
Application [Google.Chrome] is found on target host
PackageId: Google.Chrome
RepoUrl: https://cdn.winget.microsoft.com/cache
Version: 132.0.6834.83
Target version 131.0.6778.265
Try to upgrade
Upgrade log:
No available upgrade found.
No newer package versions are available from the configured sources.
Uninstall log:
Found Google Chrome [Google.Chrome]
Starting package uninstall...
Successfully uninstalled
Install log:
Found Google Chrome [Google.Chrome] Version 131.0.6778.265
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://dl.google.com/dl/chrome/install/googlechromestandaloneenterprise64.msi
Installer hash does not match; this cannot be overridden when running as admin
Application [Google.Chrome] not found on target host after installation"}

 

 

1

Comments (6 comments)

Sort by
0
Avatar
Daniel Lundqvist

Agree, there seem to be a problem with the release of Google Chrome from time to time. Very annoying. This sounds like a simple fix for UAM.

1
Avatar
Dave Stephenson
(Edited )

Great catch, Peter!

This is kind of related to something I saw recently with a partner where they were fighting with Chrome auto-updating, but the WinGet repository not being aware of the upgrade, yet, so it did something similar to your logs where it uninstalled Chrome and tried to install an older version.

Are you thinking the "correct" order of operations is this or something different?

  1. Check for upgrades
  2. Is there a newer version already installed and the policy set to "latest"? > Ignore
  3. Is there an older version installed and the policy is set to a specific version? > Install that specific version
  4. Is there an older version installed and the policy is set to "latest"? > Upgrade
  5. When installing, download the installer and do the hash check
  6. If there is a mismatch in the hash, throw an error that can be notified on
  7. If the hash matches, uninstall the previous version
  8. Once uninstalled, install the new version

 

 

0
Avatar
Peter Yasuda

Hi Dave Stephenson,

You have exactly what I was thinking. That process should insure you have a working application, even when something goes wrong with getting the latest version, or there's a hash mismatch. 

Thanks!

0
Avatar
Dave Stephenson

Excellent!
Thanks, Peter. 🙂

Our product team will get this added to the backlog.
However, if anyone else has any ideas/suggestions, please feel free to add them.

0
Avatar
Ryan Dorman

This is one of winget's achillies heels.  We haven't moved to UAM yet but for our Intune envrionments I package winget into Win32 apps with PSADT for a cute visual feedback with ServiceUI.  For apps that are deployed as part of AutoPilot provisoining I've actualled pulled the winget packages back because for Chrome the frequency of updates gives a higher than 5% failure rate on the package due to hash mismatch.  If a package is installed during AutoPilot I try to make sure the vendor has a stable, version neutral download link and pull it directly and dont do a hash check.  Chrome isn't the only one, Egnyte was a recent offender as well.  I had been looking at a 3rd party paid, curated winget repo but it looks like the company pulled back the service offering.  Having logic to work around this limitation of using a public repo would be a big feather in Nerdio's cap.

0
Avatar
Peter Yasuda

Hi Ryan Dorman, I thought the fault was with UAM's logic, but you're saying Winget uninstalls apps before verifying the hash of the downloaded file. That would be more challenging for Nerdio to fix. Up until a few weeks ago we had been using Winget in a Scripted Action update applications, and I don't recall any problems updating Chrome. UAM is running during a 2 - 3 AM maintenance window, and I don't remember when we were running the SA. I had been considering moving the UAM maintenance window, under the theory that we're currently updating Chrome in the same window where they are updating their repos. That seems likely because some hosts in the same policy will update successfully while others have the hash mismatch. Thanks for you comment!

Please sign in to leave a comment.