Network Health Check

What the network connectivity diagnostic does

This Automox Worklet™ runs an unattended network connectivity diagnostic on a Windows endpoint and writes a structured report into the Automox Activity Log. The diagnostic is read-only. Nothing on the endpoint is modified by this Worklet. That makes it safe to schedule on a recurring policy, run as a FixNow action, or queue against an entire endpoint group during an active network incident.

The PowerShell remediation script captures five datasets in sequence. It samples Wi-Fi signal strength six times at two-second intervals by parsing the Signal line out of netsh wlan show interfaces. It then runs ping -n 10 8.8.8.8 to measure packet loss and round-trip time against a reliable external target. It runs tracert 8.8.8.8 and matches any hop that reports latency at 10ms or above so you can see where the slow link lives. It computes total uptime in days from Win32_OperatingSystem.LastBootUpTime. Finally, it polls \Processor(_Total)\% Processor Time and \Memory\Available MBytes twice at a five-second cadence to spot CPU or memory pressure that might be causing what the user is reporting as a network problem.

Every dataset is written to the Activity Log with a tilde (~) record separator, which makes the output trivially exportable to CSV. You can pull the log out of Automox, split on the tilde, and feed the rows into a sheet, a SIEM, or a network monitoring dashboard without writing a parser. The Worklet runs the subset of commands that produce the most useful triage signal across a fleet: ping, tracert, netsh wlan show interfaces, and Get-Counter for CPU and memory.

Why diagnose endpoint network connectivity from Automox

User-reported network problems are the noisiest ticket category in IT Operations. The complaint is always the same – "my internet is slow," "Zoom keeps dropping," "the VPN won't stay connected" – but the root cause changes endpoint by endpoint. The driver could be a weak Wi-Fi signal in a home office. It could be a 200ms upstream hop in a traceroute. It could be packet loss against DNS, an OS that has not rebooted in 40 days, or CPU and memory exhaustion that masquerades as a network stall. Without objective measurements gathered on the endpoint itself, the help-desk loop turns into screen-shares and guesswork.

Triggering this Worklet from the Automox console collects ping, tracert, Wi-Fi signal, uptime, CPU, and memory data from any Windows endpoint in scope, and the output lands in a single Activity Log entry a help-desk technician can read without opening a remote session. The same Worklet runs against a single user-reported endpoint via FixNow, or across a regional group of laptops when the help desk sees a cluster of "slow internet" tickets coming from one office. The tilde-delimited record format makes the output easy to pipe into a spreadsheet, a SIEM, or a network monitoring dashboard for trend analysis.

How the network diagnostic runs end-to-end

1. Evaluation phase: The evaluation.ps1 script exits with status code 1 unconditionally, which is the standard Automox pattern for action-on-endpoint Worklets that are meant to run on every policy cycle. The exit code marks the endpoint non-compliant, which queues the remediation script. There is no compliance condition to satisfy because the goal is data collection, not configuration drift correction.

2. Remediation phase: The remediation.ps1 script collects five datasets in order. It samples Wi-Fi signal six times via netsh wlan show interfaces over about 12 seconds. It runs Ping -n 10 8.8.8.8 for 10 ICMP echoes. It runs tracert 8.8.8.8 and filters hops at 10ms or above with Select-String. It calculates total uptime from Get-CimInstance Win32_OperatingSystem. It then captures two CPU and memory snapshots via Get-Counter \Processor(_Total)\% Processor Time and \Memory\Available MBytes, spaced five seconds apart. Each dataset is emitted to stdout with Write-Output and separated by a tilde so the Activity Log entry can be split into columns later.

Network diagnostic requirements

• Windows 7, Windows 8.1, Windows 10, Windows 11, and Windows Server 2012 R2 or later (any Windows endpoint the Automox agent supports)

• PowerShell 2.0 or later, which is present on every supported Windows version by default

• Outbound ICMP and UDP to 8.8.8.8 (Google Public DNS); if your network blocks ICMP egress, swap the target in remediation.ps1 to an internal host that responds to ping

• Local administrator context (the Automox agent runs as SYSTEM by default, which already satisfies the performance counter and CIM access this Worklet requires)

• A wireless adapter present for the Wi-Fi sampling block to return data; on wired-only servers and desktops the Signal field is empty and the rest of the report still runs

• Roughly 35 seconds of total runtime on the endpoint: 12 seconds for Wi-Fi sampling, 10 seconds for ping, 10 seconds for CPU and memory sampling, plus a few seconds of tracert and uptime collection

Expected diagnostic output in the Activity Log

After the Worklet runs, the Activity Log entry for the policy execution contains a single multi-line block divided into five tilde-delimited sections. The first line shows total uptime as a decimal day count (for example, Days of Uptime: 12.34). The second block lists the six Wi-Fi signal samples as percentages between 0 and 100. A healthy laptop typically sits between 70% and 100%, and anything below 50% is the likely cause of a slow-connection complaint. The third block is the ping summary from 8.8.8.8 with packet statistics and minimum, maximum, and average round-trip time in milliseconds. The fourth block contains the two CPU and memory snapshots, formatted as AVG CPU: <pct>%, Avail. Mem.: <gb>GB (<pct>%) so you can spot resource exhaustion quickly. The final block is either Trace: All under 10ms, OK or Slow Trace Routes: <hops over threshold>, which tells you whether the path to 8.8.8.8 has a slow hop and which hop is the offender.

To turn the report into structured data, export the Activity Log to CSV and use the tilde as a record separator. From there you can sort across the fleet for endpoints with packet loss, low Wi-Fi signal, or high uptime that suggests a pending reboot. To validate locally on a single endpoint before pushing the Worklet broadly, run the same commands by hand. Useful one-liners include ping -n 10 8.8.8.8, tracert 8.8.8.8, Test-NetConnection 8.8.8.8 -InformationLevel Detailed, ipconfig /all, route print, nslookup automox.com, Get-NetAdapter, and netsh wlan show interfaces. For the resource block, run Get-Counter \Processor(_Total)\% Processor Time and Get-Counter \Memory\Available MBytes. The Worklet output should line up with the manual results. Any divergence usually means the agent is running under a different context than the interactive session.

Because the endpoint itself is unchanged after the run, you can schedule this Worklet on a daily or hourly cadence for a problem fleet and trend the results over time. Re-running it during an active incident gives you a fresh capture without forcing the end user onto a screen-share. The FixNow path lets a help-desk technician fire it ad-hoc against the specific endpoint a ticket is open against.