Remote Uninstall for Windows Roaming Client
next (developing in <60 days)
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.
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
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
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?
Jubaire
This would be very useful. If not done through the GUI, can you compile a msi or an approved Powershell script that we can run similar to what Scott posted below?
Zohaib Khan
Would like this ability available for Mac roaming clients as well.
Scott
$prog = "DNSFilter"
$app = Get-WmiObject -Class Win32_Product | Where-Object { $_.Name -match $prog }
if($app -ne $null)
{
$app.Uninstall()
}
else {
Write-Host "Could not find program $prog"
}
stephen
this would be excellent -for all platforms
Load More
→