Toolbox Issues: Files Not Running + Icons Missing + Copy File 0%

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.