Monitoring of DNS agents
under review ( scoping )
Ramil Aninang
I have encountered issues where DNS agent are not working even if it has started successfully on windows services. I have to manually stop and start the service to make it work. I hope there will be a function where we can monitor the last sync activity of the users or the status of the DNS agent connection on the portal for us to have a heads-up information on which agent fails to load up and for immediate troubleshooting.
Scott Thomson
Putting this here since it seems to make sense: your API is what 'tells' agents that an update is available - if an agent queries API, gets update-avail = TRUE - and then you don't see a check in... Please raise an alert. It 'could' be a device that legit went to sleep or offline at the same time, but in our experience that is so rare as to be a non-issue.
We've found plenty of agents that failed open with the latest code (v1.11->1.12) where we either had to manually start the service (and then it was OK, had 1.12 code) or something faulted and the service no longer starts; typically resolvable with uninstall/re-install (which REALLY should not be happening, but I don't see how you get around this unless you redo your self-update to split it into an isolated process)
Steve Staden
under review ( scoping )
Moving this item to Under Review. Just wanted to update for transparency to voters.
James
We are still fairly new to DNSfilter, how are you finding out that you have these issues? We have datto rmm which I built a policy with powershell to install on the device if the service isn't running.. I haven't heard of any issues with users but also not really sure how to tell if we have one
Steve Staden
planned ( in queue )
Tom Himes
Same issue here and we were on 1.8.2. The only fix from support was to run a powershell job they provided to uninstall/reinstall. Not a great fix for a large organization.
Matt Ellsworth
We see this as well periodically. We also have lots of agents that stop auto updating.
Madanraj
Same issue encountered by us and chat support asked us to upgrade the windows agent to 1.8.2 but the issue still persist of the agent stops working intermittently(3 tickets opened in the past for same issue). This is beating the purpose of having Roaming client agent available all the time to protect the endpoint. Even when the agent is down all the DNS request should always go through 127.0.0.2 irrespective of the agent availability so that we come to know of the agent not running but it is switching to router assigned DNS servers when the agent is down. Not cool since the product engineering should cover these scenarios and remediate it since leaving a risk unattended in cybersecurity is dangerous.
Steve Staden
This isn't related to the feature request itself, but to the issues mentioned in the request. We encourage updating to the latest Windows roaming client version (1.8.2) if you are on an older version and experiencing issues. We have made many improvements that customers have provided positive feedback on - https://dnsfilter.canny.io/changelog/windows-roaming-client-182-auto-update-scheduled-for-monday-1024. If you're still having issues on the latest version, please submit a support ticket so we can further troubleshoot. We are focused on improving the experience and working through all issues that are being reported. Thank you for your help.
James
Steve Staden: this problem still occurs with 1.8.2
James
As a DNS MSP Partner we also experience this problem across the estate of computers we manage and monitor. It has been getting significantly worse of late.
Ben
We're also running into the issue where the windows roaming client stops filtering randomly and we have to restart it to get it working again. This has been a major issue
Load More
→