Remote Uninstall for Windows Roaming Client
next (developing in <60 days)
Josh Lamb
Would like the ability to initiate an uninstall of the Windows roaming client from the DNSFilter dashboard.
Carl Levine
Hey all, this functionality is ready to be tested. I wanted to extend the invitation to this group to see if there's anyone interested in helping out. Email [email protected] or respond to this thread and we can get you set up with the feature flag on your account and the alpha release of the next version of the RC. Confirmations will be sent on 10/31 and testing will likely begin on/after November 5th.
Dave Kuhns
We would like to test this function
B
Barbara Webb
yes please add me to the feature release
Carl Levine
Hey all, this functionality is ready to be tested. I wanted to extend the invitation to this group to see if there's anyone interested in helping out. Email [email protected] or respond to this thread and we can get you set up with the feature flag on your account and the alpha release of the next version of the RC. Confirmations will be sent on 10/31 and testing will likely begin on/after November 5th.
Jeremy Rodriguez
Carl Levine Im in. Let me know what we need to do.
Andrew
Carl Levine we would like to test as well.
Chris Dewey
Carl Levine Im in for this. Please reach out to me
Carl Levine
Hey all, I wanted to take a moment and keep you apprised of our progress on this feature request. We have engineered the requisite API methods that will allow the dashboard to remotely uninstall the Windows RC. We are working on the UI (front end) enhancements to support this functionality, and there will be a version bump of the RC to accommodate this functionality. One of the cool things we were able to do while we were in the code base was to get protection for situations where endpoint users with Local Administrator permissions will be presented with a prompt for a passcode to uninstall the agent. This functionality will all be coming this quarter, and I think I speak for all of us here at DNSFilter that we appreciate your patience. Our goal in Q4 is to make the endpoint experience better than ever!
Carl Levine
Merged in a post:
Remote Lock shutdown/uninstall of client
MICHAEL MADL
To ensure that we can enforce policy and not have anyone work around the agent it is critical that we have the ability to remotely lock the ability [or unlock] to turn off and/or uninstall the DNSFilter agent for both MAC and WINDOWS.
John
As a reminder as this is built out, I think the agent behavior needs to change. Today - if we delete an agent from the portal while the machine is offline we can end up in a scenario where that machine ends up getting turned back on and has no internet because of having no DNS.
If the agent is on a machine, connects to the portal and discovers that it's been deleted from the portal it needs to uninstall.
If instead it's going to wake up, connect to the portal (potentially via broken DNS because it's been already deleted from the portal) and then not be able to see that the uninstall command has been queued this change is pointless.
Online Agent told to uninstall = agent uninstalls
Agent phones home and doesn't exist in the tenant = agent uninstalls
Carl Levine
John: Couldn't agree more! This is one of the scenarios that was posed in a planning meeting yesterday, and it's driving some pointed discussion about the approaches we'd take when an agent is called for uninstallation but isn't "phoning home". The logic for the "Activity in the last 15 minutes" status is API driven, so our approach will likely require adding a new state and doing exactly what you've suggested here. Alas, as the PM, I am the "what" and "why", with enough "how" to be dangerous. Watch this space, we're really excited to be delivering new value in this arena.
Deon
Carl Levine Keep in mind I can always understand the argument for the fail-closed that DNS Filter currently does because it offers the most protection.
However, I think it should be, at least, an option to allow for fail-open/uninstall as the people utilising that will more than likely have something like an RMM or MDM swooping in to replace the agent if the computer is still active, but for some reason wasn't checking in with DNS Filter.
Carl Levine
Deon: Watch this space, that's in the works as well.
Carl Levine
next (developing in <60 days)
John
As the oldest comment on this request -- from 2011... WHY has this not been prioritized by now?
David
This is a critical issue for us. The lack of this feature has started a search for other options that won't black-hole a workstation if it wasn't turned on in time for an uninstall job.
If an org is offboarded, we are expected to remove our RMM agent and other softwares by a specific date, but in many cases the expectation is to continue delivering services (including DNS filtering) up until that date.
Depending on an RMM-delivered offboarding script for DNSFilter (which depends on the RMM agent being present) causes a process issue. In larger orgs you are going to have a number of user-endpoints that are not turned on during an exit window. Typically, when removing an RMM agent, pending jobs are NOT executed when a system comes back online. The agent is simply uninstalled.
The DNSFilter RMM Agent automations are excellent for mass onboardings, but not exiting a client.
If this uninstall functionality isn't possible, the roaming agent should at LEAST deactivate filtering and pull DHCP provided DNS if it determines that the organization it was attached to has been deleted. The notification area icon could be made to indicate this mode.
Scott Thomson
Would love to see some someone inside comment on this request; when we recently spoke I forgot just how old this is - any ack of just how painful and pointless the current behavior is, especially for MSPs managing agents at scale?
Nick Saunders
Scott Thomson: Hi Scott, appreciate the feedback. We do have this feature on the consideration list for next RC enhancements - we've generally found that MSPs with large deployment are already using RMMs or other automations for deployments and offboarding of machines where they're able to leverage commands such as those in our help docs to uninstall the RC. But I absolutely understand the value in making things more intuitive from the Dashboard.
Scott Thomson
Nick Saunders You show me an example of a similar product that dead ends like the agent does on portal-delete, and I'll drop this. Every other MSP tool we use that has sane/justifiable behaviors to manage agents - simply halting dns resolution until the device reboots or service restarts is... doing what exactly?
What compelling reason do you have NOT to manage/queue the uninstall in your system? Every other tool we use can queue the uninstalls - so if devices are offline, they get that when next online - and we don't have to shepard it and plan weeks ahead for customer offboards.
Find just one example in industry that behaves as your agent currently does, and I'll stop pestering you about this. As it is, this is one of hte highest voted and oldest requests, and the impression is that you really don't have any idea how similar tooling behaves. See also - fragile and unreliable self-update mechanism.
Nick Saunders
Scott Thomson: I believe the behavior came from a security-minded perspective that browsing without a filter enabled (no policy enforced) was insecure but I know that's not going to be the right call for all businesses. We're actually looking to allow that behavior to be configurable so you choose the right approach for your users. We'd love to work on everything but as you can see we have lots of ideas and feedback to consider.
Scott Thomson
Nick Saunders That's my point - if you think this is secure; what security is being provided when the agent re-activates upon system or service restart? It doesn't even achieve the implied goal of 'killing' internet. If Huntress's host-isolation reverted on system restart, do you think their product would even be sellable?
Nick Saunders
Scott Thomson: The way it behaves is if the agent is able to reactivate it's because it has an applied policy and is filtering traffic as before. You'll see it reappear in the Dashboard.
Scott Thomson
Nick Saunders we are talking past each other at this point - have Nick H or Josh relay my email & descriptions of uninstall mgmt for 3 other agent-based solutions. I truly do not understand why you think it is acceptable that we have to mop up your code with another tool. Like, your self-update still fails open an easy 10-20% of the time, so how secure is that?
Nick Saunders
Scott Thomson: Absolutely, happy to follow up for those details and I 100% get the frustration and agree our current behavior is not very polished. Appreciate your patience and interest in chatting through things with us.
Jack Taugher
Scott Thomson "You show me an example of a similar product that dead ends like the agent does on portal-delete, and I'll drop this."
Huntress uninstalls remotely from the Dashboard.
In less than 90-days, this will be nearly a 3-year request.
Jack Taugher
Scott Thomson "You show me an example of a similar product that dead ends like the agent does on portal-delete, and I'll drop this."
Huntress uninstalls remotely from the Dashboard. I can pick and choose agents and have it uninstall per-agent.
In less than 90-days, this will be nearly a 3-year request. And gosh, dark mode is on the next RC.
Deon
Nick Saunders and when a mass uninstall via RMM fails, because the WMIC command you provide us with is deprecated and unreliable/slow at best, what then? DNS Filter is by far the most irritating tool in our entire stack to offboard/clean up correctly.
If the RC previously had a config, and the next time it checks in it determines that the organisation it was associated with
no longer exists
as would be the case for MSP offboarding, it should remove itself rather than fail closed. We're somewhat tired of having to pay for agents because there is no other option outside of pissing off a client that is offboarding - not the best look.If you're going to lean on the RMM tool thing, consider that automatically removing agents shouldn't be a problem because the MSP will have the RMM tool (or MDM) configured to automatically reinstall the appropriate agent if it detects it is missing.
Why not just have this as an "Opt-In" at the MSP, Organisation and maybe Policy level?
Load More
→