@ZiggyStardust32   Sorry that you’ve had this experience with the Webroot agent. I’ll try and offer some options and/or direction for future reference.

1. The GSM can’t contact the endpoint. Commands expire.
   - The WR Admin console can not reach out to agents directly to function due to network routing challenges. So, the architecture is dependent on the agent calling home for instruction. This is managed in your policy. If the policy polling is set to “daily”, then it’s once a day that it will possibly have a chance to run the command. The agent commands do have a shelf life so as to NOT clog up these middleware server farms, so if the agent does not check often, it can and will expire before the agent can do what’s been asked.
2. The endpoint can’t contact the GSM so you can’t uninstall it because it things it is managed.
   - The agent is locked down on purpose to minimize local uninstall and if the policy was established to keep users from uninstalling, then it’s simply doing it’s job under “self protection” mode. This is by design. A suggestion may be to change the policy to “Unmanaged”, which gives the end user full access to make changes.
3. Excludes aren’t excluded.
   - There could be a variety of reasons why overrides are not being respected, the most common are malformed entries that simply do not work or the agent can’t understand. Support could offer suggestions for correcting this situation. Review the “best practice” guide for an effective approach. (See below link.)
4. it won’t register as the the “on” virus in Security Center so both Windows Defender and Webroot are active.
   - Usually the agent does set this flag properly. If it’s problematic, give it a few days and a reboot. If it persists to be problematic, then contact support, they have options to help.
5. It won’t install or uninstall properly.
   - Depending on the version, there were some uninstall issues. However, the latest version, 9.0.27.x corrects these.
6. It is hit and miss if it puts itself in Add/Remove programs.
   - This is policy driven or related to whether the EXE or MSI installer was used. MSI installer will always put something in Add/Remove by MS spec/design, where as the EXE installer will not if using the default policy settings. However, you can instruct the MSI installer to NOT put anything in Add/Remove using a specific flag in your install script.
7. The latest update makes the WRSVC service fail to start because it is improperly digitally signed.
   - The service is properly and legally digitally signed, so this may be dependent on how you determined this situation. The core KEXT drivers and EXE are fully signed. The service account is a registration of the EXE in Program Files.
8. Endpoints show up in the wrong site
   - The agent simply registers it’s installation by key code instructed during installation process. RMM’s will set this or it can be set manually during installation or using a script. There is no way it can arbitrarily register itself to another site as this is encrypted and locked data never to be changed unless instructed by the administrator.
9. It thinks programs are harmful that are totally safe.       
   - The agent is agnostic in that it makes determinations in three ways. Good, bad or unknown. If the process its monitoring is unknown, then it’s dependent on behavior of the application. So, if the application “looks” like a bad actor, it takes steps to correct. This is all by design.

Note: Webroot’s agent is a NextGen EPP solution that has many shields and many ways in which it makes determinations. Managing these through policy and properly established overrides can greatly enhance its effectiveness and minimize frustration. My suggestion is to review our Best Practice guide for getting the most out of the console and agent.

Admin console Best Practices - https://download.webroot.com/WSAB_GSM_BestPracticesGuide.pdf

1. The policy polling is set to 15 min
2. Moving it to Unmanaged doesn’t do any good because it has lost contact with the GSM
3. You don’t quite understand how Webroot handles Excludes. It scan everything even if it is “Excluded” then looks at the Exclude AFTER it scans it do decide whether or not to ignore the results. What is it about the word “Exclude” that Webroot doesn’t understand?
4. You are saying the bottom line here is to contact support. Been there done that. Useless.
5. 9.0.27 might fix the uninstall error but add the problem with the WRSVC service not starting because of a digital signature error. Typical of Webroot. One step forward two steps back.
6. The policy is set to add it. It just doesn’t. This has been going on for over a year and Webroot refuses to address it.
7. See #5 above. This is a known issue with 9.0.27. Call support and reference ticket# 308239
8. Call support and reference ticket# 306966
9. I have reported the suspect program 12 times over the last two years and once again Webroot doesn’t do anything. Is ignoring things by design too? The need to listen to people who take the time to tell them that a false positive needs to be corrected.

My suggestion is to find another virus package. I don’t even want to think about the time I have in trying to get Webroot to work right. It needs to be “set it and forget it” and it isn’t even in the ballpark…..

@ZiggyStardust32 - again, my apologies for you’re experience. I am aware of the support teams responses now that you provided ticket information, thanks.

As a senior solution engineer and specifically working with various RMM platform partners, yours included, I’ve worked with many customers as yourself who have to deal with the nuances of our how agent works. It’s not perfect, but the efficacy for stopping malicious activity is first and foremost the focus.

1. The policy polling is set to 15 min
   - This is best practice suggestions, so that’s great.
2. Moving it to Unmanaged doesn’t do any good because it has lost contact with the GSM
   - The agent does not communicate directly with your specific admin console, rather it communicates directly with a series of back end server farms depending on the function. Policy assignment is not arbitrated through the same method as agent commands and if the agent key is set correctly, then policy assignment works separately and will be applied. To speed up that process, simply select the “Refresh configuration” in the system tray icon or use the -poll command.
3. You don’t quite understand how Webroot handles Excludes. It scan everything even if it is “Excluded” then looks at the Exclude AFTER it scans it do decide whether or not to ignore the results. What is it about the word “Exclude” that Webroot doesn’t understand?
   - Fully aware of how the agent works, scanning is just one of the shields and not the primary method for determinations. What you describe appears to be a path override, which the agent has to scan the entire directory to gather the PE binaries to determine if any malicious code was dropped in the directory and compared against the setting “detect if malicious”. If this setting is not checked, it will attempt to ignore these binaries. The agent does NOT arbitrarily ignore any directory that is configured as override, so that is correct, which if there’s a specific application/exe/dll that is important and part of a line-of-business application, then it’s suggested to create that binary as an override vs a path override, which is handled different. Direct binary or MD5 overrides are fully ignored and instantly available via the console. Path overrides are a bit more nuanced.
4. You are saying the bottom line here is to contact support. Been there done that. Useless.
   - It appears support provided answers that were satisfactory and worked.
5. 9.0.27 might fix the uninstall error but add the problem with the WRSVC service not starting because of a digital signature error. Typical of Webroot. One step forward two steps back.
   - Actually, the service enablement registry key has been there for some time. If it was disabled, for reasons unknown, 9.0.27 simply respected that setting. I’ll research this more to fully understand the situation, but a clean install may have been in order for problematic systems like this. The core KEXT and Binaries we supply are fully legally signed & certified by MS. The reg flag is a technical workaround MS caused, but the code is fully digitally signed.
6. The policy is set to add it. It just doesn’t. This has been going on for over a year and Webroot refuses to address it.
   - The installers have not changed in years for sure and it’s usually requested to be removed, not added. 99% of MSPs request to have this removed. Can research more, but adding it for local use is not something that’s been requested, which is why it’s off by default.
7. See #5 above. This is a known issue with 9.0.27. Call support and reference ticket# 308239
   - It’s not a known issue with 9.0.27, it’s a previous issue that was simply being passed along to 9.0.27. Fresh install would have rectified this. Not a great answer, but since the agent is 5mb, reinstall usually it’s that much of a problem.
8. Call support and reference ticket# 306966
   - No need, I’m just one floor up from that team. 8-)
9. I have reported the suspect program 12 times over the last two years and once again Webroot doesn’t do anything. Is ignoring things by design too? The need to listen to people who take the time to tell them that a false positive needs to be corrected.
   - You’re welcome to provide the solution and/or binaries in question directly to me and I’ll follow up with our threat team. Our threat team builds rules to combat updated binaries, but it’s not 100% perfect, so updates are often required. If you export the CSV from any of the “Undetermined” reports, I will follow up. scooper@webroot.com 

Again, my apologies for your experience. While I can understand your frustration, there are limits to the millions of technical challenges and variable with a security product, keeping endpoints safe and its management functionality.