Every time we update to a new version of ConnectWise Control, it freaks out our EDR.  We spend days dealing with hundreds of benign alerts -- because your update files aren't signed.  It also delays the rollout process.  Would really appreciate if you used signed files for updating.  It is more secure and significantly less headaches.

The weakest link seems to be the SQLite DB. Once the DB gets to 1GB size, the SC application becomes unstable.

Our situation :
We have 3 offices in Canada (HQ, A, B)
HQ-A have MPLS link between them,
HQ-B use VPN over internet.
All location have independent internet access.

We use access session on all system in all location, but the relay is located in the HQ.

Curent setup.
1 DNS name to the server that resolve to an external IP when out of the local infrastructure and an internal IP when inside the infrastructure.
- This way system on our internal network dont use the public internet access, it more secure, reduce the global bandwitch and load on our front end firewall.
The issue, if the inter-site link go down, the access session will not be able to connect, as the DNS will still resolve to the internal IP, resulting in disconnection.

Our need, be able to setup 2 URL for the a access session, as such when the 1st is irresponsible the client can try connecting to the second one, with a retest every X to go back to primary.
With this we could setup our client with a internal URL as primary and an external URL as secondary and still reach our system if the VPN or MPLS go down, but not the internet.

Currently there is a trigger that sends an email when guest sends message to unconnected session. This annoys our customers that there is even a chat option that does not go anywhere when a session is not connected. They don't understand this. Even though we keep telling them we have a chat option under the LabTech agent icon they choose the first "chat" they find. PLEASE add a configuration flag/option to disable chat screen when session unconnected. I know we can hide the system tray icon--however that prevents other features we do use/need.

We've frequently ran into the need to be able to have different technicians connect to different "guest" sessions on the same terminal server at the same time. Currently we fight over whose already in a machine.

From CW#7560570:

Partner would like to limit ScreenConnect hosts to only be able to open a configurable number of sessions at a time, preferably with a way to have different users with different numbers of sessions that can be open (licenses used).

Look at this thread on the forums, no one likes the new name "Control". The only way to get it changed away from this horrible name is to upvote this feature request. Either change it back to ScreenConnect, or call it something else like Connect, just not a name that implies a negative connotation. Please. This was really a bad idea to change the name.

Partner would like the ability to control and launch sessions from device's running Chrome OS.

The addition of Duo push 2FA is great but a bit puzzling. Why only support push when Duo supports so many authentication options and they make it easy to implement them all.

• Some people don't have a smartphone where they can install the Duo app so push won't work for them but they can still receive a text message of phone call just fine. Duo supports both of these options for 2FA but Screenconnect's Control's integration was is implemented in a way that does not allow them.
• Some people might have multiple devices with the Duo app installed and need to choose which one they want the push sent to. Duo allows users to choose which one they want to receive a push from, or which one they want to receive a text or call on. Again Control's integration does not allow this.
• Ever forgotten your mobile phone at home? I have and that's why I've configured my Duo account with a hardware token too. Unfortunately Control's integration does not support this Duo 2FA method either.
• Perhaps you are prone to forgetting your mobile device but don't want to have a hardware token. In this case Duo can be configured with bypass code (basically a OTP that you know beforehand). Well, you know the story.

I'd really like to see Control support the all the Duo authentication methods and for the looks of their documentation this should be relatively easy.

As an added bonus this also provides a natural way to handle the 2FA logon rather then show the user a prompt for a code that they can't type (what your Duo 2FA currently does).

make file transfers more efficient, auto resume the transfer if connection interupted