Please add proper support for TLS 1.3 in Mono so that Chrome/Firefox users don't have to disable TLS 1.3 to make ScreenConnect work.

Related KB: https://docs.connectwise.com/ConnectWise_Control_Documentation/Technical_support_bulletins/Can_no_longer_load_Control_website_after_updating_Chrome

Background: Control 6.5 imposes a signature validation scheme to ensure the integrity of the Connect install (per this post). This is a net good for most of the community base. For the rest of us it's more trouble than it's worth.

Request: We need the ability to either whitelist custom extensions from validation or disable the signature validation scheme entirely.

Reasoning: I've developed quite a few extensions in an on-premise Control installation to automate significant portions of my business. I'm not willing to share some of this code since it exposes the inner workings of my business, sometimes usernames and passwords, trigger URLs, and plenty of other information that would be useless for the rest of the world, but could increase the risk of my own business data should it be shared with a third party -- even ConnectWise. Microsoft, Google and Adobe have each been hacked in the past, so it's safe to assume that anything I share with CW will eventually be exposed as well.

The hosted developer instance option requires me to share business logic and requires significant rewrites to the code for each of my extensions to be able to prevent business information exposure. Furthermore, as far as I can tell, some of the functionality can not be rewritten in a way that prevents this exposure.

I've submitted an extension to CW in the past and it took weeks to have it approved. It took weeks to be approved for a developer instance. I can only imagine initial approval of each of my extensions to be able to use them in my own on-premise install will take weeks as well, and even minor updates to my extension (such as cosmetic changes or field formatting) will likely take weeks to be approved as well. 

On-premise users require the ability to continue to use and develop our extensions without exposure to ConnectWise. Please enable us to whitelist our custom extensions within the web.config so we can maintain the integrity of our own installations and source code.

Hello, I've been using Connect Wise for over a year now and work with many individuals and businesses.  A convenient requested feature is listed in the header of this notice.  I'm wondering when this would be available for IT's to utilize and how we could enable this feature.  The sooner the better!  To just use the drawing tool is rather cumbersome and ineffective.

Thank you,

Bill Marks

Computer Training & Support Services, Inc.

847-736-2326

email:  bill@ctandss.com

Be able to apply App.Config files or settings based on the Session Group(s) a computer is in.

CW#7546987

I'd like to see more settings available on a per-user rather than per-endpoint basis. One example:

I use SC to do remote support for my clients. I'm almost always connecting in when they're there, so I never want to blank the monitor. I've provided access to SC for a client who wanted access to their own PC, so i created a user, customproperty with their name to give them access to their PC only, all that jazz. They can log in and use SC to connect to their PC and only their PC. They want the ability to blank on connect by default because they'll only be connecting to their PC when they're out of the office, so they don't want anyone snooping around and looking at what they're doing remotely. However, this is the same SC install on their PC that I connect in to when I support them while they're in the office, so I don't want it to blank. Setting the app.config on their computer would make it so that no matter who connected, they'd get blanked, which isn't ideal. If the preferences were attached to the user, then they'd get the blanking default they wanted, no matter the computer they connect from or into, and I'd get my non-blanking that I want.

Can you separate the permissions in "manage credentials"?

I mean, we want some users to be able to "Prompt for Storage" but we want other users to be able to "Send to Screen"

Partner wants to "bake in" proxy settings instead of using the tray icon on the client.

Haven't seen this yet, but with so much MSP hacking... we'd appreciate the option to force 2FA every time (not just a new browser)    Its only a matter of time before a tech gets compromised.

Option to select Force 2FA Always either by tech or everyone is just fine.

I have clients that use the remote printing feature of ScreenConnect daily, but after updating to v19.0, remote printing now needs to be toggled manually each time the host connects. I would like it if once remote printing is enabled then it stays active even after the host disconnects, unless disabled manually.

Now that SAML is supported in 6.5 we need a way to log out from the IdP when we log out of ScreenConnect.  Please add support for the Single Logout URL or a custom Logout URL when using a SAML provider for authentication.  

Right now if I log out from ScreenConnect I stay logged into my IdP and I can get back into ScreenConnect without entering my credentials again.