Hey @SteveM !
I see that in your support ticket we were able to get a call scheduled for today to assist with this issue.
Let’s continue to use that medium for tracking the issue.
Thanks!
@SteveM Did you find a resolution for this ?
We are experiencing the same issue. Is there an official answer on this that can be shared with the community?
I pretty much discontinued with the case, didn’t find a resolution and the impact appears to be minimal. When the time allows, I’ll check the agent logs again and see if this issue is still there or not.
Checked my device and still seeing this error. Most recent one is below.
Is this the exact message you’re seeing ?
time=2025-05-07T22:41:00.831+01:00 level=ERROR msg=ErrorEvent error="refresh error: failed to authenticate: failed to reach server: Post \"https://rtt.automox.com/rtt/authenticate\": dial tcp: lookup rtt.automox.com: no such host"
Checked my device and still seeing this error. Most recent one is below.
Is this the exact message you’re seeing ?
time=2025-05-07T22:41:00.831+01:00 level=ERROR msg=ErrorEvent error="refresh error: failed to authenticate: failed to reach server: Post \"https://rtt.automox.com/rtt/authenticate\": dial tcp: lookup rtt.automox.com: no such host"
Hey @sukh.r and @treybo !
Typically we see these types of symptoms when the required Automox endpoints are not allow listed or the required routing is not configured for your firewall, VPN, or network appliances.
https://docs.automox.com/product/Product_Documentation/Agents/Agent_Requirements/Agent_Firewall_Allowlisting_Rules.htm
Additionally, endpoint-protection and antivirus software may be blocking connectivity or causing agent service disruptions, so it’s worth ensuring that the required files and folder locations for the agent are not being blocked.
That said, since these configurations are largely environmental we do recommend triaging things further with our Support team if you continue to encounter issues: https://help.automox.com/
@sukh.r and @treybo - we never fully resolved it or could figure out exactly what the issue was. We have a mix of remote (who only need the VPN for protected resources) and on-site users and it was happening to both types. Outbound traffic is allowed by default, so we did not have any evidence it was the firewall.
Our solution, which was worked pretty well was to do the following:
Deploy 2 scheduled tasks from Automox that run in the morning and in the afternoon that runs the following command: taskkill /f /fi "SERVICES eq amagent" ; Start-Sleep -s 5 ; net start amagent
That command gets the agents back online and connected to the console again.
There are times where the agent connectivity drops in between the scheduled tasks and you may not be able to afford to wait for them to come back up. In that scenario, we use our SentinelOne’s remote shell feature to backdoor into the asset and run the same command as above.
It is frustrating and I have provided my feedback to Automox. However, their support appeared to have tried everything they could to find a fix (short of completely solving it). It is for sure still happening, but the impact is now minimal due to those tasks.
Thanks for the info @SteveM.
@JohnG-Automox we also see that we need to continuously restart the service in order for Automox to work correctly. We hate the idea of doing it on every machine everyday as it appears to only affect about 1/3 of our fleet at a time.
The instructions you have provided we have shared and verified are whitelisted many times now. Is there a solution being built into the product to detect connectivity issues and restart the Automox services as necessary. Better yet, they just wouldn't fail.
