Windows - Software - Disable Google Chrome Updates

What the Chrome update disabler does

This Automox Worklet™ disables Google Chrome's built-in automatic update mechanism on Windows endpoints. The Worklet writes a Google Update per-application policy value into the registry at HKLM:\SOFTWARE\Policies\Google\Update, which GoogleUpdate.exe reads on every check-in. Once the policy value is in place, Chrome stops polling for new versions and the in-browser update controls report that updates are managed by the organization.

The Worklet supports four configuration modes through the chromeUpdatePreference variable at the top of the script: 0 (updates disabled), 1 (automatic and manual updates enabled), 2 (manual updates only), or 3 (automatic updates only). The default is 0, which is the strictest setting and the one most fleets want when Chrome is being managed through the Automox third-party software catalog. Change the variable and the output label switches between DISABLED, ENABLED, MANUAL, and AUTOMATIC ONLY so the policy run log records the chosen mode.

Chrome installations and updates delivered through the Automox third-party software catalog are unaffected by this configuration. The policy value blocks GoogleUpdate's own scheduler, not MSI-based Chrome deployments. That separation is the point: Automox owns the cadence, and the browser stops racing the catalog.

Why enforce admin-controlled Chrome update channels

Chrome ships a stable-channel update roughly every four weeks and security patches in between, each of which can land on a user's laptop without warning. When a version bump breaks an internal web app, a SaaS console, or a Citrix-published browser, the support tickets arrive faster than any rollback can be coordinated. The Google Update per-application policy value at HKLM:\SOFTWARE\Policies\Google\Update is the documented Chrome Enterprise control point for this, and it is the setting that survives across Chrome upgrades, profile resets, and user uninstalls.

The Google Update policy key drifts in three predictable ways: a fresh image lands without the HKLM:\SOFTWARE\Policies\Google\Update entry, a user with local admin rights deletes the value, or a Chrome reinstall recreates the GoogleUpdate scheduled task and re-enables auto-update. This Worklet asserts the per-application Update value continuously, so the next evaluation catches drift before it becomes a stalled patch window or an audit finding against CIS Benchmark guidance on managed browser updates.

How Chrome update enforcement works

1. Evaluation phase: The evaluation script calls a Test-Registry helper to look up the Update{8A69D345-D564-463C-AFF1-A69D9E530F96} property under HKLM:\SOFTWARE\Policies\Google\Update and compares its value to the chromeUpdatePreference setting. If the value matches the desired state, the Worklet writes "The Google Chrome automatic update setting matches the configured policy." and exits 0. If the property is missing or the value differs, the script exits 1 and Automox schedules remediation on the endpoint.

2. Remediation phase: The remediation script calls Set-RegistryProperty with the same path, name, and value. The helper uses Test-Path to confirm the HKLM:\SOFTWARE\Policies\Google\Update key exists and calls New-Item -Path $Path -Force to create the full path when it is missing. It then writes the Update{8A69D345-D564-463C-AFF1-A69D9E530F96} property via New-ItemProperty using the default String type, or via Set-ItemProperty when the property already exists. The script logs "Google Chrome automatic updates set to: DISABLED" (or ENABLED, MANUAL, AUTOMATIC ONLY) so the policy run log records the final state.

Chrome update policy requirements

• Windows workstation or server; Chrome Enterprise update policies apply to both endpoint types

• Google Chrome installed on the endpoint (the policy is harmless on endpoints without Chrome; the key is just unused)

• Administrative privileges to write under HKEY_LOCAL_MACHINE\SOFTWARE\Policies. The Automox agent runs as SYSTEM and already meets this

• PowerShell with the registry provider available (default on every supported Windows version)

• Optional: edit chromeUpdatePreference at the top of evaluation.ps1 and remediation.ps1 to set the desired mode (0 disabled, 1 enabled, 2 manual only, 3 automatic only). Keep the two scripts in sync or the Worklet will loop

• Plan to deliver Chrome through the Automox third-party software catalog or a separate Worklet so endpoints still receive patched versions on a managed cadence

Expected Chrome update state after remediation

After the Worklet runs, HKLM:\SOFTWARE\Policies\Google\Update contains a value named Update{8A69D345-D564-463C-AFF1-A69D9E530F96} set to the chosen mode (0 by default, written as a REG_SZ string because the script uses PowerShell's default registry property type). Chrome reads the policy at startup and on its standard policy refresh cycle. The browser stops contacting tools.google.com for update checks. The GoogleUpdate.exe scheduled tasks (GoogleUpdateTaskMachineCore and GoogleUpdateTaskMachineUA) still run but find no work to do. The About Chrome page reports that updates are managed by the organization. The policy survives Chrome version upgrades delivered through the Automox catalog because it lives outside the application's own configuration.

Validate from a sample endpoint with Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Google\Update' -Name 'Update{8A69D345-D564-463C-AFF1-A69D9E530F96}' to confirm the value matches the policy. Open chrome://policy in the browser and confirm the Google Update policies appear with the expected source listed as Platform. For audit evidence, capture the Automox activity log entry showing exit code 0 and the registry value snapshot, then attach both to the change record. The Worklet is idempotent, so a recurring policy run keeps the value pinned across reimages and user-driven Chrome reinstalls.