![]() 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. ![]() The point of the above is that clearly something is notable and knowingly different and bad on this point. 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. 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. 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. 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. 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. While the icon missing is not the largest issue, it is an indicator to us that "hey files are screwed up". 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. the glitch we are speaking of), the icons show just fine. ![]() When one fresh uploads files, before they are corrupted or delinked in some manner (i.e. we wouldn't care which of the 3 took priority, but just pick ONE vs NONE). 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. some sort of generic hand under a piece of paper shows in instead of the correct custom icon the. The icons of the Toolbox files are missing, once the files-not-running glitch occurs, i.e. 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. Files put here are removed when one closes the session. 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. The point is that a majority of launch-able files do not run. 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. exe) uploaded on the Toolbox do not run inside a remote control session. Many/Most files (especially with extension. 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. 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).Įither 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.
0 Comments
Leave a Reply. |