0

I have a custom PowerShell commandlet that I have created in C# that spins up some instances of vstest.console.exe and publishes the test results to a .trx file or to tfs. This commandlet works in isolation when using PowerShell locally.

However when I run the commandlet remotely using v3 PowerShell remoting, The invoke-command completes, but there are 2 issues:

  1. The test run process does not complete as there is no results file published
  2. I do not get the results on the remote console, whereas in the local case they bubble up from the newly started processes

Here is the remote call I used in the remote PowerShell calling script

$j = Invoke-Command -Session $currentPSSession -AsJob -ScriptBlock {
    Add-PSSnapin "IntegrationTestTools"
    Start-IntegrationTests -someotherUnimportantArgs
} | Wait-Job

$results = $j | Receive-Job

from stepping through the script it does indeed wait for the job, however the results are empty.

To note I have setup the remoting as per Keith Hill's post . Also I have setup Wsman with

set-item WSMan:\localhost\Shell\MaxMemoryPerShellMB 0
set-item WSMan:\localhost\Shell\MaxProcessesPerShell 0
set-item WSMan:\localhost\Shell\MaxShellsPerUser 0

So processes and allowed memory should not be limiting this particular exercise.

Any ideas?

JoeKir
  • 1,087
  • 9
  • 20
  • 1
    Just to make sure you're referencing the right job object do this `$job = Invoke-Command ... -AsJob ...`. Then `Wait-Job $job` and `Receive-Job $job`. Also, is the snapin bit-specific (32-bit or 64-bit)? – Keith Hill May 01 '13 at 20:21
  • Thanks Keith, I did actually change how I got the job object prior to your response, I updated above. The snapin is registered in both x64 and x86 on the target machine. From monitoring task manager, the process that my commandlet calls spins up for 60 seconds exactly and then gets killed off. So I'm trying to determine what is causing that timeout. Do you know of any WSMan settings that may cause this for subprocesses? – JoeKir May 01 '13 at 20:51
  • Do you think this could be the cause of it? http://msdn.microsoft.com/en-us/library/e0c5127e-b10c-4be5-9e03-346806fb7a28#endNote130 – JoeKir May 01 '13 at 20:56
  • Not sure. You could try changing the value. BTW what happens if you run this wiht the PSSession configured to use localhost? Just trying to eliminate some variables. – Keith Hill May 01 '13 at 21:21
  • Yes if I use `$currentPSSession = New-PSSession localhost`, running the script on the target machine, then the subprocess called by the commandlet still exits at the 60 second mark. – JoeKir May 01 '13 at 22:39
  • And if you try using the microsoft.powershell32 endpoint in the session configuration, does it also fail? – Keith Hill May 01 '13 at 22:49
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/29273/discussion-between-joekir-and-keith-hill) – JoeKir May 01 '13 at 23:41

1 Answers1

2

I thought I'd share in case anyone is unlucky enough to have this happen at some point. If you use credssp as authentication enum when connecting to a remote PowerShell session, your user token is marked as "impersonate", this means that you are part of the NETWORK USER group which means no visibility of WCF named pipes as the SID 5-1-5-2 (more commonly known as the Network SID) is denied access to named pipes. Here's an enlightening article on the subject: KennyW's blog.

The process I was remotely starting with my PowerShell commandlet started child processes that were communicating over named pipes :(
So in the end had to psexec (sysinternals) as system to get that process to execute locally within the remote session. Not elegant but it was all I had available.

Also thanks to Keith Hill for his help with the PowerShell troubleshooting!

My blog article detailing my findings - http://josephkirwin.com/2013/05/06/the-named-pipes-had-a-party-and-imposters-were-not-invited/

JoeKir
  • 1,087
  • 9
  • 20