locked
Psexec & Powershell RRS feed

  • Question

  • Hi All,

    I'm attempting to run multiple netsh commands through Psexec via Powershell's Start-Process cmdlet. I've tried a few different things, but below is what I currently have which. I receive an error, 'group' is not a valid command. Not sure where my quotes are getting screwed up.

    $PsExecCname='\\prometheus'

    $command='cmd /c (netsh advfirewall firewall set rule group="File and Printer Sharing" new enable=Yes ^& netsh advfirewall firewall set rule group="Windows Management Instrumentation (WMI)" new enable=yes ^& netsh advfirewall firewall set rule group="Windows Remote Management" new enable=yes)'

    Start-Process -FilePath 'C:\windows\System32\sysinternals\psexec.exe' -ArgumentList @($PsExecCname,$command) -Wait



    • Edited by Sentri7 Tuesday, October 15, 2013 2:23 PM
    Tuesday, October 15, 2013 2:22 PM

Answers

  • Have you tried running your 'command' in a dos prompt all by itself?    I did, minus the first ' and last ' and i received this error:

    'group' is not a valid argument for this command.

    Until that command works in a cmd prompt, which is where you're telling psexec to run it, it won't work witih PSExec either.       I'm noticing the ^ in front of your & characters, which let you run multiple commands in one line on a command prompt.  Not sure what the ^ is for, but if you remove those, it'll work.   I tried it in my environment with just that fix, and I saw it run the 3 separate updates to the firewall rules.

    $PsExecCname='\\prometheus'
    $command='cmd /c (netsh advfirewall firewall set rule group="File and Printer Sharing" new enable=Yes & netsh advfirewall firewall set rule group="Windows Management Instrumentation (WMI)" new enable=yes & netsh advfirewall firewall set rule group="Windows Remote Management" new enable=yes)'
    Start-Process -FilePath 'C:\windows\psexec.exe' -ArgumentList @($PsExecCname,$command) -Wait


    Brian / ChevyNovaLN

    • Proposed as answer by Brian Busse Tuesday, October 15, 2013 4:10 PM
    • Marked as answer by Sentri7 Tuesday, October 15, 2013 7:06 PM
    Tuesday, October 15, 2013 3:10 PM

All replies

  • Have you tried running your 'command' in a dos prompt all by itself?    I did, minus the first ' and last ' and i received this error:

    'group' is not a valid argument for this command.

    Until that command works in a cmd prompt, which is where you're telling psexec to run it, it won't work witih PSExec either.       I'm noticing the ^ in front of your & characters, which let you run multiple commands in one line on a command prompt.  Not sure what the ^ is for, but if you remove those, it'll work.   I tried it in my environment with just that fix, and I saw it run the 3 separate updates to the firewall rules.

    $PsExecCname='\\prometheus'
    $command='cmd /c (netsh advfirewall firewall set rule group="File and Printer Sharing" new enable=Yes & netsh advfirewall firewall set rule group="Windows Management Instrumentation (WMI)" new enable=yes & netsh advfirewall firewall set rule group="Windows Remote Management" new enable=yes)'
    Start-Process -FilePath 'C:\windows\psexec.exe' -ArgumentList @($PsExecCname,$command) -Wait


    Brian / ChevyNovaLN

    • Proposed as answer by Brian Busse Tuesday, October 15, 2013 4:10 PM
    • Marked as answer by Sentri7 Tuesday, October 15, 2013 7:06 PM
    Tuesday, October 15, 2013 3:10 PM
  • Ah, I had this running in a .bat where the caret was needed to start a new line. I have absolutely no idea how I overlooked that here. Thank you!

    One other thing: is there a way to format the 'command' variable so I can split that up into a few lines? since the single string literals everything, is there a way I can get around that to line break?

    Tuesday, October 15, 2013 3:28 PM
  • I do not think there will be a way to make that look cleaner other than maybe breaking it up on multiple lines so you can read it better.  You're still going to end up with literals not showing context color coding in editors.

    For instance... one way to make it easier to read the commands at least would be to create an array of the commands and then piece them together.   I'm just playing around now... taking cleanliness completely out of the equation... this is a quick/dirty method that leaves an & at the very end, but it'll still work ;-)

    $PsExecCname='\\prometheus'
    
    function Combine-Commands($command)
    {
    $Combined = $null
    
        foreach ($item in $Command)
        {
        $Combined = $Combined + $item + ' & '
        }
    return $Combined
    }
    
    $command = @(
    'netsh advfirewall firewall set rule group="File and Printer Sharing" new enable=Yes'
    'netsh advfirewall firewall set rule group="Windows Management Instrumentation (WMI)" new enable=yes'
    'netsh advfirewall firewall set rule group="Windows Remote Management" new enable=yes'
    )
    $CombinedCommand = Combine-Commands $command
    
    
    Start-Process -FilePath 'C:\windows\psexec.exe' -ArgumentList @($PsExecCname,$CombinedCommand) -Wait



    Brian / ChevyNovaLN

    Tuesday, October 15, 2013 3:51 PM
  • Ah! Sneaky! I like the approach here, but to leave out complexity and to maximize efficiency of operation, I will probably just live with the super long one-liner. Nifty move right there, though! Thanks for all your help, Brian!
    Tuesday, October 15, 2013 4:00 PM
  • Ah, I had this running in a .bat where the caret was needed to start a new line. I have absolutely no idea how I overlooked that here. Thank you!

    One other thing: is there a way to format the 'command' variable so I can split that up into a few lines? since the single string literals everything, is there a way I can get around that to line break?

    Since you are starting a cmd.exe process anyway, why not create a batch file that contains the netsh commands you want to run remotely, and then change $command variable to execute the batch file? Don't forget that you'll need to include the -c parameter to copy the file to the remote system.

    That batch file is redundant, yes, but that is one way to avoid long commands. It also gives you a way to test the functionality/correctness of the commands outside of the context of powershell.


    Al Dunbar -- remember to 'mark or propose as answer' or 'vote as helpful' as appropriate.

    Tuesday, October 15, 2013 4:05 PM
  • Thanks for all your help, Brian!
    Anytime.   Glad I can help.

    Brian / ChevyNovaLN

    Tuesday, October 15, 2013 4:09 PM
  • Hi Al,

    Thank you for the response. What you're saying is definitely a viable option as well. I even thought to use the -f switch with netsh to call a script file to run, which also works.

    Tuesday, October 15, 2013 4:27 PM