CODEWITHSUNDEEP
powershellpowershell-remotingpowershell-5.0powershell-hosting
craigdfrench
craigdfrench

Reputation: 970

Getting Enter-PSHostProcess behavior via PSSessionConfiguration file

Scenario: Windows service with Powershell host embedded into it. Single runspace is allocated at startup. Multi-dll solution.

Requirement: Need to access .NET classes inside running service. From a local Powershell instance using 

Enter-PSHostProcess -Name MyService

...gives me exactly what I want since I can access the .NET classes. 

[MyNameSpace.MyClass]::CallStaticFunction()

Question: How can this Powershell behavior be made available to remote endpoints using Enter-PSSession to a custom endpoint? From the Register-PSSessionConfiguration we can specify a dll but this will spawn up a process and won't connect to a running instance. Not interested in writing proxy via HTTPS, or named pipes, but using the native functionality offered in Powershell for .NET support.

Is it possible to extend this via PSSessions? Or would we just have to first do Enter-PSSession or Invoke-Command?

Upvotes: 3

Views: 1226

Answers (1)

Burt_Harris
Burt_Harris

Reputation: 6864

Reviewing the sources it appears that Enter-PSHostProcess and Enter-PSSession are very independent mechanisms. Enter-PSHostProcess communicates via named pipes, while Enter-PSSession uses WinRM (which is effectively uses http(s) over ports 5985/5986. I don't think you need either Enter-PSSession or Invoke-Command if you want interactive access to a local service process through Enter-PSHostProcess.

You may have already done this, but to try this out I started up both Powershell.exe and Powershell_ise.exe, then from the former used this command to connect to the later:

get-process Powershell_ise | Enter-PSHostProcess

and the prompt changed to include the PID of the ISE. Just to be sure static methods worked as you are expecting, I killed the ISE from the Powershell.exe command line using the command:

[System.Environment]::exit(0)

Powershell creates the named pipe this connects to using the default security descriptor for the thread, which typically allows access only to LocalSystem, Administrators, and the account the process is running under. My test worked because both processes were running under the same account (I didn't need administrator priv.)

To be clear however, Enter-PSHostProcess makes no provision for connecting to processes on another machine. It might be possible to double-hop, connecting to the machine first using Enter-PSSession, then connecting to the process using Enter-PSHostProcess.

Upvotes: 4

Related Questions