Windows - Data Collection & Auditing - Automox Agent & Remote Control Diagnostics

What the Automox agent and remote control diagnostic Worklet does

This Automox Worklet™ collects a full diagnostic snapshot of the Automox agent and Splashtop-based remote control stack on a Windows endpoint and writes the formatted report to the Automox activity log. The Worklet inspects the amagent service, validates RAM, free disk, PowerShell version, and processor architecture, enumerates installed TLS 1.2 and TLS 1.3 cipher suites, checks ECDH key exchange, runs HTTPS probes against the Automox API and console, and tests TCP reachability to every required Automox, Splashtop, Microsoft Update, DigiCert, and LaunchDarkly host.

The cipher suite enumeration is the most useful section for hard-to-debug TLS failures. The Worklet calls Get-TlsCipherSuite when available and falls back to reading HKLM:\SOFTWARE\Policies\Cryptography\Configuration\SSL\00010002 and HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers. It compares the installed list against the required TLS 1.3 set (TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256) and the TLS 1.2 ECDHE-ECDSA and ECDHE-RSA suites, then flags each one as compatible or incompatible.

The Worklet runs in diagnostic-only mode by default. Set the ConfigureCipherSuites parameter to $true if you want missing suites written to HKLM:\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002 at the top of the priority list. A system restart is required for the registry change to take effect.

Why centralize Automox agent and remote control diagnostics

Agent connectivity tickets are some of the slowest items in an IT Operations queue. The user reports their endpoint shows as offline; the agent returns a generic check-in failure; the help desk asks for an agent log the user has never seen. Hours pass while a support engineer reproduces the symptom on a test endpoint, only to discover the cause is a TLS inspection proxy stripping a required cipher suite or a missing ECDH key exchange algorithm in SCHANNEL.

FixNow this Worklet against any Windows endpoint with a suspected agent or remote control issue and the activity log captures service status, RAM and disk pressure, TLS protocol support, cipher suite coverage, ECDH availability, HTTPS round-trip to api.automox.com and console.automox.com, and TCP reachability to every Splashtop relay the remote control client needs. The support engineer triages the entire stack from one activity log entry without scheduling a screen share.

How the agent and remote control diagnostic sweep works

1. Evaluation phase: The evaluation script exits 0 immediately so every run reaches the remediation phase where the diagnostic work happens. This pattern lets the Worklet behave as an on-demand audit rather than a compliance gate, so the activity log captures the full snapshot whether or not anything is wrong.

2. Remediation phase: The script runs the full diagnostic. It calls Get-Service amagent for service status, startup type, and LogOn account, reads free RAM via Win32_OperatingSystem and free disk via Get-PSDrive, enumerates TLS 1.2 and 1.3 support against howsmyssl.com, lists cipher suites and key exchange algorithms from SCHANNEL, runs Test-HttpsConnectivity against api.automox.com, console.automox.com, command-storage.prod.automox.com, and storage-cdn.prod.automox.com, and runs raw TCP socket tests against the full Automox, Splashtop, DigiCert, LaunchDarkly, and Microsoft Update host list on the documented ports. Output is written via Write-Output so Automox captures it as the activity log payload. If ConfigureCipherSuites is $true and required suites are missing, the script writes them to the SSL\00010002 Functions registry value.

Agent and remote control diagnostic requirements

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

• Minimum 100 MB of free RAM and 70 MB of free disk on the system drive at the time of the run

• Local administrator or SYSTEM privileges (the default Automox agent context satisfies this) for service queries, SCHANNEL registry reads, and Get-TlsCipherSuite

• Outbound TCP 443 to the Automox, Splashtop, DigiCert, LaunchDarkly, and Microsoft Update host list defined in the script's $NetworkTargets array, and TCP 80 to digicert.com, cdn.digicertcdn.com, dl.delivery.mp.microsoft.com, and ctldl.windowsupdate.com

• Set the ConfigureCipherSuites parameter to $true only when you want the Worklet to write missing cipher suites to HKLM:\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002 and schedule the endpoint for restart afterward

Expected agent and remote control diagnostic output

After the Worklet runs, the activity log entry opens with a SYSTEM REQUIREMENTS block reporting PowerShell version, free disk, free memory, and processor architecture, followed by an AUTOMOX SERVICE STATUS block confirming the amagent service is installed, running under LocalSystem, and set to Automatic. The NETWORK and SECURITY block lists default gateway, TLS 1.2 and 1.3 protocol support, every installed cipher suite tagged [COMPATIBLE] or [INCOMPATIBLE], and ECDH key exchange status. The AUTOMOX HTTPS/TLS CONNECTIVITY block reports response codes and round-trip times for the four critical Automox URLs. The DNS RESOLUTION and PORT CONNECTIVITY block lists DNS lookups and per-port reach results for every host, and the run closes with a Conflict Report summarising every failed check with its current and expected values.

Validate on a known-healthy endpoint and confirm the Conflict Report is empty and the success rate is 100%. If a previously-working endpoint suddenly fails the TLS cipher checks or shows a Cipher Suite Mismatch under HTTPS, the most common cause is a TLS inspection proxy that was recently introduced; coordinate with the network team to exclude the Automox and Splashtop hostnames from inspection. For audit evidence, export the activity log entry and attach it to the support ticket.