Agent Is Installed and Running but the Device Never Appears in the Automox Console (Intune and Silent Deployments)

Issue

The Automox agent is installed and the agent service is running on a device, but the device never appears in the Automox console. This commonly affects many devices at once after a silent or mass deployment — for example, a Microsoft Intune Line-of-Business (LOB) app or a deployment script — and uninstalling and reinstalling the agent by hand makes the device appear, which suggests the software itself is fine.

In some cases, devices that previously appeared in the console all disappear at once, even though the agent is still installed and running locally on every device.

Environment

• Automox (current agent release)
• Windows and macOS
• Agent deployed via Microsoft Intune (LOB app or script) or another silent mass-deployment method
• Automox console: Devices, Settings > Keys

Overview

Installing the agent and registering it with your Automox organization are two separate steps. Registration requires your organization's Access Key; the installer applies it when the key is passed correctly at install time. If the key is missing or malformed, the installation still completes and the agent service starts and runs normally — but the agent has no credential, so it never authenticates to the platform, never checks in, and the device is never created in the console.

This is why a manual uninstall/reinstall "fixes" a single device (the interactive install applies the key correctly), while every device deployed with the broken package stays invisible.

The two common ways deployments end up in this state:

1. The Access Key was never applied. The silent install command line omits the key parameter, or the command line is malformed so the parameter is dropped. Common with Intune LOB apps where the install string is configured separately from the MSI.
2. The deployment script deregisters the agent. The --deregister command removes the local access key. If a deployment or "reconfiguration" script calls --deregister and does not set the key again afterward, every run of that script knocks the device out of the console — a script that Intune re-runs periodically can silently remove an entire previously healthy fleet this way.

Resolution

Step 1: Confirm the agent is running but unregistered

1. Confirm the agent service is running (Windows: amagent in services.msc; macOS: the Automox agent LaunchDaemon).
2. Check the agent log for a missing-key error:
   • Windows: C:\ProgramData\amagent\amagent.log
   • macOS: /var/log/amagent.log

3. Search the log for the string access key is missing or invalid. On Windows, from an administrative PowerShell prompt:

   (Select-String -Path "C:\ProgramData\amagent\amagent.log" -Pattern "access key is missing or invalid" -CaseSensitive:$false | Select-Object -Last 1).Line

4. In the Automox console, search Devices for the hostname. If the log shows the missing-key error and no matching device exists in the console, the agent is installed but unregistered — continue below.

If the log instead shows the agent checking in successfully, the device may be appearing under a different name or merged with another device's identity; see My Device Is Missing from the Automox Console (https://help.automox.com/hc/en-us/articles/45771776369684) instead.

Step 2: Register the existing installation in place — do not reinstall

There is no need to uninstall and reinstall across the fleet. Set the Access Key on the already-installed agent and restart the service. Retrieve your organization's Access Key from Settings > Keys in the Automox console (Access Keys are organization-specific).

Windows (administrative PowerShell — deployable at scale as an Intune script or remediation):

net stop amagent
& "C:\Program Files (x86)\Automox\amagent.exe" --setkey YOUR_ACCESS_KEY
net start amagent

macOS (as root):

sudo /usr/local/bin/amagent --setkey YOUR_ACCESS_KEY
sudo launchctl unload /Library/LaunchDaemons/com.automox.agent.plist
sudo launchctl load /Library/LaunchDaemons/com.automox.agent.plist

Within a few minutes of the service restart, the device should check in and appear in Devices. Validate on one device before rolling the fix out to the rest.

Step 3: Fix the deployment package so future installs register

1. Verify the install command passes the Access Key. For the Windows MSI, the key is supplied as an installer property on the command line, for example:

   msiexec /i Automox_Installer.msi /qn ACCESSKEY=YOUR_ACCESS_KEY

   In an Intune LOB app, confirm the key parameter is present and correctly quoted in the app's install command field. See Silent Agent Deployment on Windows for the full, current command-line syntax, and Embedding Your Access Key into the Automox MSI for key-embedded packaging that avoids the parameter entirely.

2. Audit deployment scripts for --deregister. If a script calls amagent --deregister (for example, as part of a "reconfigure" flow), every execution removes the device's registration. Either remove the deregister step, or ensure the script always sets the Access Key again (--setkey) and restarts the agent afterward. Remember that Intune can re-run scripts on a schedule — a script that is safe once can still deregister the fleet over time.

Notes

• Uninstalling via Intune: if a device does need to be removed, deregister the agent before uninstalling. An MSI uninstall pushed through Intune without a prior --deregister can leave the device record behind in the console. A small script step (deregister, then uninstall) handles this cleanly; see When an agent is deregistered, will the device be removed from the console immediately? (https://help.automox.com/hc/en-us/articles/12780817020052).
• Access Keys are per-organization (and per-zone where zones are in use). Confirm the key in the deployment package belongs to the organization the devices should appear in — a valid key for the wrong organization registers devices into a console you may not be looking at.
• If the log shows no missing-key error and no successful check-in, verify outbound HTTPS (port 443) connectivity from the device, including any proxy configuration.