+20
Under Review

Add Command Prompt tab to SC Session Windows

J T. Elliott 8 years ago updated by Peter OTools 6 years ago 15

I love the functionality of the system level command prompt from the Web GUI. Could this feature be extended to the actual session window as a tab? Would be incredibly useful.

+3

The reason this is a big feature request is because LabTech users don't open access sessions within the Web Portal...hence...no access to a command line interface through SC unless you open a browser and go to the Hosts page....kind of redundant

We're trying to fully ditch Bomgar which has this feature and a tabbed interface. Some of our hardest working techs are very sad to be losing those features, would love to see them in ConnectWise Control. Make it more than just a cosmetic branding change!

+3

The "Commands" feature is my favorite of SC which means I rarely need to open an interactive session. but when I *do* have to open a session, I should not have to go back to the browser (or waste time opening powershell or a command prompt) just to run a simple command.

-1

What is the limitation with opening a command prompt on the desktop of the guest machine? The host client is designed to be as seamless of an experience as possible with the guest, and therefore we would expect users to want to use the locally running command prompt as long as they're already in the session

+3

1) sometimes the user won't have access to run either cmd or powershell so without logging out and then back in as another user, that's not possible.


2) the commands feature stores my command history, which would grant me immediate access to the previous command i might need to run again.


3) the commands feature also stores a record in the log of exactly what commands were run, and their output which i personally need for auditing purposes.


4) through the use of extensions i can also manipulate commands behavior to effect shortcodes without having to install additional software.


5) the commands feature is already elevated. if i have to open an elevated interactive prompt on a corporate device, for example, then the user can kill my SC task immediately after it's run and will have a persistent elevated shell they can then use to abuse the device or potentially abuse the clients network with. 


6) on Win10 an end user without admin rights could just click the eye to see the password i enter when typing in the admin credentials as i am typing it.


7) not every command i run needs to be visible to the client. while some are as simple as dir and del, others will be sc delete or 'secret sauce' that include business logic or advanced functions that could be catastrophic in the hands of an unskilled user that might try to fix it themselves next time. 


8) by your logic, there's no reason to include the commands feature in the SC backend interface either, since the tech could always just login to the device, open a cmd prompt or powershell prompt, then run the commands. It's not that the feature is necessary, but that it would make things easier for us. if the goal for the software is to improve the tech experience, this would do that. at least for me.


9) ditto a few of those but replace 'end user' with 'hacker/malware/keylogger/malicious user/person who stole the device' and you'll see a couple more reasons why the user doesn't always need to see the commands (or even know a tech is connected)

Thank you for your thoughts. The Commands feature was originally intended to be most valuable out-of-session, allowing a technician to run one-time commands on one or many machines without needing to open a session. We will take your input into account as we look at the future development of this feature

+1

And as others have said in this thread, those using Control integrated with Manage and/or Automate don't really have access the CMD feature without independently opening Chrome and signing in to Control Server, as usually in Manage (or Automate) you just launch a Control session directly into the PC you want via it's Configuration / Computer info window.

-1

You are able to use a more fully integrated command prompt through ConnectWise Automate: https://docs.connectwise.com/ConnectWise_Automate/ConnectWise_Automate_Documentation/070/060/080

I prefer the Connectwise Implementation of CMD  for a number of reasons, including:


1. The ability to run multi-lind commands, ie:


cd c:\users

dir


2. Much much faster feedback of the command output compared to automate.

do you think silencing people on this platform will make our concerns go away? removing the post from jeremy.awecomm that specifically details why you should stop attacking users who make feature requests and bug reports only demonstrates that you are, in fact, doing that.

+2

Agreed. Huge benefit for us as we are on the LT hosted SC and we do not give our techs login access to SC, only indirect access through LT (between SC, LT, and CW, that's just too many local accounts - SSO or GT*O IMO). And now that making the SC shell interactive and adding PS support is a planned feature, we will be pretending the LT shell emulator does not exist.


+1!

Is this still under review? It's been awhile since there has been any updates, I too would love to see this feature implemented.

+1  For those Commands Tab limitations (even it has good spectrum of use for me, around 80% of the time on most basic stuff) I have to go via Psexec under Windows CMD to do other stuff remotely, like calling Diskpart. This might put those together and avoid getting out of SC to resolve part of the job. I'm in !