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

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

Although there are multiple topics on similar items (1, 2, 3, 4,), none of these cover this new bug our users caught.

Guest (and host) OS is Windows 10.

Guest has a multi-monitor setup. Tested from 2 to 5 monitors attached. Using the native windows different wallpaper on each screen option, when connecting wallpaper is blanked. When disconnecting, only 1 screen returns wallpaper. If the same wallpaper is used on each screen, then issue does not occur on the same client.

The red dot is positioned after the description of the machine.  It is only visible if the Host page is maximized or stretched out to the right enough.

On a 1920x1080 monitor,

If anything less, it looks like this.  It gets covered up by the other elements in the page, elements that provide no information.

It would be more helpful (useful) if the positioning of the red dot were at the beginning of the description.

When launching ConnectWise Automate Web or Control web consoles, "Control" button doesn't launch the installed application and instead attempts to force re-download of the app.

getting the windows error asking to change the color scheme to windows 7 basic since upgrading to 6.1.