Welcome to the ConnectWise Control Feature Request Portal
If you do not have an account, click "Sign in/ Sign up" to get started.
Tips
- Search for an existing improvement or feature request before adding your own. This helps us prevent duplicate entries and track all suggestions.
- If you find a matching request, give it a thumbs up and throw in a comment.
- If you can't find a request for an item you need, create your own request. Provide as many details as you can, especially regarding possible use cases.
Rules
- No spam, advertising, or self-promotion.
- No offensive posts, links, or images.
- Only one request per post.
- Administrators have the ability to moderate the forums, including editing, deleting, and moving posts. Posts may be deleted for any reason, with or without notification.
Thank you for sharing your thoughts with us!
Standalone uninstaller
Uninstaller App specifically for installs gone wrong. I just had an issue with an installation gone wrong and was not able to uninstall because it was looking for the original installer which was not there anymore.
Allow the CW Control Agent to run as an account other than SYSTEM
Allow the CW Control service to run as an account other than SYSTEM (perhaps another admin account designated for this purpose) to support a least privilege administrative model.
Repair/Reinstall/Refresh from CLI
Add the ability to trigger a client repair/upgrade from the command line.
For example:
"C:\Program Files (x86)\ScreenConnect Client (xxf3xxe7xx62xx04)\ScreenConnect.WindowsClient.exe - repair"
We have seen cases where a working client does not automatically upgrade to the newer version of the client. We would like the ability to issues a repair command from the command line to trigger a from the client side. The repair would use the existing configuration to reach out to the CWC server and initiate an upgrade. And for logging, just add one entry to the Windows Event log stating a CLI repair was issued.
This would help diagnose stubborn client installs without having to performing a rip-and-replace.
change default session settings based on group
I'd like to be able to change the host client settings based on which group or client they are assigned to i.e. for a certain group we blank the guest monitor , others we don't but we block their input etc.
Extra Functions/Variables in "Session Filters"
Can we please expose more functions and or Variables to the Session Filter section of the Session Group Editor?
Can I suggest (specifically for SAML users) the following Variables:
$UPN
Can I also suggest the following FUNCTIONS to be added:
Mid(string, start, [ length ])
InStr([ start ], string1, string2, [ compare ])
Replace(expression, find, replace, [ start, [ count, [ compare ]]])
A good example of how this could be used is a Session Filter called:
"Where am I logged In currently":
GuestLoggedOnUserName = $EMAIL
There are so many BASIC functions missing from this feature, and it would be great to finally be able to use it as powerful as it is.
Force log off a user from a host
I have a situation where all licenses are in use with Screenconnect. I know that one of the sessions is running on a PC where the user is not actively using it. I want to be able to find that specific session and disconnect that user to free up a license. This should work in the same way that Microsoft Terminal services works, where even if more than one user is connected to a host I can drop just one of the connections. Right now the only way to do this is to revoke access from all sessions in the security tab of the administration section. This is a terrible user experience because I sholdn't need to force disconnect every user in my organization just to free up one license. Please fix this so that the available actions for a host include a "disconnect active session" option.
Add host to client tunneling or port forwarding (ala plink.exe -R or -L)
Add the ability to forward specified ports from the host to the client. For example 5433:localhost:5432 - let me connect from pgadmin to the postgres database on the remote (port 5433 gets forwarded to localhost:5432 on the remote.)
You can do this with plink as "plink.exe -R 5433:localhost:5432 username@sshost.com", but you need an ssh host running and connectable from the internet. (Plus additional key/password management hassles.)
bring "Send Syslog Messages" Extension to the next Level
Currently the Extension: Send Syslog Messages includes only basic information: such as connected, disconnected, etc..
For security relevant troubleshooting not really helpful.
right now information was logged in this way:
for my understanding it should look the following:
{Session.Name} or {Session.Host} should be used as free available variables - similar to the triggering functionality - configurable via the Extension Settings.
the settings should be extended to have an option if this kind of event should be forwarded or not.
The extension should also have an event: Where its possible to create an alert if a User has generated a Link for "Get Host Pass" and events, when it has been really used.
Ability to limit the amount of bandwidth the client consumes over low-speed connections
Story: As a host, I want to be able to limit the maximum amount of bandwidth Control uses during a session such that my session does not become unresponsive/unusable over lower speed connections.
Sometimes we use Control to remote into PCs over VSAT connections as low as 512kbps with RTT latency up to 2000ms. If the Client PC is displaying motion video (perhaps a CCTV window is open) then it's possible for Control to consume as much bandwidth it came--up to our limit. This further presents a problem because it's nearly impossible for the host to control the PC enough to close out the application or minimize the window; however, sometimes the Host actually needs to configure the application that may be displaying video. A host disconnecting from the client doesn't immediately resolve the solution as it appears the client has a buffer that must be emptied despite the host having already disconnected.
Possible solution would be to add a Client Build setting to limit the maximum amount of bandwidth the client can produce. Excess video would be dropped, etc.
Better Solution would be to not only limit bandwidth, but also have an option for a UDP connection between Client - Server -Host rather than TCP to cut down on latency and make it easier to limit bandwidth and drop packets gracefully.
Customer support service by UserEcho