5

I'm trying (under Windows 7) to use the runas command to stop then restart a service. (Win7 requires admin privs to do this; thus the use of runas.)

Stopping the service works fine, but starting it does not. Here's the command I'm using for stopping the service:

runas /user:myDomain\myUserId "net stop serviceName"

Here's the command for starting the service:

runas /user:myDomain\myUserId "net start serviceName"

When I run the above command another command window opens, but flashes away before I can see anything in it; thus I have no idea what's going wrong.

So, my question is: How might I capture stdout and/or stderr from the net start command when run via runas? I've tried just using redirection but just get an empty file. Another solution would be to get the window opened by runas for the subtask to remain open.

Thanks in advance.

4 Answers4

10

Launch cmd.exe instead with the command to run, and specify that the output be written to a file.

runas /user:myDomain\myUserId "cmd.exe /c net stop serviceName > output.txt"

You can use 2> for error output from net stop.

Michael
  • 54,279
  • 5
  • 125
  • 144
  • 1
    this does not work for me. I am doing "runas /user:username "cmd /c time > output.txt"". If you could help me understand why this doesnt work it would really do me a favor! – Feytality Jan 05 '16 at 18:58
  • what directory does output.txt appear in? – user3450049 Nov 02 '19 at 00:15
7

Also, if you don't want to bother with the output file, you can use cmd.exe /k instead of /c to launch the command and it will leave the session window open for you. Might be easier/quicker if you just want a quick peek.

Just some guy
  • 81
  • 1
  • 1
  • 2
    Next time write this kind of response as a comment, as it is related to another answer. As the order of answers may change later on, it would be difficult to reconstruct your answer. – decden Apr 17 '13 at 15:25
0

Try gsudo and run the command:

gsudo net stop serviceName
tim
  • 2,530
  • 3
  • 26
  • 45
0

I see this is a very old question, but I see there has been recent activity on the topic. Since this is an issue I too have experienced with the "runas" command of Windows command line, I wanted to share my preferred solution and explain some of the nuasances that necessitate the seemingly convoluted approach.

First off, we can capture the results from the standard output and standard error streams from executing the command with the runas command if we invoke the command with a new command interpretter shell as mentioned by Michael and SOME GUY.

I wish to add to the answer since in my use case, I was running a very similar command as part of an automated routine, and I did not want the window stealing focus (as "modal" windows do) nor did I want the window in the way, but I did wish to have a small visual queue the task had run and the results were awaiting being reviewed and dismissed. To solve this I did

runas /savecred /user:myDomain\myUserId "cmd /C start /MIN cmd /C """net stop serviceName ^& timeout 1800""" "

There are a few nuasnaces to the approach that caused me a great deal of grief as I formulated this approach:

  1. The use of the start command is desired so that I can run the command MINIMIZED so the modal command console will not steal focus. Only the start command allows the command to run in a minimized window (of purely command console approaches not inclusive of PowerShell, WMI/WBEM/CMI or scripts (VBS or WindowsScript, be it cscript or wscript invoked)

  2. The start command is part of the command line interpretter (compiled into the command shell). I, therefore, have to invoke two command shells -- one to run the start command and a second to run the command whose output we wish to capture in a command console and not a file, even if only temporarily as I have shown.

  3. Unlike the very similar start and cmd commands, the runas command always requires quotes which also brings me to a 4th quirkiness of the purely command line approach...

  4. The quoted string for the runas command must escape characters with carets and not backslash. An exception is double quotes which can be escaped as triple double quotes (making commands rather difficult to read).

It isn't a very elogant solution and isn't suitable for a large number of use cases, but I found it very useful for running automation from an account I also sometimes do other things. In this manner, I can keep accounts to a minimum on my home PC and yet I can run scripted automated tasks without an ultra reliance on Windows Scheduler which has had some quirks of its own, but especially the immediate standard output stream and a standard error streams that you and I desire (at least not without configurations that land us right back at essentially this same approach).

I hope this helps save someone some frustrations down the road though in an era when PowerShell is very quickly replacing the antiquated command console, it may not. That's ok. Since PowerShell has an exceptionally large vocabulary and syntax compared to the considerably lighter command console, I think the command console has at least a little life still left in it.

Charles
  • 338
  • 3
  • 8