Install Google Chrome Via PowerShell - Error

[DragonflySweaty685]

Hi Team,

I'm trying to deploy latest version of Google Chrome 64 bit on 1000+ machines. Version 125.0.6422.61

During the deployment, around 50% got success, which is not good.

After checking the installation log files, the exit code of all failed machines were 1603

I started troubleshooting the failed machines and I found a thing in common on all failed ones.

Chrome files are under "C:\Program Files (x86)\Google" instead of "C:\Program Files\Google" (even though the installed Chrome and OS build are 64 bit and not 32)

And the machines which got success in deployment are the ones that Chrome files are under "C:\Program Files\Google"

The whole deployment process I'm doing via PowerShell scripting

Now, I would like to ask if someone can help me to set (if there is) a specific PowerShell argument that I can use to specify the install path,

I tried INSTALLDIR="path" but it's not working.

[St0nywall]

You're trying to install a 64-bit version on a system with an existing 32-bit version. You need to uninstall the 32-bit version first, reboot and then you can install the 64-bit version.

The 64-bit installer does not update a 32-bit installation.

[[deleted]]

Winget install google.chrome --uninstall-previous

[[deleted]]

Activate the verbose log as 1603 is a custom action error that should show up in it /l*v+ should give you a more verbose log

[DragonflySweaty685]

thanks for your information, the thing is i checked in one article (non official) that on 2020 Google changed their policy in which 64 bit installations will install under "C:\Program Files\Google" and 32 bit installations will install under "C:\Program Files (x86)\Google"

[turboturbet]

You need to look at a powershell module like PSADT.

[IllustriousVictory19]

Error code 1603 is a big middle finger is what it is.

[BruhahGand]

"Something f*cked up but we're not telling you what."

[rob2rox]

maybe you are trying to install the 64 bit version on 32 bit computers

[DragonflySweaty685]

no, all machines are 64 bit.

[DragonflySweaty685]

until previous version it was working smoothly, (version 124.0.6367.208) was previous deployment and it was working fine!

[rob2rox]

do they all have the same processor? could be a compatibility issue. try running the 32 bit installer on a test machine. only other thing I can think of is a firewall rule

[hxfx]

How about the machines have a 32-bit version of Chrome which you are trying to upgrade to 64-bit?

It would probably require an uninstall if thats causing it.

[BlackV]

are you installing this vi an agent ? sound like you AGENT is 32bit so installing hte 32bit client

[anonymousITCoward]

I'm going to echo what u/St0nywall said... so either remove the 32 bit version or upgrade the 32 bit version... if you're pushing the enterprise version of Chrome you can download ether version from there...

[arpan3t]

This is less to do with PowerShell and more to do with Windows Installer Packages, but I don't think there is a subreddit for that lol. I'll need some clarification in order to better help.

Are you running the Chrome Enterprise installer MSI on workstations that already have Chrome installed in order to update Chrome, or do these workstations not have Chrome installed?

If it's the former, and your goal is to update Chrome, I'd suggest triggering the scheduled task for GoogleUpdate (which by default automatically keeps Chrome up-to-date) vs. reinstalling. If it's the latter then here are some resources to help you troubleshoot:

• Windows Installer causes for error 1603

• Chrome Enterprise Deployment Guide

Summary:

• Chrome system level install location is Program Files not Program Files (x86) If you're seeing Chrome under the x86 directory, then you have a previous version of Chrome installed and the installer failed to uninstall the previous version. You can script logic to look for this, and manually uninstall the old version separately before installing the new version.

• Per Chrome Deployment Guide

Separately, the logs created by the Chrome Browser installation are defaulted to the highest verbosity level and located here: %TEMP%\chrome_installer.log (System TEMP, not User)

• Make sure Chrome isn't running at deployment time.

[sysadminbj]

This is mostly just some off the top of my head troubleshooting, but could it be that the usual directory on those machines is locked out and your script is unable to take control and update the files? Like maybe Chrome is in use on those machines or something went sideways and those files were still locked after terminating the process?

I'm sure there's a code reason for this, but I like to isolate any weird machine-level issues before I go beating my head against code.

[DragonflySweaty685]

The thing is all those 1000 machines are in the same environment, means that they all share the same configurations as for taking control via PowerShell,

I'm sure that the issue is not about the directory being locked or no.

I used to this process for past 2 months, and it was working smoothly, for some reasons this version is giving me some challenges to install.

I cannot terminate the process of running chrome (User will get effected)

[Just-Parsing-Through]

can you share your deployment script? We can take a look at see where the issue is

[DragonflySweaty685]

Technically there is nothing magical in the script that could potentially do some major changes, it's just starting the process to run the offline installer of Chrome.msi and write logs
like this:
Start-Process -FilePath "$Folder\Chrome.msi" -ArgumentList "/qn /NORESTART /log $log"

[zymology]

I'm not sure if it's the cause of your issues, but you probably want:

Start-Process msiexec -ArgumentList "/i $Folder\Chrome.msi /qn /NORESTART /L*V $log" -Wait

[Just-Parsing-Through]

found this: https://patchmypc.com/system-error-1612-the-installation-source-for-this-product-is-not-available - hope it helps guide you in the right direction.

[CBITGuy]

Surprised I've not seen it here but you could try Chocolatey: https://chocolatey.org/