We use azureAD for authentication, would be great if the same was available from the Connector desktop application. It's not useable for us at its current state as we don't have internal users.

Just allow a hidden url, ie. mycompany.screenconnect.com/login

Right now I can elevate a script either from the UI or the toolbox.  I cannot elevate a 1 time command.  Please add the ability to elevate on demand commands from the UI so there is consistency with scripts.  The logic here is when I need to apply updates or something like that, I want to be able to run on multiple boxes at once.  I DO NOT want this in our toolbox as a script anyone can run on our customers computers.  

Able to see customer names and events that are happening on the system all in one report.

Would be nice to get this, as we're paying for it.

On Linux systems running systemd currently no unit file is generated for the guest service thus if the service crashes the init system will not restart it.  This is simple to do, and offers a simple way to automate service recovery which is important given ScreenConnect (Control if you must) might be the only way to access that system.

Also, the service is not started automatically after install via .sh file and it should be.  No one installs ScreenConnect and doesn't want it running.

Option to Require host passes to be sent via email (no copy link option) for specific machines or session groups
Option for a pass holder/guest to use their email address to view active host passes from the host site

Option to Notify pass holder that the host pass will expire soon sent to the same email address

Option for pass holder to request an extension of their pass

Option for Host to approve or deny requests to extend

Option to limit the number of times a pass can be extended

When I connect to a Server 2016 Datacenter server with screenconnect I have a black screen.  If there is an active RDP session on the server I am able to select it from view-select logon session and I can work from that session.  If I switch back to the console it is a black screen.  I've tried restarting the screenconnect service, reinstalling screenconnect, etc.  It appears to be an issue with console session itself but I've been unable to find any way of

The previous support forums were archived and the url  http://controlforum.connectwise.com no longer works, even though on the new forums it says the archived pages exist. There is import information in there on how to do things the new forums do no have. Support has been unable to help me as well and told me they can't access the old pages to look it up. Can someone please fix this and allow us access to the old support forums?

We are using latest 21.3 version of ConnectWise Control (CWC) (and also symptoms occurred on older versions and have been occurring in one form or the other for 6 to 12 months).

TOOLBOX ISSUES:

Either after receiving the often-sent email notification with SUBJECT "The IP Addresses for your ConnectWise Control Cloud Server have Changed" and/or perhaps randomly/nightly/every-so-often-days when ConnectWise (CW) antivirus scanner "touches" toolbox files .....we cannot determine which of the above causes the below issues but it is likely one of the 2 of these due to timing we've logged when the glitches happen ....

ISSUE #1 ==>

Many/Most files (especially with extension .exe) uploaded on the Toolbox do not run inside a remote control session. There is a higher chance they do if they are smaller in size as in KBs instead of MBs and/or sometimes after trying the same file numerous times in a row. The above is just an observation. The point is that a majority of launch-able files do not run. The normal process when a Toolbox file runs is that it first secretly downloads into the remote session computer's My Docs folder -> whatever custom CW subfolder based on the product's customized name -> Temp .....then it runs. Files put here are removed when one closes the session. Anyway, when the hey-it-won't-run symptom occurs, one notices that the file doesn't even download there as is normal, so of course it never runs.

ISSUE #2 ==>

The icons of the Toolbox files are missing, once the files-not-running glitch occurs, i.e. some sort of generic hand under a piece of paper shows in instead of the correct custom icon the .exe or whatever extension per the OS and it's default opening app would normally show (based upon your PC or the remote session PC or CW's server decision ....we wouldn't care which of the 3 took priority, but just pick ONE vs NONE). When one fresh uploads files, before they are corrupted or delinked in some manner (i.e. the glitch we are speaking of), the icons show just fine. This clearly means CW's Windows/Linux/proprietary AWS server where the files go can clearly get the icon AND RETAIN IT JUST FINE for hrs/days until the corruption or delinking occurs. While the icon missing is not the largest issue, it is an indicator to us that "hey files are screwed up" ....also, to be frank, with many files, especially as a remote tech support company, it wastes time to not be able to quickly identify by an icon type what type of file it is, especially since some files slightly too long get cut off in the Toolbox view without efforts to see them. So, imagine one has two files with the same name, maybe cutoff in length of the name shown slightly with the same generic icon, yet one is really a .txt file and one is an .exe file ....well the difference of running an .exe vs a .txt is no small matter. Also, when one is moving fast and troubleshooting something, visual identification in a millisecond of a file type is innate in grabbing the right file, such as a .pdf vs a .zip or whatever. So, actually the icon thing we do feel can be classified as a “big deal” as it’s inconvenient and inefficient to not see unique icons -- just like the Toolbox correctly/happily shows at least for hrs/days until the glitches start happening. Before whatever within the last year move CW did to newer AWS severs and/or newer AV scanner and/or newer we-don't-know-but-you-all-do changes happened 6 - 12 months ago on the Toolbox storage and code surrounding it, icons worked JUST FINE AND STAYED WORKING JUST FINE. The point of the above is that clearly something is notable and knowingly different and bad on this point. It needs to be made clearly by CW what it is, why it is, and why it cannot go back to the way it was when it had no issues for years.

ISSUE #3 ==>

Similar to what was writing on this existing CW forum -- https://control.product.connectwise.com/en/communities/6/topics/3266-toolbox-deploy -- when the symptoms occur, often if not always, the download rectangle (that happens before the Toolbox file "runs" in the remote session) stays at 0%, indicating unhappiness and an inability to somehow "find" the Toolbox file.

SUMMARY NOTES ON ABOVE ==>

There have been documented/well-known internally at CW issues with Toolbox bugs starting approx a year ago or so (give or take some months either direction). This seemed to have started with various code updates and/or CW antivirus mucking up things and/or when Toolbox files were stored in some sort of newer AWS container/method/repository or something of this concept. There were months where the bugs above or similar ones were "fixed" but then not fixed and then "fixed again" and then finally acknowledged on bug fix change logs and then forgotten yet not fixed and finally just simply not discussed anyway anymore (implying they were fixed even though they could clearly be seen not to be).

We ourselves have reported these glitches on various support chats, tickets, on and off for the year or so since the issue was first noticed (by us likely) and when it finally was acknowledged partially in change logs/KB's at the time. We believe the above bugs are not new and have been occurring in one form or the other since then. They may or may not be caused by certain circumstances, certain file name lengths in the toolbox, certain extensions, certain simultaneous circumstances or other things of this sort which is why perhaps not everyone has the issues or notices them. Again, we suspect either the AV scanner is the culprit and/or the IP change aspect (causing some sort of "delinkage" of the Toolbox files to the account that moved PERHAPS but this is a theory as we have no access to the backend to verify or test).

When the bugs above occur, we've tried all browser brands, all new and slightly-not-new versions of all browsers, from multiple cities, multiples ISPs, on multiple Operating Systems, i.e. the bugs are not imaginary nor are they only on one browser/PC/oh-hey-clear-your-browser-cache goofy level -- and we are a high level IT company, so we've tested many ways to rule out stupid’s with different technicians.

The only solution seems to be to reupload affected Toolbox files (which are most of them), which, if one has many in many folders, is excruciatingly tedious and time consuming, especially when the bug reoccurs again and again every few days or so on average. Like many who use the Toolbox, we need it to just work without babysitting it or not having critical tech support used files for our customers not available on a random whim when a remote support rep of ours needs it.