Author Posts

April 8, 2018 at 6:14 pm

Good Evening,

We do not have Powershell remoting enabled for our enterprise and so I resorted to using psexec to install some software remotely.
If I run the following it works:

$Executable = IE.exe
$Arguments = /quiet
Start-Process -Wait -PSPath C:\PsExec.exe -ArgumentList "\\Test C:\$Executable $Arguments"

However if I run it like this:

Start-Process -Wait -PSPath C:\PsExec.exe -ArgumentList "\\Test C:\IE.exe /quiet"

It does not work, I believe this is because 'Start-Process' and 'PsExec.exe' interpret the argument list differently? Please could someone explain why putting the executable and arguments in a Powershell variable works but putting them as a literal string in the command does not?

Is there a way to troubleshoot what is causing the error?

April 8, 2018 at 8:29 pm

Why not just use GPO to install?
No script code required.
Why use start-process and psexec together? When you can just do it directly, eliminating any possible Start-Process conflicts.

psexec \\remote-pc -u “DOMAIN\Administrator” -p “password” cmd /c “msiexec.exe /i “\\server\share\application.msi” /quiet /norestart”

How to use Group Policy to install software remotely
'support.microsoft.com/en-us/help/314934/how-to-use-group-policy-to-install-software-remotely-in-windows-2000'

How to use Group Policy to remotely install software in Windows Server 2008 and in Windows Server 2003
'support.microsoft.com/en-us/help/816102/how-to-use-group-policy-to-remotely-install-software-in-windows-server'

Also, you'll note that your two samples are different.

– You specify a path in one but not in the other.
– Those variables need to be enclosed in single or double quotes to be seen as literal strings in the first one, just as you did in the second one.

Here's why – the added parens is to show the output of what you are storing in the varible with the use of Write-*:

    ($Executable = IE.exe)
    ($Arguments = /quiet)
    ("\\Test C:\$Executable $Arguments")


     ($Executable = IE.exe)
    IE.exe : The term 'IE.exe' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was 
    included, verify that the path is correct and try again.
    At line:1 char:16
    + ($Executable = IE.exe)
    +                ~~~~~~
        + CategoryInfo          : ObjectNotFound: (IE.exe:String) [], CommandNotFoundException
        + FullyQualifiedErrorId : CommandNotFoundException
 

     ($Arguments = /quiet)
    /quiet : The term '/quiet' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was 
    included, verify that the path is correct and try again.
    At line:1 char:15
    + ($Arguments = /quiet)
    +               ~~~~~~
        + CategoryInfo          : ObjectNotFound: (/quiet:String) [], CommandNotFoundException
        + FullyQualifiedErrorId : CommandNotFoundException
 

     ("\\Test C:\$Executable $Arguments")
    \\Test C:\ 

Vs...

    ($Executable = 'IE.exe')
    ($Arguments = '/quiet')
    ("\\Test C:\$Executable $Arguments")


     ($Executable = 'IE.exe')
    IE.exe

     ($Arguments = '/quiet')
    /quiet

     ("\\Test C:\$Executable $Arguments")
    \\Test C:\IE.exe /quiet



	
			
	

April 9, 2018 at 8:43 am

Hi postanote – I know we looked at this briefly before (on powershell.com) and to get around it I can use GPO or SCCM/LANDESK but it is bugging me. The first example I gave works, the second does not.

This works (without the quotes):

$Executable = IE.exe
$Arguments = /quiet
Start-Process -Wait -PSPath C:\PsExec.exe -ArgumentList "\\Test C:\$Executable $Arguments"

This does not:

Start-Process -Wait -PSPath C:\PsExec.exe -ArgumentList "\\Test C:\IE.exe /quiet"

April 9, 2018 at 8:27 pm

Hmm I seem to have got myself mixed up, you were right postanote, first one fails because of the missing quotes, I have just tried it.