Install Latest Agent On Systems With Old Agents

What the Automox agent upgrade Worklet does

This Automox Worklet™ detects when a Windows endpoint is running an Automox agent older than the current GA release and triggers an in-place upgrade to the latest version. The Worklet calls https://console.automox.com/api/info with Invoke-RestMethod to read the published agent_version, then queries HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\* for the entry where DisplayName equals "Automox Agent" and compares its DisplayVersion against the API response. Endpoints already on the latest GA build are reported compliant and the Worklet exits without making changes.

The remediation path is deliberately asynchronous. The Worklet downloads Automox_Installer-latest.msi from https://console.automox.com/installers/ into the SYSTEM context $env:TEMP directory (typically C:\Windows\Temp), writes a helper PowerShell script named UpgradeAutomoxAgent.ps1 alongside it, and registers a one-shot Windows scheduled task named "Upgrade Automox Agent" that fires 15 seconds later under NT AUTHORITY\SYSTEM at highest privilege. The scheduled task stops the amagent service, runs msiexec.exe with /I, the MSI path, ACCESSKEY=<value>, and /quiet, then starts or restarts amagent and cleans up the installer, helper script, and the task itself.

Decoupling the install from the Worklet itself matters because amagent is the process that executes Worklets. If the agent ran the MSI synchronously, it would terminate its own parent process mid-upgrade. The scheduled task hands the upgrade off to a separate SYSTEM context and writes a Start-Transcript log to $env:TEMP\AutomoxUpgradeLog.log so the run is auditable after the agent restarts under the new version.

Why update stalled Automox agents at fleet scale

Outdated agents are a silent failure mode. An endpoint with an old amagent build still appears in the Automox console, still reports a hostname, and still looks healthy on the device list, but it cannot consume newer Worklet syntax, cannot honor recent policy parameters, and can quietly miss patch windows that other endpoints complete on time. Agents stuck below version 1.0.40 are the worst case, because that release predates the self-update path – those endpoints will not move forward without an explicit push from a Worklet like this one.

The Automox agent is the one component that makes every other Worklet possible, and stale agents are how patch policies silently stop reporting on the Windows endpoints that need them most. This Worklet queries the Automox console for the current GA release, compares it to amagent.exe on each endpoint, and runs the signed installer to bring outdated builds forward. Once the agent is current, the rest of your patch catalog runs against a fleet that actually reports back.

How the Automox agent update works

1. Evaluation phase: The evaluation script calls https://console.automox.com/api/info with Invoke-RestMethod to retrieve the current GA agent_version, falling back to a TLS 1.0/1.1/1.2 protocol list if the first request fails. It then walks HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\* for the entry where DisplayName equals "Automox Agent" and reads DisplayVersion as the installed agent version. Test-NetConnection runs against api.automox.com, console.automox.com, and rtt.automox.com on TCP 443 to confirm the endpoint can reach the URLs needed for the upgrade. The endpoint is flagged non-compliant (Exit 2) only when the installed version is below the API-reported GA version, the agent is 1.0.40 or newer (older agents exit 0 and must be reinstalled manually), and all three mandatory hosts are reachable.

2. Remediation phase: The remediation script repeats the evaluation checks, then instantiates a System.Net.WebClient and calls Downloadfile to pull https://console.automox.com/installers/Automox_Installer-latest.msi into $env:TEMP. It writes UpgradeAutomoxAgent.ps1 alongside the MSI containing a Start-Transcript log target, a Stop-Service amagent block, a Start-Process msiexec.exe call with the argument list /I, the MSI path, ACCESSKEY=$accessKey, /quiet (-Wait -PassThru so the script blocks until exit), conditional Start-Service or Restart-Service logic for amagent, and an agentCleanup function that removes the MSI, the helper script, and the scheduled task. Register-ScheduledTask creates the "Upgrade Automox Agent" task with a single trigger 15 seconds out, running PowerShell.exe with -ExecutionPolicy Bypass -NoProfile -NonInteractive -NoLogo -command, as NT AUTHORITY\SYSTEM at highest privilege. The Worklet then exits so the agent can finish reporting before the task fires and the upgrade replaces the amagent binaries underneath it.

Automox agent update requirements

• Windows 10, Windows 11, Windows Server 2016, Windows Server 2019, or Windows Server 2022 (older Windows builds are out of support for the current agent installer)

• PowerShell 5.1 or later, which ships in-box on every supported Windows release

• Automox agent version 1.0.40 or later already installed; endpoints below that floor must be reinstalled manually from the console

• Outbound HTTPS (TCP 443) to api.automox.com, console.automox.com, and rtt.automox.com from the endpoint or its proxy

• Automox Access Key stored as a Shared Secret named accessKey on the Worklet so the MSI can re-register the endpoint without exposing the key in script text

• At least 100 MB of free space in C:\Windows\Temp to hold the installer MSI, the helper PowerShell script, and the upgrade log

• Local Administrator or SYSTEM rights for the Automox agent (the default agent service account already meets this)

Expected state after the agent update

Within a few minutes of the Worklet completing, the scheduled task runs msiexec.exe, the MSI replaces the amagent binaries in C:\Program Files (x86)\Automox, and the Automox agent service starts or restarts under the new version. The endpoint reconnects to api.automox.com and reports the new agent version in the console device record. The Start-Transcript log at $env:TEMP\AutomoxUpgradeLog.log captures every step of the upgrade run, including the msiexec invocation and the service state changes. The temporary installer MSI, the helper PowerShell script, and the scheduled task definition are removed by the agentCleanup function after the install path completes.

Validate by re-running the evaluation script and confirming it returns compliant with the new version recorded in HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall. You can also run Get-Service amagent to confirm the service is in the Running state and Get-Item "C:\Program Files (x86)\Automox\amagent.exe" | Select-Object VersionInfo to inspect the on-disk binary version. Endpoint configuration, organization ID, and any policy assignments persist through the in-place upgrade because the MSI is run with the original ACCESSKEY rather than as a fresh install.