Hello and Welcome to Webroot @msmith-442 

Sorry I do not know that much about Webroot Business Endpoints.

Hopefully this helps?

It is possible to shut down or temporarily disable the Webroot Business Endpoint Protection agent.
 
To do this:

1. Log into the Webroot console, open the policy applied to the endpoint(s).
2. Under the Basic Configuration settings:
   • Change the Allow SecureAnywhere to be shut down manually setting to On
3. Save changes to the policy and apply it to the endpoint(s)**.
4. Once the updated policy has been applied to the endpoint, right click the system tray icon (W in green circle) and select 'Shut down Protection' to disable the agent.

**NOTE: Policy changes will be applied during the polling interval set for the policy. You can force the endpoints to check in by:

• Right clicking the system tray icon and selecting ‘Refresh Configuration’
• Forcing the endpoint to poll by locally or remotely executing a wrsa –poll command:
  • For 32bit Operating Systems: "C:\Program Files\Webroot\WRSA.exe" -poll
  • For 64bit Operating Systems: "C:\Program Files (x86)\Webroot\WRSA.exe" –poll 

For more information on editing policies, please see the user guide. https://download.webroot.com/WSAB_EndpointProtection_AdminGuide.pdf
 

Also please check here for information: https://community.webroot.com/troubleshooting-and-uninstalling-143/how-to-shut-down-or-temporarily-disable-the-webroot-business-endpoint-protection-agent-337541

You can also Submit a Support Ticket and the Support Team will assist you free of charge:

https://www.webroot.com/us/en/business/support

Note: When submitting a Support Ticket, Please wait for a response from Support. Putting in another Support Ticket on this problem before Support responses will put your first Support Ticket at the end of the queue. A reply from Support should take from 24 to 48 hours but could take a little longer because of COVID 19 and the Webroot Employees are busy working from home.

Hi!  Thanks for replying.  I am a new user, my SysAdmin has recently bumped me up to "GSM Super Admin" permissions.  However I still cannot seem to do what you are describing.

I am able to log into the admin control panel, switch over to the Policies tab, find my default policy (applied to all workstations), but I am unable to change any of the settings on it.  There is no option for me to change any of the settings on that policy:
 

I would think there has to be an easier way though?  I don't want to change the policy for my entire company, just temporarily disable protection on a single workstation to troubleshoot a software conflict…?

Hi @msmith-442 

I do apologize and I do understand what you are trying to accomplish but I am not a Webroot Business advisor. Perhaps this link can assist with this issue.

https://docs.webroot.com/us/en/business/wsab_endpointprotection_adminguide/Content/ManagingEndpoints/DeactivatingEndpoints.htm

As I have mentioned please Submit a Support Ticket or/and let me ping someone that knows more then I.  @freydrew can you advise someone in the Business Support to assist here?

Hi!  Thanks for the additional link.  I’m able to get to that screen but I do not have the checkboxes shown in step #2.  So I can’t select different endpoints.

Additionally the only options I have in the toolbar at the top are “Save changes” and “Undo changes”.  The option for “Move endpoints to another group” is visible but grayed out.  I don’t have any of those other options like “Agent commands” or “Deactivate” shown in step #3.

Is this software syncing to my AD, perhaps?  Do I need to make some kind of change in AD?

I submitted a ticket on Friday, hopefully someone in business support will be able to respond to me soon.  Thanks!

@msmith-442  - you’ll need to create an editable policy. It sounds like you have opened the “Recommended Default” policy, which is NOT editable and shouldn’t be used in production. Rather, we advise to copy this policy, give it a logical name, like “Workstations Default” and then you can edit these policy settings to fit your need.

You may also find this Best Practice Guide helpful.

General Guides: https://docs.webroot.com/us/en/business

Admin Console Guide: https://download.webroot.com/ManagementConsole_BestPracticesGuide.pdf

Make a custom policy, change the “Shutdown protection” setting and it’ll show up in the System Tray icon. When you right click, you’ll see a menu. The “Shutdown Protection” will show up there.

Hope that helps

@coscooper  Hi!  Thanks for the response.  I looked and we are using the group “Default Group”, not the one labeled “Recommended Defaults”, so I assume what you are suggesting is not the case?  See screenshot:

When I double-click on this policy this is what I see:

 

I can’t figure out how to change any of those values.


In any case, is this the only way we can do this?  Seems like a lot of work.  As I said above, I’m a new tech working at a company that has used this product for a while.  I don’t want to make any sweeping changes to our policy, just trying to figure out how to temporarily disable the program on a single workstation to trouble shoot a compatibility issue.

When I try to disable the app on the workstation I get this message:

Any other suggestions?  Thanks!
 

@msmith-442 - It does look like that redacted site policy may be a custom policy assigned to all of the endpoints, which you should be able to duplicate and modify for single use or what you’re trying to accomplish. However, these screen shots indicate you do not have admin privileges to make a policy or modify a policy at the site level. If you had admin privileges, you’d see the following buttons along the top. See Create/Delte/Rename etc… these are admin options.

If you could modify policies at the site level, you’d see the extra column to the right where you could make the respective change.

Check with the main console administrator to change your permissions. I noticed at one point you’d mentioned this was a multi-site console, so if you’re log in is established as a GMS admin, check there to see if you have rights at the global level. If not, the administrator can reset them and/or setup your permissions site by site.

Once you have admin privileges to make these changes, you can make as many custom policies as you’d like for specific use or to assign to various endpoints.

If you guys need a full walk through of best practices and help with managing your console, you can private message me here or email me at shanec@opentext.com and I’ll have someone on my team reach out to get that scheduled.

Hi @coscooper !  Thanks for replying.  I saw in your reply above where you said "However, these screen shots indicate you do not have admin privileges to make a policy or modify a policy at the site level."

I asked my SysAdmin to make me an admin and he made me something called a "GSM Super Admin".  I looked on the “Admin tab” and this is the same permission level he has.  I don't know what that means, but shouldn't "GSM Super Admin" be able to edit everything?

Is there something else he needs to change in order to make me be an admin able to edit this specific policy?

@msmith-442 

You should be set to what’s called a Limited Admin and given permissions only to the site  you require access.

If you are only temporarily troubleshooting, you can just set the policy of a single endpoint to “unmanaged” from the group management tab of the console. That way you can then adjust any settings locally on the computer itself including shutting it down. That option then is found under the local GUI by clicking the Advanced settings button. 

Just be sure when you are finished to go back to that group management tab and set the endpoint policy back to the default one you previously used.

John

Hi @jhartnerd123 !  Thanks for responding.  I understand what you are saying that I should be “Limited Admin”, but even as a “GSM Super Admin” I am unable to change a policy, make a policy, or move a computer from one policy to another.

Wow, and I thought this would be an easy question, LOL.

You can’t be a super admin or even a limited admin if you are unable to make any sort of adjustment to a policy. You must be set as a view only account. 

@jhartnerd123  - This is me:

 

Omg.  I found the settings.  Needed to change it here.  Worst UI ever.  There goes about two days of my life.   
 

Maybe now I can make some progress...
 

@msmith-442  - looks like you figured it out. I’ve been heads down all day on another project and didn’t get a chance to jump in earlier. @jhartnerd123  offered good suggestions for using Unmanaged policy over turning on “Shutdown protection”, beyond the ability to modify/admin policies, sites, settings.

The different settings, Admin type (Super vs Limited) are for specific use cases. Then, the site admin view/admin per user, per site is for the same. There are many customers that have different admins for different needs, like helpdesk, NOC techs, administrators, site only admins, specific customer admins, so the UI and settings are for a variety of needs. Super vs Limited show/allow high level sections and if not visible, then that user/tech can’t modify things, like policy and/or overrides at a global level. THEN, that per-mutates down to sites with a hole other set of permissions as we support site only admins for when/if you have a user that JUST needs to manage/see just one site.

As an aside, the entire console is being redesigned to offer streamlined UI for these kinds of settings & needs. Admin privileges has grown over the years to what we have today. There’s a lot more work that needs to be done to make it useful, but to be totally frank, admin privileges are complex due to the variety of needs and the destructive ability if every abused, misused or through ignorance, so it’s not super easy on purpose. 8-)

Lastly, as I’ve offered earlier, if you need a training walk through or best practice session, we offer it for your edification and to speed up the process so you’re not posting back and forth in the community and/or spending all this time hunting for a setting. Had we had a 10 minutes BP session online virtually with an expert, we’d have had this fixed in less than 5 minutes. 8-)

Now that you have correct admin privileges, there are a lot of other policy settings and suggestions we can offer to streamline your setup. Private message me if you’re interested in setting up some time to review and insure you’re setting things up correctly. Myself or someone on my team will reach out and get that scheduled.

So typical, USELESS. At times we need to be able to shut down the program in short order because occasionally it will cause some issues. We used to be able to do this simply by unchecking a box next to the Host name, shazam. NOW, APPARENTLY, we need to run this by a Senate appropriations committee, get a majority vote in the House, and hope it passes. 

POLICY, you’ve GOT to be kidding. Why on Earth should I need a POLICY to stop a program on a machine? A Policy of ONE???????? Lol.

Repeat, USELESS

@EasyNow  - Unfortunate you feel this way. The console and management of endpoints has to appeal too many environments and needs, including large endpoint counts as well as a single endpoint, so it has to accomodate many needs, not just one single threaded requested need.

Policy management has been the same since inception, nothing has changed.

Why Policy over “magic buttons for admins on the agent” ?  Because of self protection and insuring a malicious actor does not compromise the agent when it’s hacked. Being an admin in the console provides authentication to make a change to an endpoint. Flipping a policy is seconds in the console, if you’re on the endpoint troubleshooting it’s simple enough and fast enough to have the agent call home, get the policy, make your changes/tests and then flip the policy back to production lock down. It doesn’t take an act of congress if you’re the proper admin.

As mentioned, there are deficiencies to be sure and some of them will be addressed in the near future with the console UI/UX refresh.

Respectfully, I disagree.  As a new user of Webroot I had to spend *hours* googling, reading forums, testing, and reaching out to support just to troubleshoot one relatively insignificant issue -- which turned out to be a bug in Webroot's Identity Shield, which was preventing Google Chrome from opening, which *still* has not been fixed.

Yes, we have an open ticket, they are aware of the issue and no ETA on resolution.  In the meantime we've just had to turn the protection off.

I could have figured all this out much more quickly if there was an easy way to administratively disable functions on a single endpoint or if the process was more intuitive.

This frustration is coming from a seasoned IT Pro (over 20 years in the business managing the IT departments for multi-million dollar companies).  Based on this experience I have had with the software so far, I will be making every effort to move us to an alternate platform in the future.

@msmith-442 - I can fully understand your frustration and agree. As a 30 year IT pro myself, something as simple as this should be easier. The current technology and console are being completely revamped to provide more ease of management and ease of troubleshooting.

The ID Shield issue at hand is relatively new and is a bug being worked. The agent is undergoing a transition and this specific shield will be addressed in forthcoming releases. There are numerous strategies for troubleshooting. One issue with the current agent is, there are numerous shields and attack vectors the agent monitors and even if you’d had access directly to the agent GUI it may not have been easily transparent.

That said, for any sizable business partner, we offer direct hands on best practice calls from inception so you guys don’t have to go through these pains. Depending on your reseller, they should have offered that as an option which in less than an hour, I or someone on my team, could have gotten you much further along a more successful path. No software is perfect and we all have to figure out work arounds to solve specific problems.

Please let me know through DM if you’d like to schedule something to review your console, offer trouble-shooting options and how best to move forward.

Disagreement noted, but again, not helpful. Case in point, I’ve been trying to create a Kaseya Agent installer for a Mac, but the package is missing files. The feeling at Kaceya is that Webroot is causing a problem. I shared my screen on a zoom, but as I am unable to disable or uninstall webroot, we have no recourse. It’s not just a bug, it’s a major disaster! A new client is not getting his Mac installed because Webroot, in it’s lengthy existence, still has not come up with an effective or expeditious method for disabling, or even removing, itself. Instead, they are passing the buck to Kaceya, in effect saying it’s Kaceya’s responsibility to do this with some sort of policy.

Thank you for the verbose input, though. Looks like the only way I can get this removed is going to be to nuke the windows on this pc, and start fresh, sans webroot.