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

Avatar
  • updated
  • Considering for Future Release

From CW-7637203:

Would like to customize the temp location where "As of version 5.5, when you run a tool from the shared toolbox, the tool will be downloaded to a temporary folder on the guests machine. When the session has ended, ScreenConnect attempts to delete the downloaded tool from the temporary folder."

Duplicates 3
Relocation the Toolbox Default Download Location

I find that using the ToolBox and getting the programs to download in the User Document folder is not the correct place. Can we have a feature to us a customer location.

For example all our tech us a folder C:\TechTools\ I would like to move it so if a Tech uses the ToolBox is goes to this location. 

Scripts executed by SC to not run out of C:/Windows/Temp

I haven't seen anything else like this but we are utilizing antivirus with script control features, Which basically blocks any/all scripts that we don't allow.

That being said the only way we can whitelist at this time is based on the working directory, And it appears they are running out of the windows temp dir, Is there any way this can be changed to have the scripts run out of an alternate directory? I have a couple of plugins installed but sometimes when I first connect into a session it triggers the script control and I'm not sure what is running. but its basically 20170313xxxxxxxxx_temp.vbs is the formatting of the files that run, or try to I should say.

Same goes with when we attempt to convert screen recordings on the SC server, it runs a script to do it and script control blocks it and there is no way we can whitelist it other than disable script control or allow everything through the windows temp dir which is just a terrible idea.

Change Shared Toolbox Download Location

We would like a way to choose where the files are downloaded when using the Shared Toolbox.

Currently it is default to My Docs on the user's profile.


Looking to either specify a location when downloading or be able to change the default download location.

Avatar
3
Xander Warrender

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.

Avatar
0
anonymous
  • Started
Avatar
0
anonymous
  • Planned
Avatar
0
anonymous
  • Under Review
Avatar
2
Peter OTools

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).

Avatar
0
anonymous
  • Pending Review
Avatar
2
Dion

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.

Avatar
0
anonymous
  • Under Review
Avatar
0
anonymous
  • Pending Review
Avatar
1
anonymous
  • Under Review


Top contributors

Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar