Welcome to our community!

Run a command as a separate / background process

Avatar
cps
  • updated
  • Under Review

Running a client-side command via the Commands tab is limited not only by amount of output but also by time. In other words a command run at the prompt will be killed if it exceeds a web.config specified period of time (10 seconds by default). It is quite common to want to run a command that takes longer than 10 seconds. For example, I have a disk cleanup powershell script that I push to clients that can take 10-12 minutes to run. Changing the default timeout period in web.config is not a good solution to this problem, as the system essentially hangs waiting for the command to complete.


Suggestion: offer an option to run the command as a spawned / background process on the client, similar to running a program or batch script via the START or CALL commands (and suppressing the pop up of a command window on the client). Thus, the command will execute on the client without tying up the Commands tab. An additional enhancement would allow for capture of output to a log file and emailing the result to the technician upon completion of the command.



Replies 10
Avatar
0
anonymous
  • Under Review
Avatar
1
Darren K

Please do this and also tag commands with a unique id so we can tie requests/responses together. 

Avatar
0
Douglas Byrd

Please do this

Avatar
0
Caitlin M Barnes Team Member

Hi All, 

Late last year we introduced Backstage mode, which allows host to complete Windows terminal and powershell commands on the remote machine without interrupting the end user. Take a look at the documentation link above, it sounds like our Backstage feature meets this request!

Avatar
0
Darren K
Quote from Caitlin M Barnes

Hi All, 

Late last year we introduced Backstage mode, which allows host to complete Windows terminal and powershell commands on the remote machine without interrupting the end user. Take a look at the documentation link above, it sounds like our Backstage feature meets this request!

This doesn't solve the problem. Backstage mode has a lot of problems, specifically it is very difficult to paste long scripts into the terminal that is opened. Because it is in session 0, many UIs don't build correctly, specifically PowerShell ISE. I think what users really wanted (which you'll see in other feature requests) is to have a larger terminal window that works conceptually similar to the terminal window on the web UI, but built into the client itself that we can paste large PowerShell scripts into and have them run consistently without user interruption.

The issue we are specifically asking for here it for you guys to not jam up communication to the agent service on the target machine when executing commands.

Avatar
0
cps

Hi Caitlin,

Yes and no.

Backstage mode is a truly awesome innovation and is much appreciated. It certainly provides a practical means for running commands on a given device (and much more) without locking up access to the remote machine until command completion or timeout. We use it daily.

What it does not do is provide a mechanism for running a command across a group of machines. Let's say I have a command sequence that I want to run on 500 machines. I can select those machines and run the command(s) against the group, but each machine will be subject to the present limitations of the Commands tab. Further there is no way to capture the output for later analysis.

Avatar
0
cps

Darren: You make a good point about being able to paste commands on the fly and to have a less cramped terminal window with which to operate.

You can put the command script into a file and put it in the toolbox, and then run it from Backstage. This make sense if it is a script that will be used repeatedly and/or on multiple computers at different times, but using the Command tab to paste the commands is quicker for one-off situations.

In summary I would say Backstage overlaps this feature request. In many ways it goes further, while in other ways it does not fulfill  it.

Avatar
0
Darren K
Quote from cps

Darren: You make a good point about being able to paste commands on the fly and to have a less cramped terminal window with which to operate.

You can put the command script into a file and put it in the toolbox, and then run it from Backstage. This make sense if it is a script that will be used repeatedly and/or on multiple computers at different times, but using the Command tab to paste the commands is quicker for one-off situations.

In summary I would say Backstage overlaps this feature request. In many ways it goes further, while in other ways it does not fulfill  it.

The problem with the toolbox approach is it doesn't harvest the results from the scripts, and it would be clunky to execute programatically (adding a tool to the box, waiting for all machines to finish executing before removing it, etc) You'd end up with a bunch of old scripts cluttering your toolbox.

Avatar
0
Patrick S

Please implement this.

Avatar
0
Patrick S
Quote from Caitlin M Barnes

Hi All, 

Late last year we introduced Backstage mode, which allows host to complete Windows terminal and powershell commands on the remote machine without interrupting the end user. Take a look at the documentation link above, it sounds like our Backstage feature meets this request!

This does not answer the request. We need one of the two options, or both:
1. An option in the "Run Tool" dialog that will run the tool/script in the backstage environment.

2. Running commands with unlimited or adjustable timeout (say 0-60 minutes).



Top contributors
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar