Backstage is great and would love the option to start connections in Backstage mode rather than having to interrupt a user only to switch to backstage.

One of the nice features of the Toolbox is to be able to add a portable executable. This is great provided that the executable is completely self-contained, however in many cases the tool might require one or more DLLs or other components. It would be great to be able to have a mechanism to associate a group of files to be downloaded to temporary space when a tool is invoked, so the tool can use them.

As an illustration, in the documentation for the recently released Backstage feature, it is suggested to add Explorer++ to the toolbox to provide a file manager within the Backstage mode. That's a great idea, except Explorer++ has a tendency to crash frequently, and it does not offer side-by-side panels. A superior alternative is a tool called Just Manager, which is a free portable file manager that does not crash in Backstage, has side-by-side panels, and is about a quarter the size executable. But the Just Manager exe program relies on a small DLL called IconPack. As such, if you simply click on Just Manager in the toolbox it will fail because the DLL is missing.

Now, it turns out that if you also add the IconPack.dll to the toolbox, and click it prior to clicking on Just Manager, ScreenConnect downloads the DLL to temporary space and subsequently if you click Just Manager it can find the DLL and run normally. However although this approach works, it is messy and not scalable, as there is no way for a user to know which DLLs go with which tools in the toolbox. What would be better would be to automate this process and hide the detail from the user.

One possible mechanism would be to encapsulate the files into a .zip, and add the .zip to the toolbox rather than the individual files. If such a toolbox entry is clicked, ScreenConnect downloads the zip file to the temp area, unpacks it, and runs the executable that has the same name as the zip file. So for example we could have justmanager.zip which contains both justmanager.exe and iconpack.dll (and perhaps other related files like a help file). ScreenConnect would unpack the whole thing into the temp area and then run justmanager.exe.

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. 

I'd like to request that both with when a session ID is generated at runtime (derived from mac address in the a absence of s= value in ClientLaunchParameters.txt with a custom install), and when using provided installers that injects a value in that file, that the session ID be equal to the hardware UUID. As reported in  Service Ticket#11461647, it is possible for the session ID generated from mac address to be the same across machines. When this isn't unique, suddenly people are unexpectedly connected to the wrong computer or can't connect to the computer they need since it only shows one of the computers with overlapping IDs at a time. This is embarrassing and a security risk. Anyway, regardless of the issues that come from overlapping session IDs when the session ID isn't stored in the ClientLaunchParameters.txt access client configuration, the other issue is if you re-install an access agent, the session id changes and you end up with a mess of duplicate session entries in the admin panel. One place the unique hardware UUID can be found is using `/usr/sbin/system_profiler -detailLevel basic`. I can't think of a good argument against using this value.

We just recently updated to 6.9 and backstage is amazing. Wanted to add a feature request for longer scroll back (buffer) in the command and powershell windows. Having no scroll back at all is quite limiting. Thanks!

In order to deploy macOS privacy preferences policy via MDM/DEP, the macOS app in Mojave that needs exceptions must be signed. Otherwise, a user has to create exceptions to allow remote control via ConnectWise Control, which isn't ideal. I don't want to have to sign your app to get the payload pushed out to create the exceptions from our management software. If you signed your apps like other developers, this would be much easier for all users, like those of the Addigy and JAMF communities. 

Many of my clients have several remote sites with many laptops moving between them.  I'm wondering if it's possible to add a feature so that I could identify the external IP address's of all the sites with a name, and that name would be displayed after the "Network Address" on the General tab.

The notification could be:

1. An email sent to the address users configured on the instance.
2. A banner notification on the web interface, similar to that display when guest machines need to be updated, which could be dismissed (and therefore the notification of that downtime no longer shown) on a per user basis.

Either or both of these could be implemented for the feature, configuration via the admin page or per-user preference as to if the banner and/or email should be sent to a user and the timeframe in advance of the downtime that the notification would be provided. The configuration would allow full spectrum coverage from customers that are not bothered about planned downtime that will switch off all notifications for all users, through customers that only want a single user to be informed, to customers that want all users to know about planned downtime.

Hello,

Installed SC 6.1.12292.6236 and now PrtScn and Alt+PrtScn button presses no longer copy the screen to the host clipboard. This is a very drastic change in behavior, and makes it much more difficult to quickly capture images of issues from remote guest machines.

After contacting support about this bug, your agent said the data is now added to the remote guest clipboard instead of the host clipboard. This seems great for a remote worker, but not for the rest of us using SC for client support. I was also displeased by your agent suggesting that we start using third party software to take screen shots. I also think many clients don't want the hosts dumping large screen shots on to their clipboards. The guest vs. host clipboard use should be a configuration option instead of making SC harder to use. Or at the least, copy the screen data to both clipboards instead of degrading the software for so many of your customers.

Thanks,

Tim

As of my knowledge, there's currently no way to split a multi-monitor remote connection into multiple window.

This features would help a lot to manage multi-monitor connection.

When the remote users have a more than one monitor it scales down the dimension of our connection and it's hard to manage efficiently.