Windows
View all Worklets
WindowsWindows

Windows - Forensics - Get Automox Agent Log (Amagent.log)

Retrieve amagent.log entries from Windows endpoints into the Activity Log for remote agent troubleshooting

Worklet Details

What the Automox Agent log retriever does

This Automox Worklet™ reads the amagent.log file at C:\ProgramData\amagent\amagent.log on Windows endpoints and writes the requested portion of the file to the Automox Activity Log. The amagent.log is the primary diagnostic surface for the Automox Agent. It records policy evaluation runs, Worklet execution, patch scan results, server check-ins, and authentication or network failures with timestamped entries.

The remediation script defines a Get-AmagentLog PowerShell function with two optional parameters, -LineCount and -DateSearch, which combine to give you four retrieval modes. With no parameters, the function returns the entire log. With -LineCount N, it returns the last N entries. With -DateSearch 'YYYY/MM/DD', it returns every line containing that date string. With both parameters, it returns the last N entries from that date. The default invocation on line 115 pulls the last 100 lines, which keeps output well inside the 1 MB Activity Log ceiling.

The output is written to stdout, which the Automox Agent captures and renders as Activity Log output on the policy run. You can target a single endpoint, a device group, or the full Windows fleet and read every result from one place. The Worklet does not modify, rotate, truncate, or delete the source log; it is read-only.

Why pull amagent.log into the Automox console

When the Automox Agent stops behaving as expected, the answer almost always lives in amagent.log. The file records the agent service starting, the heartbeat to the Automox cloud, the policy list pulled down on each cycle, every Worklet evaluation and remediation invocation, and the exit code each script returned. Without that file, you are guessing at why a single Windows endpoint missed a patch window or why a Worklet that ran cleanly across the rest of the fleet failed on one host. The traditional alternative is to open a remote session, navigate to C:\ProgramData\amagent\, and read the file by hand, which scales poorly across a distributed fleet.

Running this retriever as a FixNow against a single misbehaving Windows endpoint, or scoping it to an endpoint group when a regional check-in problem is suspected, pulls C:\ProgramData\amagent\amagent.log directly into the Automox console alongside the policy result it explains. Support engineers triage the failure from the console without opening an RDP session, walking a user through a screen share, or asking another admin to navigate the host file system.

How Automox Agent log retrieval works

  1. Evaluation phase: The Worklet runs Test-Path on C:\ProgramData\amagent\amagent.log with -PathType 'Leaf' to confirm the agent log exists on the endpoint. If the file is present, the script writes a confirmation line to stdout and exits 1 to flag the endpoint for remediation. If the path is missing, the script writes a not-eligible message and exits 0, so the endpoint is skipped without an error state. The evaluation flags any endpoint where the log exists, so account for that behavior when scheduling the policy.

  2. Remediation phase: The remediation script defines the Get-AmagentLog function, then invokes it on line 115 with the parameters you configured. The function re-validates the log path, validates -DateSearch against the regex ^\d{4}/\d{2}/\d{2}$ when supplied, reads the file with Get-Content, optionally filters by date using Where-Object with [regex]::Escape, optionally trims to the last N lines using Select-Object -Last, and writes the resulting lines to stdout. If the filter returns nothing, the function writes 'No log entries were found with your defined search criteria.' and exits 0. The Automox Agent captures stdout into Activity Log output.

Agent log retrieval requirements

  • Windows 10, Windows 11, or Windows Server 2016 or later with the Automox Agent installed in the default location

  • PowerShell 4.0 or later (Get-Content, Where-Object, and Select-Object -Last are all available in 4.0 and above)

  • amagent.log present at C:\ProgramData\amagent\amagent.log (the default path; non-default installs are out of scope)

  • Automox Agent runs as LOCAL SYSTEM by default, which already has read access to amagent.log; no additional permissions to configure

  • Edit line 115 of the remediation script to set the parameters you want: -LineCount N for the last N lines, -DateSearch 'YYYY/MM/DD' for a specific day, both parameters together to combine them, or neither to return the full file

  • Plan for the 1 MB Activity Log ceiling: prefer -LineCount with a small N (50–500) or a single-day -DateSearch rather than the entire log

Expected Activity Log output after retrieval

After the policy runs, the Activity Log for each targeted endpoint contains the requested slice of amagent.log. Each entry retains its original timestamp, log level, and message text. The default -LineCount 100 invocation produces the most recent 100 entries in chronological order. -DateSearch returns every line containing the supplied YYYY/MM/DD token, which pairs well with a known incident window. Combining -DateSearch with -LineCount narrows that day to its most recent N lines for shorter output. If the filter matches nothing, the Activity Log shows the literal string 'No log entries were found with your defined search criteria.' instead of an empty result.

Validation and follow-up: Scan the output for repeated check-in failures, HTTP 4xx or 5xx responses from the Automox cloud endpoint, certificate validation errors, or non-zero exit codes from Worklet remediations. Cross-reference the timestamps against the policy run that triggered your investigation. If the date filter returns nothing, drop -DateSearch and re-run with a larger -LineCount. If the output is truncated at the 1 MB cap, narrow the window with -DateSearch or a smaller -LineCount. Because amagent.log is read-only here, you can re-run the Worklet repeatedly against the same endpoint without changing its state.

View in app
evalutation image
remediation image

Consider Worklets your easy button

What's a Worklet?

A Worklet is an automation script, written in Bash or PowerShell, designed for seamless execution on endpoints – at scale – within the Automox platform. Worklets deploy named-CVE mitigations within hours of disclosure, perform configuration, remediation, and install or remove applications and settings across Windows, macOS, and Linux.

do more with worklets