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.

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.