Removing WRSA

  • 16 January 2019
  • 5 replies

Badge +3
Webroot's self-protection has, once again, gotten completely out of hand. We are deploying by NinjaRMM (not by choice). This is a hit-and-miss process; usually the agent pairs off OK with the associated webrootanywhere account, and while it's an enormous PITA to have to create the policies and profiles AFTER onboarding, this isn't the problem.

We are in a situation where perhaps 1/10 of all installs will deploy the WRSA agent files OK; it'll start up, pull a default desktop config profile from god-knows-where, but then it tries to pair itself off to an account, fails with a generic internal error, and then slams the rest of the install shut and digs itself in like a tick.

Exactly like a tick. It'll sit there siphoning off resources (think desktop profile running on a server), and is extremely difficult to remove safely.

The agent itself is locked out by default (because Webroot), but because the process failed during provisioning, there is no valid central control panel from which to manage the agent. That's pretty shabby design, but whatever.

We used to be able to disable the WRSA service, reboot, then run \Program Files (x86)\Webroot\WRSA - uninstall.

Sometime in the last week (since I last had to do this) something has changed, because that command line switch now appears to loop back to the user-mode control panel command--which "helpfully" informs you that the product needs to be uninstalled from the central panel and bails out.

Is there a new process or other command line switch that I'm missing?

5 replies

Badge +3
As an aside, installing PSEXEC and running WRSA -uninstall in an artificial system/interactive context DOES seem to trigger the old removal script, so it's a workaround of sorts.

But let's be clear; having to install a 3rd party tool to get around a broken installation process is ludicrous--so I'll keep my question standing in the hope that there is a less extreme solution.
Userlevel 6
Badge +20
@sfogg my apologies for your situation in regards to deploying through this RMM. I'll forward this onto a SME that knows that RMM behavour better than I.

However, in regards to the main question, removing WRSA, nothing has changed with that uninstall command in a CLI. However, it only really works when you boot that machine into safe mode. It's never worked when running under a normal user or even an admin and that's by design. It will also work if you can gracefully shutdown protection through the system tray icon. If the agent does not get a policy, there's a chance it sets itself to "unmanaged" and allow you to shutdown protection. If not, Safe Mode is your best option.

FYI... when the agent first gets installed, it runs a learning scan to determine what's already on the computer, then it checks into the console via what ever "key code" it was provided. You can review this in the UI by looking at the Accounts section on the right. It may not show the entire key code, rather it will show the first 4 characters to at least indicate where it thinks it should be managed.

If I discover how Ninja passes this information to the installer, I'll let you know.
Badge +1
@sfogg. Thanks for the detailed info on the issue and it certainly isn't the norm for installs. We like to assist to remedy and can start that process by documenting the issue in greater details (logs). As Shane noted, we would leverage Ninja as well to get more clarity into their process. I'll ping you directly to start the process.

-Thanks. Michael
Badge +3
@Shane: Thank you for taking the time to reply, but that isn't consistent with what we've seen. We've opened support cases on this before, but all we've ever gotten was workarounds to deal with the specificity. Not that these didn't work; we got 'disabling the service and rebooting' from one of your support folks, and it was a real diamond in the rough--but there was never any willingness to acknowledge a wider issue. The default profile [at least the one picked up from Ninja's deployment package] locks out the local console. I'm sure you can see how this could be problematic.

The bottom line is that as an MSP responsible for 600 endpoints, 'booting to safe mode' ranges from 'unreasonable' through to 'impossible' on almost every deployment scenario that I currently manage. The specific example that inspired me to make the above post in the first place was on a production DC. There is absolutely no way that I'm going to put a DC into DSRM to remove a bad AV licensing key, and not offering a reasonably accessible offline force-removal tool makes my job much harder than it
needs to be.

As such, we need better solutions than 'boot in safe mode.' And if they aren't found with the vendor, then we have to come up with our own. This is really neither here nor there, though, because I've got the answer to my question. It's 'use the third party tools and work around it.'

Thank you anyway.
Userlevel 6
Badge +20
@sfogg Unfortunately the root cause is how the installation is handled from your RMM and how the installer receives its key code. If the installer gets a key code from a console you do not know or do not have management access, then that process needs to be reviewed by Ninja, not Webroot as we did not direct or build this integration. You're trying to solve a problem through brute force options that are not ideal.

If the installer is handed a proper key code, which is locked to a console by design, not to tick folks off, then it can be managed properly without incident. It's when admins want/desire out of management methods to "break" the agent from doing its job that gets difficult. The agent is just doing what it was told; [Install at the kernel level, lock to XYZ console (which can be figured out, as I mentioned, look at the UI and see what account the key code was assigned) and only let an approved technician with access to that console shut me down or manage me.] It just installed as it was told. When this is all done correctly, there's no issues and no problems.

However, when admins want a way to "break" the agent, it becomes a problem and yes, we make it very difficult, by design. (Booting to safe-mode is just one way we offer to help when an agent has been miss-managed, i know it's not ideal, but it's not going to change). If it's hard for you manually, then it's hard for a bad actor to compromise the agent and Webroot should not be held to a "loose standard of expectation" for convenience. As soon as we loosen those restraints, then we'll get blamed for being able to be shut down too easily, thereby compromising systems. So, we err on the side of being hard to shut down every time. 8-)

I believe the root issue revolves around the RMMs approach to installation and providing the appropriate key code as these kinds of issue are not present with other installation partners. Breaking the agent because it was installed incorrectly is as stated a work around, but not the root cause. If we figure out the root issue, key code assignment that you can fully manage in the first place, the need for a third party hammer is not necessary and we can offer a way to manage the agent in a controlled fashion.

The real answer is find out how that particular RMM supports the installation and we'll find the problem and provide you a manageable solution that doesn't require any third party tools.