Windows - Data Collection & Auditing - Retrieve Google Chrome Update Logs

What the Chrome update log retrieval Worklet does

This Automox Worklet™ reads the Google Chrome update log on Windows endpoints and writes the contents directly to the Automox Activity Log. The log file lives at C:\ProgramData\Google\Update\Log\GoogleUpdate.log and is written by GoogleUpdate.exe (Google Update / Omaha) whenever it attempts to check for, download, or install a new Chrome version. Each entry carries a timestamp in [mm/dd/yy hh:mm:ss] format, a severity level, and the underlying installer or network status code.

The remediation script uses Get-Content to read the file and surfaces the last 100 lines by default. Two optional parameters refine the output. LineCount overrides the default and returns the last N lines of the file. DateSearch filters the output to entries whose timestamp begins with a given mm/dd/yy string, which is useful when narrowing down to the exact window an end user reported a stuck update. Both parameters can be combined, so DateSearch "02/23/24" with LineCount 50 returns the last 50 entries from February 23, 2024.

When the log file does not exist on an endpoint, the evaluation script exits 0 and the endpoint stays compliant. That branch is common, because Chrome update logging is not on by default. Pair this Worklet with the companion Enable Logs for Google Chrome Updates Worklet to switch logging on across the fleet before scheduling this one.

Why pull Chrome update logs from every Windows endpoint

Chrome ships a security update roughly every two weeks, and the browser's threat surface includes V8 type confusion bugs, sandbox escapes, and recurring zero-day Chrome CVEs on CISA's Known Exploited Vulnerabilities catalog. When GoogleUpdate.exe fails to apply one of those releases, the endpoint stays on a known-vulnerable build until somebody opens Chrome long enough to trigger a foreground update. GoogleUpdate.log is the only first-party record of why an attempt failed: HTTP 403 against the update server, COM elevation denied, signature verification rejected, disk full during install, or a third-party security agent quarantining the GoogleUpdate.exe binary. Without that log, root cause is guesswork.

Chrome ships a stream of high-severity V8 and renderer CVEs, and an endpoint where GoogleUpdate.exe is silently failing keeps a user on a vulnerable build for weeks before anyone notices. This Worklet reads %ProgramData%\Google\Update\Log\GoogleUpdate.log on every Windows endpoint in scope, normalizes the output into the Automox Activity Log, and lets you triage failing endpoints by GoogleUpdate error code rather than opening a remote session against each laptop one at a time.

How Chrome update log retrieval works

1. Evaluation phase: evaluation.ps1 runs Test-Path against C:\ProgramData\Google\Update\Log\GoogleUpdate.log with -PathType 'Leaf'. If the file is present, the script writes a Flagging for remediation message and exits 2, which queues the remediation phase. If the file is absent, the script exits 0 and the endpoint is marked compliant because there is nothing to retrieve.

2. Remediation phase: remediation.ps1 calls a getChromeUpdateLog function that reads the log with Get-Content -ErrorAction Stop, then applies filters. If DateSearch is supplied, the script builds a regex pattern of \[<date> and pipes through Where-Object { $_ -match $datePattern }. If LineCount is supplied, the filtered set is narrowed with Select-Object -Last $LineCount. By default the remediation returns the last 100 lines. The selected entries are written to stdout, which Automox captures into the Activity Log for the policy run.

Chrome update log retrieval requirements

• Windows 10, Windows 11, or Windows Server 2016 and later with PowerShell 5.1 or PowerShell 7

• Google Chrome installed via the per-machine MSI or the standalone enterprise installer, so GoogleUpdate.exe runs in the C:\ProgramData\Google\Update\ context

• Chrome update logging enabled via the registry value LogFile under HKLM\SOFTWARE\Policies\Google\Update or via the companion Enable Logs for Google Chrome Updates Worklet (UUID f229b271-9eaa-56a7-b9e3-0542cf2c317e)

• Read access to C:\ProgramData\Google\Update\Log\ for the Automox agent service account (the default LocalSystem context already has this)

• Optional LineCount parameter (Int) on the policy when the default 100-line tail is not enough; pass 0 or omit to keep the default

• Optional DateSearch parameter (String) in mm/dd/yy format to isolate a specific incident date

Expected output in Automox Activity Log

After the policy runs, the Activity Log for each flagged endpoint shows a Google Chrome update log was found. Displaying contents header followed by up to the last 100 GoogleUpdate.log entries. Each line keeps its native [mm/dd/yy hh:mm:ss] timestamp, the originating module (goopdate, omaha, GoogleUpdate, or GoogleUpdateBroker), and a status string such as installation succeeded, network request failed, COM server not registered, or signature verification failed. Filter the Activity Log by these strings to triage across managed endpoints from a single console rather than per endpoint.

Endpoints without the log file exit 0 from evaluation and produce no remediation output. Endpoints with the file but no matching date entries return No log entries found for the date: <date> and exit 0 cleanly. Endpoints that hit a Get-Content error (locked file, denied ACL, or corrupted log) surface the PowerShell exception in the Activity Log because the script uses -ErrorAction Stop. To validate end to end, pick one endpoint reporting stuck updates, run this Worklet against it, then cross-reference the returned error codes against the Chrome enterprise release notes for the version installed on that endpoint.