Windows - Forensics - Get Automox Remote Control Log (rc-Module.log)

What the Remote Control log retrieval Worklet does

This Automox Worklet™ extracts entries from the Automox Remote Control module log (rc-module.log) on Windows endpoints and writes the matching lines into the Automox Activity Log. The log lives at C:\Program Files (x86)\Automox\modules\rc\rc-module.log and captures session establishment, WebRTC negotiation, authentication exchanges, and the errors thrown when any of those steps fails.

The remediation script wraps Get-AmRemoteControlLog, a single PowerShell function that supports six retrieval modes. The default mode returns the last 100 error-level entries, which is the right answer for most ad-hoc troubleshooting. The other five modes cover full-log capture, last-N lines, date-scoped queries, and combinations of date plus line count or error filter.

Because the Worklet writes back to the Activity Log on each run, the diagnostic data ends up in the same audit surface as patch results and policy runs. Support engineers can pivot from a failed Remote Control session timestamp to the matching rc-module.log lines without opening a fresh session to the affected endpoint.

Why centralize Remote Control diagnostics

Remote Control failures are usually surfaced by the user. An admin clicks Connect, the session never opens, and the support ticket arrives with no log attached. Manual log retrieval requires a separate session to the endpoint, which is the same surface that just failed. The rc-module.log already contains the answer; the bottleneck is getting that file off the endpoint and into a place a support engineer can search.

Reviewing rc-module.log normally means a remote session into the user's endpoint, navigating into the Automox install directory, and copying the log content into the ticket by hand. Run this Worklet against any Windows endpoint with a Remote Control issue to retrieve rc-module.log directly from C:\Program Files (x86)\Automox\modules\rc\ and stream the relevant entries into the Activity Log, so the next ticket arrives with the diagnostic data already attached. The Activity Log keeps the captured entries with the policy run, which makes them searchable from the console long after the log itself has rotated on the endpoint.

How Remote Control log retrieval works

1. Evaluation phase: Tests for the presence of C:\Program Files (x86)\Automox\modules\rc\rc-module.log using Test-Path. If the file exists, the endpoint is flagged for remediation and the script exits 1. If the log is missing, the script exits 0 and remediation is skipped, which means endpoints without the Remote Control module installed do not consume policy time.

2. Remediation phase: Runs Get-AmRemoteControlLog -LogPath $LogPath -LineCount 100 -ErrorSearch $true by default, returning the last 100 error-level entries from rc-module.log. Change line 128 in remediation.ps1 to swap to one of the other five modes: full log, last N lines, date-scoped, date plus line count, or date plus error filter. All matching lines are written to standard output, which Automox captures into the Activity Log for the policy run.

rc-module.log retrieval requirements

• Windows Server 2016 or later, or Windows 10 or Windows 11 workstation

• PowerShell v4 or higher

• Automox agent with the Remote Control module installed

• Read access to C:\Program Files (x86)\Automox\modules\rc\

• Optional: edit line 128 of remediation.ps1 to switch retrieval modes. Default is mode 3 (last 100 error entries); see the script's .USAGE block for all six combinations

• Optional: pass a DateSearch value in YYYY-MM-DD format to filter to a specific day's events

Expected rc-module.log output in the Activity Log

After the Worklet runs, the Automox Activity Log for that policy contains every line of rc-module.log that matched the configured filter. The default invocation surfaces the last 100 lines whose text matches the regex "error", which typically includes session timeouts, failed authentication exchanges, and WebRTC negotiation errors. Each line is preserved verbatim, including its native timestamp, so the entries can be correlated with the originating support ticket.

If no lines match the filter – for example, the endpoint has not produced any error-level entries in the searched range – Get-AmRemoteControlLog returns a single line stating that no entries were found. That outcome is informational, not a failure: the script still exits cleanly and the policy run is marked successful. To validate against a known-good run, schedule the Worklet on a pilot endpoint that has produced at least one Remote Control session. Then check the Activity Log for entries matching the rc-module.log lines visible directly on the endpoint.