Under Review

uninstall password

Dustin Evans 6 years ago updated by Kyle Simpson 3 months ago 24 1 duplicate

We would like to have the option to add a password to protect the screen connect client from being uninstalled by users with local admin privileges. I have found that when the client is installed from labtech, users don't recognize it and tend to remove it. This causes problems with the labtech SC plugin.

Available in Version:

Duplicates 1


Where I understand that you want to limit the client from doing something that he should not a local administrator acces should be respected.

the level of acces screen connect give on a target computer is very important, let imagine a bad user using this feature to lock donw computer under his/her control. the way to prevent removal should be by controlling the user acces level on the target computer and not limiting a correctly authenticated local administrators form removing the software.


That is normally how things would be done. However, we cannot revoke administrative access from clients that own their infrastructure. If we did that, we WOULD be using best practices but we also may not keep our clients. For most clients, limited access is transparent but for most users but for some, admin access is necessary. Furthermore, privileged operating system access for a user should not impede our ability to support that user. Usually, the user is unaware that the software was installed by us in order to support them (despite the onboarding package they receive) and they are under the impression that it is some frivolous program installed by one of those commonly used programs that installs junk along with it (not pointing any fingers) and they remove SC from their computer. When this happens, it is a big waste of time for us to fix it through LabTech. My compromise on this would be as follows; if the user tries to uninstall through the control panel, require a password but also having a command line utility that allows uninstall without a password.


We just need a password prompt like trendmicro has for their software so users cannot uninstall screenconnect.


Panda uses this method too. Works like a charm. Make it possible to edit the password per client, so you don't need to give them a master password, which can be used on every system.


Could we, instead have the capacity to provide an custom message with logo part of the unistall screen. Then the user will know the software was install by there support compagnie with a message that would make it clear for the end user about what they are doing.

That's fair. Software installed by: <company name>

Considering for Future Release

Any movement on this?  If we do not see this on the road map soon I may be forced to move to another remote access client which is not something I am thrilled about...

Also interested in this. 

Suggested workaround - use LT to push the client to machines where it's been uninstalled. Could automate this by just dropping the correct command in the commands table. 

OR - just use LT to remove the registry entries so it's not listed in "programs" control panel. Also easy to do. 

Any movement on this yet? Also, looking for uninstall password to prevent users from uninstalling even if they have local administrator rights.

TrendMicro does this with their antivirus client.


Why hasn't this been added yet? It's been a feature request for 3 years???

Clients have requested we use remote access software that includes tamper protection for the client install, I sure am going to hate using two different Remote support packages. I really hope after 5 years this is something that is actually in the works. If it is please update this post with an ETA. If not I will start looking for alternatives I guess.

As a workaround  - Ask them if they'll accept you removing its entry from Add Remove Programs so "users" don't see it as installed and try to remove it. Nuke the registry to remove the entry for it. 

Wow. I am surprised this is still a request after 5 years. In my situation, there is no in-house IT personnel. A password to uninstall screenconnect is needed because while most users do not have local admin rights on their machines, there are some users who do have admin rights for whatever reasons. Having to waste time troubleshooting why you lost connection to a device, then to find out it is because the user uninstalled it is counterproductive. Even if there was in-house IT personnel, then a simple fix would allow them to know the uninstall password, if ever needed. Please can you add this request?

This will be useful feature for some corporates if you can let us choose to set this passcode when building the installer.

For corporate devices, we want to make sure certain apps are always running on devices and something like this passcode feature if it is available would be great because we normally give local admin access to some teams for development purpose and we don't want them to remove this agent without IT admin consent.

Most endpoint security agent apps has this feature of passcode to uninstall or remove agent from user devices or at least user shouldn't able to remove it unless they have some uninstaller so either of these two features is what I noticed on any endpoint manager apps.

Please review and let me know if my request makes any sense.

It's discouraging this has been sitting here for 6 years. It would definitely be a nice feature. I was just encouraged in a support ticket to put in an enhancement request for this very thing. Here's my 2 cents. I have an admin user who is actually manually stopping the Screenconnect service. In the past, I've used Symantec Endpoint Protection, and Bitdefender Gravity Zone, and they both had the ability to password protect the agent such that it couldn't be uninstalled or stopped by even an admin if they didn't have the specific password to do so. I know this is not an antivirus program but IT WOULD BE AWESOME if we could have a way to protect the services from being stopped and the agent from being uninstalled. We are only dealing with corporate owned devices.

For reference:



Any further update on this?