Powershell - Invoke-command does not run the msiexec.exe

Question

I want to install the TortoiseSVN-client on a bunch of servers, using Powershell remoting. Basic operations work, but the below command won't work as remoting

Invoke-Command -ComputerName myserver -ScriptBlock {Start-Process "msiexec.exe" -ArgumentList "/i \\fileserver\install\subversionclients\TortoiseSVN-1.14.0.28885-x64-svn-1.14.0.msi  /passive /norestart /qn ADDLOCAL=ALL" -Wait}

On the other hand, logging on to the server and issuing the following

Start-Process "msiexec.exe" -ArgumentList "/i \\fileserver\install\subversionclients\TortoiseSVN-1.14.0.28885-x64-svn-1.14.0.msi  /passive /norestart /qn ADDLOCAL=ALL" -Wait`

...that works. I have not been able to figure out why - no errors are shown, and no return value either. As I have understood Invoke-command it is elevated by default. Trying to add -Verb RunAs does not help either. I do also have the -wait-argument (ref. https://serverfault.com/a/550169/180067) but that did not help either in my case.

Answer 1

This is because you are using Kerberos authentication, and you try to perform a "double hop", and this is not possible by default with Kerberos (basically, you can authenticate to "myserver", but you can't "hop" again to "fileserver").

What you can do:

• Copy the file locally on the server, and then remotely install the MSI from the local directory.
• Or, if you don't want to copy it locally, you can use CredSSP instead of Kerberos to authenticate to "myserver", but this requires configuration. Add -Authentication CredSSP and -Credential "yourUserName" to the command, and follow the instructions shown in the error message.

Additional details, considerations, and different solutions are available here: Making the second hop in PowerShell Remoting

[...]You can use the Credential Security Support Provider (CredSSP) for authentication. CredSSP caches credentials on the remote server (ServerB), so using it opens you up to credential theft attacks. If the remote computer is compromised, the attacker has access to the user's credentials. CredSSP is disabled by default on both client and server computers. You should enable CredSSP only in the most trusted environments. For example, a domain administrator connecting to a domain controller because the domain controller is highly trusted[...]

and here to configure CredSSP: Enable PowerShell "Second-Hop" Functionality with CredSSP

On my client workstation, I need to use the Enable-WSManCredSSP cmdlet to enable the client role and then specify the computer to which I want to delegate my credentials. This command is shown here.

Enable-WSManCredSSP -Role Client -DelegateComputer *.iammred.net -Force

Now, I also need to make a change on the remote server to permit it to use delegated > credentials. This command is shown here.

Enable-WSMaCredSSP -Role Server –Force