Be able to specify guest side temporary save location for toolbox items in 5.5+

I'd also like to be able to go back to the way this was before. It's great that SC is trying to clean up behind itself but let's do that from a location of our choosing, and not within the client's documents. At the very least, the default location should be somewhere like ProgramData or just off the C: drive... somewhere out of their way.

Clean or not to clean... that should be an option! xD We are a Corp environment, kind of safe-tish one, so cleaning transfer tools is a waste, since we use it over and over again. YES: from the security standpoint, I rather put some file/size/cheksum/whatever to compare the file still the same and intact (no corrupted or modified-infested).

We just hit this issue upgrading from version 5.4 to 5.6. We are having issues when logged in as a locked down user (documents directory is not writeable) but mostly when user documents are redirected to a UNC path (causes issues with some scripts and also issues with standard user accounts elevating a tool to admin [the admin user cannot acess the user's documents directory]. Also it is annoying having to redownload a tool when switching users on the PC you are remote controlling (as each user cannot access the other user's documents).

Previously we had toolbox items going to C:\temp\support which worked great and I wrongly assumed that the 'FilesDirectory' setting in the App.Config would still override this 'new' methodology. To me this is a bug [FilesDirectory should override this still] but support fobbed it off stating it as a 'feature' and to post as a feature request here.

I would lile to see two new App.config options introduced - one to set the path of the toolbox items (or to follow the existing FilesDirectory setting like it used to) and another to enable or disable the automatic deletion of the tool after being run and closed. I see no reason programmatically why this could not be easily and quickly introduced to fix these issues.

Would be nice if the status of this could be stabilized.

I cannot beleive that this annoyance STILL hasn't been fixed. Toolbox doesn't work on two of our clients sites as they restrict writing to the users document folder to stop them saving files there. We called about this nearly two YEARS ago.

My issue I created a post for in regards to scripts running out of C:\Windows\Temp is a bit different than this issue.... This is related to the directory where tools are being ran in, I'm discussing scripts that SC attempts to run whether it be server side to generate video recordings from sessions or on a workstation to query data to put into the webui.... I suppose it could tie into this slightly....

Can this please be escalated so that a fix for this issue can be implemented into the next release.

It is still an ongoing issue that frankly should have been fixed long ago. I cannot see any technical reason why it could not be easily implemented with two app.config settings so that we can modify the default save location (away from the user's Document folder) and whether to clean up the folder on exit or not.

It is really tedious having to copy/paste files into a session because the toolbox logic is broken.

Seriously, can this please be re-implemented and released. It is extrodinary that absolutely nothing has actually been done in over 2 years other than bouncing around the status of this 'feature request' that is technically a bug fix.

'Considering for future release' really isn't good enough as this is functionality that existed and worked in version 5.4 but was removed. It should not be hard to implement an app.config setting to allow the pre V5.5 behaviour enabling it to work in enterprise and locked down scenarios again.

Please get this pushed through rather than procrastinating on it.

With Windows 10 1709 FCU, the Controlled Folder Access feature locks down the Documents folder even further making this a bit of a train wreck. We need to be able to root the Toolbox temp folder under %userprofile% 

With the feature turned on, when the .exe file is copied to the Documents folder that is fine, but if that tool creates an ini file then CFA prevents it from doing so and thus affects function. The only way around this is to let the tool fail, then go into the CFA settings and allow it. Doing this multiple times a session is a PITA !

I've come to the conclusion that nobody is listening any more. We've had phone conversations over several years about this but noone has ever don't anything about it. SC was supposed to save us time, though with this irritation still being ignored, as well as another major hassles resulting in having to use Sysprep rather that a quick copy of another PC, we've finally given up with this company. We won't be renewing.

Please restore this function, it was a good function or at least explain why it is not being re implemented, thank you.

This is an absolutely vital feature to allow the toolbox to function properly in a domain these days.. show me a single admin who doesn't redirect the documents folder to a server for centralized backup. Files will not launch from a UNC path that the system account does not have access to.

Or at least make the default path something that isn't commonly redirected like C:\Toolbox

The craziest thing is, Chris, that they DID put it in.  Around 5.5 and not for long.  It was there and then they took it away and wrecked it again.

I'll add my request in for this.  Users don't like their My Documents getting cluttered with stuff like this.

Our biggest issue here is if we wanted to leverage any of our internal scripts rather than just portable apps we need to be able to change this. Since many of our clients have their profiles redirected to OneDrive, our clients can go into their recyclebin and undelete anything we use from the toolbox and if it's our in-house code, be able to get all of our scripting that we consider to be intellectual property.

**** THIS. This is why this path in ScreenConnect needs to be configurable.

We have group policies that block storage of .exe files on the user's profile, meaning we have to .zip and extract any toolbox files to use them.  We really need this functionality to set the location for downloaded toolbox files to something like c:\temp.

Not being able to change this feels like such an oversight. Documents is frequently redirected to the user's OneDrive. I really don't want random exe files syncing in and out of OneDrive like that.

I’m wondering if there might be a way around this, and I'd like to open a conversation here.
But I need answer to this question: Where a tool/program from Toolbox is downloaded using Backstage?
I know I'm using System credential in Backstage (that actually is not a user/credential per se, so its folders are not in C:\Users). ;)

Good idea Kunta Kinke! If you work mostly on backstage as I do. The path for downloaded files/programs on user: System (Backstage) is c:\Windows\Temp. So nobody will go exclusively to sniff around in that folder, even then, you could easily apply temp cleaning after you are done with you job. Thanks for the idea! That help me a lot! 

That is a good idea Kunta, however that is not a solution when running scripts and importing registry entries that only affect the current user. The backstage user is not the current user.

You have to run the tool on the user's screen, and ever time you do, the user automatically gets their very own copy of your IT script/tool, backed up to the cloud so they can access it whenever and wherever they like.

This is really bad. Please give us the ability to configure where files from the toolbox are stored locally when ran, or at the very least change it from the user's documents folder. Why it's there in the first place is the result of a very poor decision.

I believe this option is available now, if you navigate to Admin > Advanced > Application Configuration > Other settings. Scroll down to "Directory settings"  I hope this helps 

You may need the "Advanced configuration editor" from the extension marketplace in order to see those config settings

Hi TopCat1121,

That only changed the directory name on the ScreenConnect server.

The problem is the directory location on the remote client.

P C

Any update on this? We use OneDrive for business and when running anything from toolbox it still copies over to C:\users\[user]\Documents\ and on completion OneDrive syncs the supposedly temporary file back to the cloud. Causes some hangups and I reckon there are users out there with a ton of wasted space in these folders.

+1 to this. The temp folder path is not consistent between endpoints in backstage and is causing issues for us. This would be fixed if we could choose the temp location.

For some it sends it to "C:\Windows\SystemTemp\ScreenConnect\24.3.6.9056\Temp".

For others it sends it to "C:\Windows\System32\config\systemprofile\Documents\Screen Connect Remote Control\Temp".

You cannot run 32bit programs from within System32, so on half of our endpoints we cannot use 32bit programs from the shared toolbox.

This does not seem to line up with documentation either Shared toolbox - ConnectWise.