@ZiggyStardust32 

Your opinion is unfortunate in that support provided you what they knew without having any details other than the cursory question(s).

The answer is, it could be any number of ways the agent was shut down and/or protection suspended and the request, which you did not provide, was to submit more details like operating system and logs which would help anyone diagnosing an issue to have more data. Troubleshooting 101.

With that said, I will attempt to answer your question as best possible without any details or logs since you do not appear to want to help with the diagnosis.

ONE: Agent protection suspended.

> If “Allow protection shutdown” is enabled in the policy (which is not recommended) and the user can select that as an option, it will shut down protection. Case closed. That’s a policy management issue that is highly unusual and provides too much leeway with the end user.

NOTE: In rare cases, the system tray icon, which I’m assuming you meant as I’m not aware of any “clock icon” we support, may not be itself stopped as it’s a separate mini-application and it has been known to keep running. If it’s running and the agent and/or service are not operating, it simply reports what it sees. “Protection Disabled”.

> The agent in question was installed as a consumer level product, which gives the local user carte blanc access to every possible area of the agent and is not fully managed by a central console.

> Another possible way the agent could have been shutdown, partially, is that “Self Protection” is set to minimum and the user, possibly savvy enough to know, opens the service manager and stops the service. Self protection set to minimum gives local admin the opportunity to stop services, including the Webroot agent.

> Another possibility is a malicious actor compromised your network, obtained elevated privileges and stopped the PID. (Rare, but has happened with RDP compromised networks.)

> Another security tool on the endpoints detected the agent and either removed it, unlikely if you say you can restart it, and/or the other security tool simply partially shut it down.

Again, any one of the scenarios above could be the culprit, but without any details or logs from the endpoint in question, it could be a myriad of reasons, so without that information that you didn’t supply, it’s a “best guess” until that information is provided.

TWO: Why isn’t the agent reporting disabled in the console.

Because our system is a SaaS model service whereby the agent does not talk directly to your specific admin console, it’s not a bi-directional communication model. The Console or any service we have running centrally CAN NOT reach out and “ping” or check the status of an agent or detect its heartbeat. 

The agent therefore has to “call home” periodically to let the console know it’s alive and well. If the polling setting is “daily” then it calls home every 24 hours, which is why we recommend lowering that setting. When it does call home, it does not call your console. It communicates with a central server farm whereby that middleware service captures details about the console it’s assigned and once the agent does all it’s maintenance, determinations and other activities, that middleware service then updates your console as to it’s activities usually within a few seconds or minutes.

Lastly, instead of building a tool to check heartbeat, which could be shutdown and would be another tool to maintain security and set as a policy, we rely on our RMM Partners to detect heartbeat more efficiently. Every RMM we integrate has such a mechanism and it’s extremely reliable.

Outside of an RMM tool we suggest using more appropriate network monitoring tools for this an many other solutions within your management purview. So rather than reinvent wheels that already exist, we chose to expect network administrators to establish their own tools locally on their networks.

Regards,

Thank you. So why, after asking support the same question twice, couldn’t they answer it like you did? What was so hard about that? For the record I responded that it was a Windows 10 endpoint. I was not asked for any logs.

@ZiggyStardust32 - i can’t speak for all support techs, but, it’s usually around experience. I’ve been with Webroot for many years and have fielded just about every question imaginable.

That said, fair enough, you’re actually correct. I glanced at the ticket thread quickly and saw a link which usually references the log generator, which it did not. My ineptness and too quick during reviewing.

To affectively diagnose, a log request should have been made, especially with an oddity like this where if it was shut down and in an odd state. The agent may have included a log entry with a code or something to provide a clue.

If you’re open to it, you could also run the log gatherer through the console. It’s under Agent Commands - Run Support Diagnostics (Something like that). The agent, if running, will gather it’s log and lots of other pertinent information, like sys events, app events etc… and send it to a backend secure server where anyone in support or myself could review and see if there’s an “ahah” clue.

I found the solution and it was flawless! I just uninstalled Webroot from all 300 of my endpoints. For the first time in years things are running really, really good. Should have done it a year or so ago!