How to Silently Install Google Chrome with PowerShell
Deploy Chrome without prompts using the Enterprise MSI, PowerShell, logging, exit-code checks, and rollout guidance for managed Windows devices.
Use the Google Chrome Enterprise MSI with Windows Installer from an elevated PowerShell process. The common deployment command is msiexec.exe /i with /qn for no user interface and /norestart to prevent an unexpected reboot.
$msi = 'C:\Install\googlechromestandaloneenterprise64.msi'
$log = 'C:\Windows\Temp\ChromeInstall.log'
$proc = Start-Process -FilePath 'msiexec.exe' `
-ArgumentList @('/i', $msi, '/qn', '/norestart', '/L*v', $log) `
-Wait `
-PassThru
if ($proc.ExitCode -ne 0) {
throw "Chrome installation failed with exit code $($proc.ExitCode)"
}
Write-Host "Chrome installed successfully. Exit code: $($proc.ExitCode)"
Run PowerShell as administrator, or run the script through a device-management agent operating as SYSTEM. Quote the MSI path whenever it contains spaces.
1. Choose the right Chrome installer
For managed, system-wide deployment, download the current Google Chrome Enterprise MSI and confirm that its architecture matches the endpoint. Keep the MSI in a controlled local or network location. The consumer installer EXE is intended for interactive or per-user installation and is not the usual choice for Windows software distribution.
An MSI installation is system-level. Google documents that installing Chrome from an MSI overrides a version installed by a user, provided the MSI is newer than the version already deployed. User-level Chrome normally resides below the user profile, while system-level Chrome is installed under Program Files\Google\Chrome\Application\.
Pre-install checklist
- Use the Enterprise MSI, not a consumer download, for managed deployment.
- Verify 32-bit or 64-bit architecture requirements for the target devices.
- Check that the package version is newer than the deployed Chrome version.
- Copy the MSI to a readable local path or a network share accessible to the deployment identity.
- Ensure the deployment process has administrator or
SYSTEMrights. - Reserve a writable location for the verbose Windows Installer log.
- Pilot the package on representative test computers before broad rollout.
2. Run a completely silent install
One-line PowerShell command
Start-Process msiexec.exe -ArgumentList @('/i', 'C:\Install\googlechromestandaloneenterprise64.msi', '/qn', '/norestart') -Wait
Recommended deployment wrapper
This version validates the input file, creates a log directory, waits for Windows Installer to finish, and fails the deployment when the exit code is not successful.
[CmdletBinding()]
param(
[Parameter(Mandatory = $false)]
[string]$MsiPath = 'C:\Install\googlechromestandaloneenterprise64.msi',
[Parameter(Mandatory = $false)]
[string]$LogPath = 'C:\Windows\Temp\ChromeInstall.log'
)
$ErrorActionPreference = 'Stop'
if (-not (Test-Path -LiteralPath $MsiPath -PathType Leaf)) {
throw "MSI was not found: $MsiPath"
}
$logDirectory = Split-Path -Parent $LogPath
if (-not (Test-Path -LiteralPath $logDirectory)) {
New-Item -ItemType Directory -Path $logDirectory -Force | Out-Null
}
$arguments = @(
'/i'
$MsiPath
'/qn'
'/norestart'
'/L*v'
$LogPath
)
$process = Start-Process `
-FilePath 'msiexec.exe' `
-ArgumentList $arguments `
-Wait `
-PassThru
switch ($process.ExitCode) {
0 { Write-Output 'Chrome installation completed.'; exit 0 }
3010 { Write-Output 'Chrome installation completed; a reboot is required by the installer.'; exit 3010 }
default { throw "Chrome installation failed with exit code $($process.ExitCode). See $LogPath" }
}
Many management systems treat exit code 3010 as success with a reboot pending. Because /norestart is supplied, schedule any restart according to your maintenance policy instead of allowing the installer to restart a device unexpectedly.
3. Understand the Windows Installer switches
| Switch | Purpose | Typical use |
|---|---|---|
/i |
Installs the specified MSI. | Always include it for a new deployment. |
/q |
Sets a quietness level. | Google’s documented silent pattern uses msiexec /q /l GoogleChrome.msi. |
/qn |
Suppresses all Windows Installer user interface. | Use for unattended device deployment. |
/norestart |
Prevents an automatic restart. | Preferred in managed environments. |
/L*v |
Writes a verbose log. | Use a writable absolute path for diagnosis. |
/l |
Enables installer logging. | Use the logging flags required by your deployment system. |
4. Deploy to multiple Windows computers
PowerShell remoting
Copy the MSI to each computer, then invoke the wrapper remotely. The remote identity must have administrative rights and the target must permit PowerShell remoting.
$computers = @('PC-001', 'PC-002', 'PC-003')
$sourceMsi = 'C:\Packages\googlechromestandaloneenterprise64.msi'
foreach ($computer in $computers) {
$remoteMsi = "\\$computer\C$\Windows\Temp\ChromeEnterprise.msi"
Copy-Item -LiteralPath $sourceMsi -Destination $remoteMsi -Force
Invoke-Command -ComputerName $computer -ScriptBlock {
$msi = 'C:\Windows\Temp\ChromeEnterprise.msi'
$log = 'C:\Windows\Temp\ChromeInstall.log'
$p = Start-Process msiexec.exe -ArgumentList @('/i', $msi, '/qn', '/norestart', '/L*v', $log) -Wait -PassThru
if ($p.ExitCode -ne 0 -and $p.ExitCode -ne 3010) {
throw "Chrome failed with exit code $($p.ExitCode)"
}
$p.ExitCode
}
}
Group Policy, Configuration Manager, and other software distribution
Google documents MSI distribution through Active Directory Group Policy, Microsoft System Center Configuration Manager, SMS, and other software-distribution tools. In those systems, upload or reference the Enterprise MSI, select a computer-targeted deployment, and use the silent install command or the MSI assignment mechanism provided by the platform.
Use a staged rollout:
- Deploy to a small test collection that represents your hardware and Windows versions.
- Confirm that Chrome launches for a standard user.
- Open
chrome://policyon a test computer and verify effective policies. - Use
gpupdate /forcewhen you need to refresh Group Policy during testing. - Review installer logs and management-system return codes.
- Expand the deployment in rings and keep the MSI available until all targets report success.
5. Configure policy after installation
Installation and policy management are separate steps. Chrome supports Windows Group Policy and cloud policies, and Google supplies policy templates for managed Windows PCs. Device-level policies apply whether or not a user is signed in; user-level policies apply to a particular signed-in user.
After installation, verify policy scope on a test endpoint:
- Use
chrome://policyto inspect effective values and refresh status. - Confirm that the policy is assigned to the intended computer or user scope.
- Check that the policy template version matches the Chrome version you deploy.
- Test with both a signed-in user and a device at the Windows sign-in screen when device-level behavior matters.
6. Version precedence and upgrade behavior
An Enterprise MSI does not automatically mean every package version can replace every existing installation. Google warns that an older MSI cannot overwrite a newer deployed Chrome version. Before rollout, compare the package version with the version already installed across the target group.
The MSI installation overrides a user-installed Chrome version when the MSI is newer. Plan upgrades as a versioned package process: identify the target version, pilot it, deploy it in rings, and retain the previous package and logs for rollback investigation.
7. Troubleshooting silent Chrome installation
| Symptom | Likely cause | Fix |
|---|---|---|
| PowerShell says the MSI cannot be found. | The path is wrong, the share is unavailable, or the SYSTEM account cannot read it. | Use Test-Path, copy locally, or grant the deployment identity read access. Quote paths containing spaces. |
| Nothing appears on screen and you cannot tell whether it worked. | /qn intentionally suppresses the interface. |
Use -Wait -PassThru, inspect the exit code, and enable /L*v logging. |
| Exit code indicates another installation is in progress. | Windows Installer is locked by another MSI transaction. | Wait for the other installation to finish, then retry. Do not launch several MSI installs concurrently on one device. |
| Installation fails with an access or elevation error. | The process is running as a standard user. | Run elevated or use a device-management agent running as SYSTEM. |
| An older package does not replace Chrome. | The installed Chrome version is newer than the MSI. | Obtain a current Enterprise MSI and compare versions before deployment. |
| Chrome installs but policies are missing. | Policy scope, templates, or refresh state is incorrect. | Check chrome://policy, verify computer versus user targeting, and run gpupdate /force during testing. |
| The script reports failure after Chrome appears installed. | The management system interprets a nonzero Windows Installer code as failure, or the process was interrupted. | Review the verbose log and handle documented codes such as 3010 according to your platform’s success and reboot rules. |
| Remote deployment works interactively but fails from management software. | The management agent uses a different identity, commonly SYSTEM, with different network and file permissions. |
Test under the same identity, prefer a local staging path, and ensure the log directory is writable. |
8. Reliability, performance, and cost considerations
- Reliability: Treat the MSI as a versioned artifact, validate its path before execution, wait for completion, capture verbose logs, and record exit codes centrally.
- Performance: Staging the MSI on a local disk avoids repeated network reads. Deploy in rings so network traffic and installer contention remain predictable.
- Reboots: Keep
/norestartin unattended jobs and coordinate maintenance-window restarts separately. - Concurrency: Avoid running multiple Windows Installer transactions simultaneously on the same computer.
- Security: Restrict write access to the package and log locations. Use a trusted distribution channel and verify the package before broad deployment.
- Licensing cost: The MSI command itself does not add a PowerShell or Windows Installer fee. Any management platform, storage, or network cost comes from your existing deployment environment.
9. Or skip the browser setup
If your next step is generating screenshots for documentation, QA, reports, or deployment portals, ScreenshotNeo removes the need to operate a browser yourself. Its API accepts one GET request and returns a PNG, JPEG, WebP, or PDF. See the ScreenshotNeo documentation for the complete option list.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp
import requests
r = requests.get(
"https://api.screenshotneo.com/v1/shot",
params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot failed: ${res.status}`);
const buffer = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', buffer));
ScreenshotNeo accepts cookie and consent banners like a visitor, then removes more than 60 known consent platforms along with newsletter popups and chat widgets; each cleanup step can be turned off. Bot checks, CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, and the response identifies the result with X-Page-Verdict and X-Billed headers. An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots.
Create a free ScreenshotNeo account to get 1,000 screenshots each month without a card.
10. FAQ
Can I silently install the consumer Chrome EXE?
For managed Windows deployment, use the Chrome Enterprise MSI. It integrates with Windows Installer and software-distribution systems and supports system-level installation.
Does /qn stop Chrome from launching?
No. It only suppresses the Windows Installer interface during installation. Chrome can be launched after the MSI completes.
Should I use per-user or device-level policy?
Use device-level policy when settings must apply regardless of who is signed in. Use user-level policy when settings belong to specific signed-in users.
How do I confirm the policy actually applied?
Open chrome://policy on the test computer, review the effective values, and refresh Group Policy with gpupdate /force when appropriate.
What should a deployment system record?
Record the MSI version, target computer, execution identity, start and finish time, Windows Installer exit code, reboot status, and the path to the verbose log.


