Hey Nic,

Is this new update going to allow for group configuration directly on the MSI?

Unfortunately that one didn’t make it in to this release.

Darn,


Is there anything we can do to potentially get it into this release, we have a huge bug that happens when the dergegister command is issued for group enrollment, I feel this is critical enough to justify an expedited update?

Hi @scriptpirate, could you please clarify your issue?

I know that there was a bug fix that went out for what sounds like the issue you are having. When was the last time you tested the deregister command?

This bug has been fixed, with the deregister command, so you can resume automating moving devices from one org to another.

Hi Jarod,


When deploying the MSI package, it does not accept inline variable for group assignment. This causes us to have to deploy the MSI, then run a PowerShell script to deregister, and re-register the agent to the correct group right after installation.

@Nic - Would you mind expanding a little on “Stuck agent resolution improvements”. Agent stability/recovery has been a big concern of ours over the last several months and probably the weakest link in the product at this time. We’ve been eagerly await updates to the agent as a result.

Hey Chris,


What stability/recovery issues have you seen? We are about to flip the switch on 3000 devices to active patching from read-only with the agent running. You struck my curiosity now.

Hey Chris! The key change for the agent is command timeouts, so commands that get hung (which we’ve seen related to certain packages that try to prompt a user or access something it cannot, primarily via custom Worklets) won’t block the agent indefinitely. We’ve also hardened up connection error handling by the agent. Additionally, we have implemented a number of backend fixes over the recent months that to make command communication more reliable, including confirming agent receipt and active retries if a device seems to have not refreshed on time.

@jarod.smilkstein Thanks! I appreciate the additional color.

@scriptpirate - It’s not a problem unique to Automox but platforms which require an agent live and die by the Agent. In a few cases we’ve had stuck commands or communication issues which would require the service to be restarted. Not a big deal but it requires a touch point on the device. For on-net workstations no problem since we have line of sight to the device but anything off-net requires some additional work. We leverage MS Intune for MDM so one solution we’ve found is to send a PowerShell command through Intune to restart these services.

My biggest concern has always been my inability to trust the “Disconnected” status for any agent based platform. Is it really offline or has the agent simply stopped communicating properly. I’m not sure how to solve for that, and like I said it’s not unique to Automox but since this platform is critical to our security posture it becomes more relevant than some other agent based systems we leverage.

Just wondering … is there a cut off date for earlier clients? More than half of the devices I look after have not been turned on for three months. Most of these are on 1.0-28.

Clearly there is a lot of updating required when our people get back to work and it would be most inconvenient if this didn’t happen because the client was too old.

There isn’t a cutoff - any old agent should auto-update to the latest version when we make it available to all installed devices. You’re on the current agent version so they’ll have no problem updating when they’re online.

More info on the proxy configuration changes, for those that are interested in that change:

If the proxy is set, an attempt is made to use it. If it is unreachable, the next proxy is checked.

The order of proxy evaluation by Automox is as follows:

1. 
   
   

   AUTOMOX_PROXY/automox_proxy

   
   
   



2. 
   
   

   HTTPS_PROXY/https_proxy

   
   
   



3. 
   
   

   HTTP_PROXY/http_proxy

   
   
   



4. 
   
   

   Windows Only: IE Proxy (Dynamic via PAC file)

   
   
   



5. 
   
   

   Windows Only: IE Proxy (Static)

   
   
   



6. 
   
   

   Direct

   
   
   

NOTE: The agent runs as a local system. The proxy settings must be configured at the system level, not the user level.

Ok version 29 is now live for new installs. Upgrades to existing installs will go out next week on Tuesday the 16th.

Here’s the updated documentation on the proxy configuration with Agent 29:


https://support.automox.com/help/using-the-automox-agent-with-a-proxy-server

A quick reminder that upgrades for existing installs are going live today. If you need that update deferred for your company for any reason please contact support@automox.com.

Is there any type of report we can run post update to ensure all clients are up-to-date?

Nothing on the console, but via api something like

curl 'https://console.automox.com/api/servers?o=<orgid>&api_key=<apikey>' | jq .[].agent_version