Stop Billing for Unresponsive Agents
under review
P
Phill Wade
It would be extremely helpful if agents that remain unresponsive for a certain period could automatically transition into a non-billable state. We’ve noticed that in co-managed environments where customers handle their own device refresh cycles - devices are sometimes wiped and shelved when a user leaves, but the Huntress agent isn’t uninstalled. This results in continued billing for inactive devices.
Ideally, if an agent remains unresponsive beyond a defined threshold, it would be marked as non-billable. Should the device come back online or re-register, billing and protection could automatically resume.
S
Stevie'la Ullrich'la
Ideally stop billing after x days AND an option to reactive a device that checks in after the inactive period instead of uninstalling, with notification email so we can decide
S
Steven Richardson
Just working through issues caused from the uninstall option the last few days.
It appears the uninstall doesn't work as expected, and we just end up with devices with huntress installed but services stopped creating additional engineering work as our RMM alerts based on stopped services. Restarting the services doesn't cause the device to check back into the huntress console so the only solution appears to be uninstall/reinstall or potentially one of the reinstall options with re-register or something.
We do need a way to manage stale devices AND to not bill for stale devices- but sending an uninstall command as a response doesn't make much sense to me.
Examples of how other vendors manage similar scenarios:
Sophos - Device remains in the console, if it does not connect to sophos central during the month, then it does not count toward billing.
Datto RMM - Ability to simply delete a device from the console (upon deletion it stops counting toward billing) but the software is not uninstalled. If the device comes back online it checks back into the console, updates and carries on (and billing resumes)
I think there is an idea option between the above two examples:
-Show stale devices clearly in a group or filter in the console so that we can clean then up from time to time (or automate cleanup based on defined criteria)
-Do not bill for a device that has not connected during the monthly billing period
Russ Bashaw - Huntress
marked this post as
under review
Thanks for the feedback everyone. We're reviewing this now.
J
Jared Roy
This is in place?
By default, after 21 days, an agent foes unresponsive, after 7 more days of non responsiveness, the agent is uninstalled. You can adjust this setting by clicking the hamburger and clicking settings.
You can set "Days until unresponsive". 21 is the shortest.
and "Unresponsive Limit", which is the number of days of unresponsiveness before an action is take. You can set 0 days, or 1/2/3 weeks.
Finally, you can set an unresponsive action, to do nothing, or uninstall agent.
If you select 21 for day until unresponsive, and set a limit of 0 days, anything that does not respond for 21 days is uninstalled.
Keep in mind, if the uninstall dips below your minimum commit, you will still be billed. but if you have a 500 commit, and 700 agents, and 20 get uninstalled this way, you will stop being billed for those 20.
Edit: I understand now. You want the agent to stop billing, but stay installed, so you do not need to rely on something to reinstall the agent.
Unfortunatley, I agree with Scott, that this is not so much a huntress issue as a process issue. We use GPO, Intune, and RMM to keep things isntalled, and often times are overbilled on RMM. This would be nice, but i think it would be a lot on hutnress to keep potentially hundreds of thousands of agents on standby in the off chance they come back online after a month.
S
Scott Brandt
This would be very helpful. I believe we've found that if a computer has been offline for long enough to be deprovisioned in the Huntress portal, once it comes back online, the Huntress agent checks in, discovers it's been auto-deprovisioned from the Huntress console, and then uninstalls itself. It would be better if it just auto-reactivated itself and billing resumed.
J
Jordy Minnebo
Scott Brandt
Have compliance policies in place in either rmm or intune. If huntress is missing for a huntress enabled customer, (re)deploy huntress.
This is a non huntress issue imo. 21 days offline removes a device from the huntress console and stops the billing. Worst thing that can happen is that you pay an additional month for this agent if it overlaps.
How do your currently track devices that are put on a shelf by your comanaged client?
do you stop the billing too? If you stop the biling didn't the client let you know that they deprovisioned a device? If they don't communicate, your rmm will be billed too..
Just my take away.
S
Scott Brandt
Jordy Minnebo, We use our RMM agents to do exactly this. Had to build a process to check the status of Huntress every day on each system that should have it, and redeploy if it's missing. Would be nice to not have to do that. In my opinion, this is not a major issue, just a nice to have, assuming you also have an RMM or Intune that can auto push the agent if missing.
Re: clients that take PCs out of service without telling us, we bill most clients per supported user so they don't have a lot of incentive to tell us about PCs changes unless we ask them occasionally about offline systems.
A
Adam Kemp
Scott Brandt I understand the other users' point, but I agree with you. The majority of my clients have MDM or RMM so I can redeploy, but I am also targeting smaller clients who do not have these facilities in an effort to at least get their security up to a similar level of clients with full stacks.
With my incumbent security agent, after x days of no comms it will remove the endpoint from the portal. If that endpoint comes online again, it is added back. The only time I can see this as not beneficial is if an uninstall is triggered manually on an endpoint rather than by the auto settings.
My proposal is that there be an additional option on the action dropdown for unresponsive agents where device is removed from the portal (and billing ceases). This way we all have the choice whether to uninstall the agent, or suspend it.