Add Command Prompt tab to SC Session Windows
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.
Welcome to our community!
Replies 15
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.
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.
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.
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
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
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)
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
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