Windows
View all Worklets
WindowsWindows

Pull Splashtop Streamer Logs from Windows Endpoints

Pull Splashtop Streamer logs from Windows endpoints into the Automox activity log for centralized troubleshooting

Worklet Details

What the Splashtop log collector for Windows does

This Automox Worklet™ collects Splashtop Streamer log files from Windows endpoints and writes their contents to the Automox activity log so a support engineer can read them without remoting back into the user's machine. The Worklet reads the ProgramData log directory at C:\ProgramData\Splashtop\Splashtop Remote Server\Log and the per-user AppData log directory at %USERPROFILE%\AppData\Roaming\Splashtop, then concatenates the recent entries into a single output blob keyed by the endpoint identifier.

Because the Worklet runs as the Automox agent (NT AUTHORITY\SYSTEM by default), it can read log paths under each user's profile that the user cannot reach through the streamer UI without elevation. The script handles both the legacy Streamer log layout and the current one, so a fleet with mixed Splashtop versions returns consistent output. Files older than a configurable cutoff (default 7 days) are skipped to keep the activity log entry manageable.

The evaluation phase is read-only. The remediation phase writes the collected log content to Write-Output, which Automox surfaces as the policy run's activity log payload. Nothing on the Windows endpoint is changed; the Worklet is a pull-only collector. Pair this Worklet with the Splashtop restart Worklet when a connectivity issue needs both log evidence and a service bounce on the same run.

Why centralize Splashtop log collection from Windows endpoints

When a Splashtop session fails on Windows, the answer is in the log. The problem is the log lives on a user's machine that may be offline, in another time zone, or already power-cycled before anyone can reach it. The standard workflow is to ask the user to email the log file, which fails when the user does not know where the log lives or has already tried a reinstall that wiped it. Engineers end up reproducing the failure on a test endpoint while the original symptom drifts out of memory.

Diagnosing a flaky Splashtop Streamer normally means ten separate ticket exchanges to retrieve ten different log files from ten different users, and the streamer rotates its own logs aggressively. FixNow this Worklet against the Windows endpoints with Splashtop Streamer installed to pull SRStreamer.log and the supporting Splashtop log set into the central Activity Log in one shot. A support engineer can compare patterns across endpoints in a single query instead of chasing users, and the collected output is preserved for the policy retention window, which usually outlasts the streamer's own log rotation on the endpoint.

How Splashtop log collection works

  1. Evaluation phase: The Worklet runs Test-Path against C:\ProgramData\Splashtop\Splashtop Remote Server\Log and enumerates per-user log directories under each profile in C:\Users. It uses Get-ChildItem with the -Filter *.log argument to find log files newer than the configured cutoff. If any candidate file matches, the endpoint is flagged for collection. Endpoints with no recent Splashtop activity are reported compliant and skipped.

  2. Remediation phase: The remediation script reads each candidate file with Get-Content, tails the last N lines (configurable, default 500) to limit the activity log payload, and concatenates the output prefixed by the source path. The combined text is written with Write-Output so Automox captures it in the policy run output. Exit 0 on success or non-zero if a permission error blocked one of the log paths.

Splashtop log collection requirements

  • Windows 10, Windows 11, or Windows Server 2016 and later with Splashtop Streamer installed at some point in the recent past

  • Local administrator or SYSTEM privileges for the Automox agent (the default agent context satisfies this) so the script can read log paths under each user profile

  • MaxAgeDays parameter set in the policy (default 7) to filter out log files older than the support engagement window

  • TailLines parameter set in the policy (default 500) to cap the activity log payload at a readable size

  • Activity log retention long enough to cover the support ticket lifecycle; ship the output to a SIEM if a tighter retention policy is in place

Expected Splashtop log output

After the Worklet runs, the Automox activity log for the policy run contains the tail of every Splashtop Streamer log file found on the endpoint, prefixed with the source path. A typical run on a multi-user Windows desktop returns one or two ProgramData-level logs and a per-user log for each profile with recent streamer activity, totaling 500 to 2,000 lines depending on session volume. Endpoints with no recent Splashtop activity record a compliant verdict and contribute no log content.

Validate the Worklet on one known-broken endpoint where Splashtop has logged an authentication error or a session drop in the last 24 hours, then confirm the activity log payload reflects the same content the engineer would see in the Streamer support panel. For audit evidence, export the activity log entry as a text artifact and attach it to the support ticket. The Worklet does not alter the endpoint, so it is safe to run on a recurring schedule for proactive log collection during an ongoing investigation.

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