Since upgrade to 19.5 when i open a client session the session Window is tiny and i have to resize it larger to make it usable.  When i close the session and re-open it opens tiny again, it does this no matter what computer i click on and start a session.  Nothing has changed on my computer.  Wasn't doing this before upgrade to 19.5

Setting up Connectwise Control on macOS 10.14 (Mojave) clients is difficult and requires many extra steps as compared with previous macOS versions.

To set up Connectwise  Control on a brand new install of macOS 10.14, these steps are required:

1. Install .pkg as normal (this allow remote viewing but no control)
2. Reboot macOS computer
3. After reboot, attempt remote control, this will prompt a popup asking if the macOS computer wants to allow
4. Click "Open System Preferences"
5. Click lock (bottom left), enter computer password
6. Check box next to "screnconnect-xxxxxxxxx"
7. Reboot
8. Remote control again works

In cases where remote control was working on a macOS 10.14 computer where Connectwise upgraded from 6.6 to 6.7, connectwise software must first be removed using these steps:

1. From Access website, select session > End > Uninstall and end
2. On macOS computer, open system preferences > accessibility
3. Click lock (bottom left), enter computer password
4. select "screenconnect-xxxxxxxxx", click - to remove
5. Reboot
6. Install using steps above

I believe this complexity is due in part to some sort of increased system security in the new macOS.  Still, it seems much of this could be streamlined.

On access page other machines are being displayed in the preview window. These cycle through until the correct machine is shown. The wrong organisation name is also displayed.

When generating a new adhoc support session, a preview window appears before you can choose the session settings. 

6.6.17808.6681

The Host is greeted with a grey screen when attempting to connect to a 2003 server.

Last known working version: 6.8.20124.6845

Since updating to 6.9.20755.6879, we noticed that some guests disappear until restarting the ScreenConnect Web Server and ScreenConnect Relay services.

TLS 1.3 seems to breaks screenconnect  when using ssl on mono.

Disabling it in chrome/firefox seems to be a quick fix, however at some point im guessing it would be better for mono to support TLS 1.3. 

Version 6.5.16479.6613

The communication object, System.ServiceModel.Channels.ServiceChannel, cannot be used for communication because it is in the Faulted state.

We have a 2019 Clustered HyperV environment where the guests do not show a live display unless the console is live from the HOST 

Keys and Mouse seem to be being passed through because if we send a CTRL+ALT+DEL to the guest and refresh the screenshot you can see it has been passed through to the guest, the display on the session just does not refresh for the host 

Screenconnect Version - 19.2.24707.7131 (not listed below) 

Environment to reproduce:

Have a SAML server setup and working.

Using ADFS as a backend server.

Sidenote:

SAML works for all users with other applications, like ITGlue.

SAML works for most users using Control.

Have user who is a member of 170 AD groups. 

Error:

User can't login with SAML to Control. Just acts like he never pushed the button. Address bar URL ends with errorcode 6 after he clicks login with SAML.

SAML reply when replicating the issue comes through as expected.

Workaround:

Remove user from 40 groups and now it works expected.

Bug:

SAML fails when user a member of too many groups