Update Google Chrome with Winget on Windows 11: Fast, Scriptable, Auditable

Background / Overview​

• It centralizes the update process into a single command, avoiding individual GUI steps.
• It’s script-friendly for automation with Task Scheduler, Intune, or other deployment tooling.
• It can run silently and accept package/source agreements for unattended maintenance windows.

Why update Chrome with Winget (and when not to)​

• Speed and repeatability — run a single command locally or remotely and get the latest packaged version.
• Automation — embed updates in scripts and schedules for unattended maintenance.
• Consistency — ensure the same command is used across many machines (no manual clicks, fewer user errors).

• Environments that require the very latest Google-signed installer before a Winget manifest update is published can see delays; the community repository is curated and may lag official Google releases by minutes to days in rare cases. (learn.microsoft.com)
• There have been documented manifest problems for the Google.Chrome package—hash mismatches and installer-related issues—so organizations that require fail-safe updates should have fallback processes. (github.com)

Quick summary of the single-command flow​

• Open an elevated terminal (Windows Terminal, PowerShell, or Command Prompt).
• Confirm Winget is present and recognized: winget --info.
• Check Chrome’s presence in Winget: winget list Google.Chrome.
• Update Chrome only: winget upgrade Google.Chrome.
• Or update everything: winget upgrade --all.

Step-by-step: update Chrome with Winget on Windows 11​

1. Verify Winget is available and current​

• Open Windows Terminal as Administrator (right‑click Start → Terminal (Admin) or use Win+X → Terminal (Admin)).
• Run:
• winget --info
• If Winget isn’t found, install or update App Installer from the Microsoft Store or retrieve the latest App Installer .msixbundle from the official repository releases. Winget requires the App Installer package to be present. (learn.microsoft.com, pureinfotech.com)

2. Confirm Chrome is installed and discover the package ID​

• To see if Winget recognizes Chrome:
• winget list Google.Chrome
• If Winget returns a row for Google.Chrome you’ll see the installed version and the package ID used by Winget. If not found, Winget may not recognize an existing Chrome installation that was installed by other means (such as an enterprise MSI distribution or user-local installer). In that case, you can install or repair via Winget.

3. Upgrade Chrome (single-package)​

• Standard interactive upgrade:
• winget upgrade Google.Chrome
• For quiet, unattended upgrade (commonly used in scripts), add acceptance and silent flags:
• winget upgrade Google.Chrome --silent --accept-package-agreements --accept-source-agreements
• Note: --silent suppresses installer UI (if the installer supports it), and the --accept-* flags prevent prompts about package or source license agreements during automated execution. Both are documented Winget flags. (learn.microsoft.com)

4. Upgrade everything (all outdated Winget-managed apps)​

• winget upgrade --all
• This checks all Winget-managed packages and upgrades any that have newer manifests. It’s useful for maintenance windows but will update every known eligible package, so review logs or test before rolling it out broadly. (learn.microsoft.com)

5. Confirm the update completed​

• Check Chrome’s reported version in the browser:
• Open Chrome → Menu (⋮) → Help → About Google Chrome (or navigate to chrome://settings/help).
• Alternatively confirm with Winget:
• winget list Google.Chrome
• Cross-checking both is recommended because there are known cases where a Winget-installed Chrome interacts differently with Chrome’s built-in updater (see Troubleshooting section). (google.com, github.com)

Advanced flags and practical examples​

• Exact match by package ID (avoids ambiguity):
• winget upgrade --id Google.Chrome -e
• Restrict to Winget’s source (useful when multiple sources exist):
• winget upgrade Google.Chrome --source winget
• Silent unattended upgrade (suitable for Task Scheduler or Intune script):
• winget upgrade Google.Chrome --silent --accept-package-agreements --accept-source-agreements
• If you want to upgrade to a specific version (gating):
• winget upgrade --id Google.Chrome --version 125.0.6425.0

Automation patterns: scripting and Task Scheduler​

# update-chrome.ps1
Start-Transcript -Path "C:\Logs\winget-update-chrome-$(Get-Date -Format yyyyMMdd-HHmmss).log"
winget upgrade Google.Chrome --silent --accept-package-agreements --accept-source-agreements
Stop-Transcript

• Schedule via Task Scheduler:
• Create a basic task → Run whether user is logged in or not → Run with highest privileges.
• Action: Start a program: Program/script: powershell.exe
• Add arguments: -ExecutionPolicy Bypass -File "C:\Scripts\update-chrome.ps1"
• For enterprise scenarios, deploy via Intune/Group Policy startup scripts or integrate with configuration management tools.

• Use logging (Start-Transcript or redirect stdout/stderr) so you can audit behavior and capture transient errors like manifest mismatches.
• Run an initial dry run (winget upgrade without --all) and check return codes before widespread rollout. (learn.microsoft.com)

Common troubleshooting and known pitfalls​

1. Winget not recognized​

• Symptom: winget command returns “not recognized”.
• Fix: Install/update App Installer from the Microsoft Store or install the Winget client/MSIX bundle from the official releases. Verify winget --info after installation. (learn.microsoft.com, pureinfotech.com)

2. Winget doesn’t see Chrome (package absent)​

• Reason: Chrome was installed by a method Winget didn’t register (user-specific installer, corporate MSI, or different publisher string).
• Fix: Reinstall or repair Chrome via Winget:
• winget install Google.Chrome
  This will download the manifest version and either install fresh or repair so Winget can manage the app moving forward.

3. Installer hash mismatch (manifest problems)​

• Observed problem: Winget downloads the Chrome installer but aborts with “Installer hash does not match”.
• Why it happens: Winget manifest entries include a SHA256 hash for the installer URL. If Chrome’s published installer changes (or Google rotates mirrors), the stored hash can become stale. This triggers safety checks and prevents potentially tampered installers from being installed. This is an issue tracked in the Winget manifests repository and has caused transient failures for the Google.Chrome package. (github.com)
• Workaround:
• Wait for the manifest to be updated in the community repo (Microsoft maintainers usually respond quickly).
• As a temporary measure, download Chrome from Google directly and install, then re-run winget list to ensure Winget recognizes the package.
• Avoid overriding or disabling hash validation in production; that undermines the security checks Winget enforces. (github.com)

4. Chrome’s internal updater breaks after Winget install​

• Observed problem: After installing Chrome via Winget, Chrome’s own “About” page shows update checks fail.
• Real reports: Multiple GitHub issues have recorded cases where Chrome’s version-checking/updater behaved differently when Chrome was installed through Winget manifests versus the standard Google web installers. This can be due to installer switch differences, machine scope (--scope machine vs user), or how Chrome’s updater service is configured. (github.com)
• Mitigation:
• Test a Winget install on a representative machine and confirm chrome://settings/help reports no errors.
• If Chrome’s updater is critical in your environment, maintain a fallback plan (e.g., install via Google-provided MSI that aligns with enterprise policies).
• Report reproducible failures back to the Winget manifests maintainers so maintainers can align manifest behavior with Chrome’s expectations. (github.com)

5. Multiple package sources / ambiguous matches​

• If you see messages about multiple versions or sources, specify the source:
• winget upgrade Google.Chrome --source winget
• Or use the exact match flag:
• winget upgrade --id Google.Chrome -e

Managing update policy: pinning and gating​

• Add a blocking pin:
• winget pin add --id Google.Chrome --blocking
• Remove a pin:
• winget pin remove --id Google.Chrome
• Gating to a version range:
• winget pin add --id Google.Chrome --version 123.*

Security, governance, and enterprise considerations​

• Winget enforces SHA256 checks on downloaded installers in manifests; this is a strong security guardrail but can produce false positives when upstream vendors change packaging quickly. Always monitor the Winget repo issues for widely reported manifest failures and respond according to your operational policy (wait, escalate, or use vetted vendor MSI installers). (github.com)
• Group Policy and Intune can be used together with Winget: Windows 11 includes Group Policy templates related to Windows Package Manager so administrators can control allowed sources, experimental features, and execution policies in managed environments. Plan Group Policy settings before broad automation. (learn.microsoft.com)
• Logging and audit trails are essential. Maintain centralized logs from scheduled scripts and capture Winget’s exit codes for automation dashboards and alerting.

Best-practice checklist before automating Chrome updates with Winget​

• [ ] Confirm Winget/App Installer is deployed and on supported versions across target machines. (learn.microsoft.com)
• [ ] Test winget install Google.Chrome and winget upgrade Google.Chrome on a test image. Verify chrome://settings/help shows a healthy update status. (github.com)
• [ ] Implement logging and capture Winget’s STDOUT/STDERR to centralized storage for failures and audit. (learn.microsoft.com)
• [ ] Add a fallback update path (vendor MSI or manual process) in case manifest problems or hash mismatches occur. (github.com)
• [ ] Use pinning to control broad rollouts or to freeze a specific version during validation windows. (learn.microsoft.com)
• [ ] Keep a cadence to check the Winget manifests repo for high-profile package issues (Google.Chrome is actively tracked by the community). (github.com)

Example real-world automation workflow (illustrative)​

• Daily scheduled PowerShell job at 03:00:
• winget upgrade Google.Chrome --silent --accept-package-agreements --accept-source-agreements
• If the command returns a non-zero exit code, the script:
• Saves detailed logs.
• Sends a short ticket to the admin queue with the log excerpt.
• If manifest-related errors appear three days in a row, escalate to the vendor MSI fallback path (download from Google enterprise channel and install via signed MSI).
• Monthly audit: run winget export on a sample machine to record installed package versions and compare against corporate baseline.

Conclusion​