Running a Setup.exe from a network share, via Invoke-Command in Powershell

Simon Bruun picture Simon Bruun · Nov 26, 2014 · Viewed 8k times · Source

PSEXEC started to give me some trouble, and I decided to recode in PowerShell.

This batch command used to work for me, before PSEXEC started messing things up:

psexec -accepteula \\<ServerToBeUpdated> -u <User> -p <Password> cmd /c "\\<ServerWithInstallationFile>\SystemEnv\Bin\Setup.exe /silent /Update"

I'm trying to do this with Invoke-Command in Powershell, but with no luck so far.

I've tried many combinations, and googled a lot, and overall it seems that PowerShell is not fond of the UNC path I'm trying to install from.

Here is what I've got:

Invoke-Command -ComputerName <ServerToBeUpdated> -ScriptBlock { Start-Process -FilePath "\\<ServerWithInstallationFile>\SystemEnv\Bin\Setup.exe" -ArgumentList "/update /silent" -wait }

I get this error message:

This command cannot be run due to the error: Access is denied.
+ CategoryInfo : InvalidOperation: (:) [Start-Process], InvalidOperationException
+ FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand
+ PSComputerName : DE5441

Some people say that the setup.exe has be copied locally on the remote server. But this does not seem to be an option for me, mainly for two reasons.

  1. My setup.exe identifies that it is not in the right path, then it kills the local the setup.exe process, and automatically starts a new setup.exe from the UNC path.
  2. I also need the ExitCode from my setup.exe, which gets lost when the "killing" starts as mentioned in reason number 1.

As a final note, I did grant access for PowerShell to run remotely with the Enable-PSRemoting command, and I also get expected results from this simple test:

Invoke-Command -ComputerName <ServerToBeUpdated> -ScriptBlock { Hostname } 

Answer

Paul picture Paul · Nov 27, 2014

You are experiencing a so called double-hop authentication issue. If using normal authentication you will not be able to authenticate to a second computer from the machine you are invoking the command on.

To solve this you can use CredSSP.

To enable CredSSP on the machine that is being called:

Enable-WSManCredSSP -Role Server -force

To enable CredSSP on the client:

Enable-WSManCredSSP -Role Client -DelegateComputer server.domain.com -force

The -delegateComputer parameter expects a FQDN but also takes wildcards.

After enabling CredSSP you can use it to invoke your command with the parameter -authentication CredSSP