Powershell: PSRP WSMan client library to C#

[SteveL-MSFT]

PSCore6 currently depends on OMI native client library for non-Windows to remote PSRP over WSMan. This library currently has a number of limitations and issues. To continue to support WSMan based remoting, we should consider writing a new library in managed code. It also appears that corefx supports Kerberos/NTLM over HttpClient so that should solve one of the immediate limitations with the native library. This library should also be a generally useful public api on nuget for other languages to remote into PowerShell via PSRP.

[iSazonov]

For reference psl-omi-provider
Seems there are no tests. Without them, porting will be problematic.

And should the new library be used on all platforms including Windows?

[SteveL-MSFT]

@iSazonov tests is lacking which is why we get reports of issues that should have been caught by tests. In this case, we would add tests along with this porting work. We would probably use the same library on downlevel Windows that doesn't have WMF4+, however, this library isn't expected to have full parity with WinRM (at least initially) so relying on WinRM in those cases would make sense. Long term, it would make sense to have a single library for all platforms.

[iSazonov]

In which repository should this be done?
We need at least a test environment.

[SteveL-MSFT]

@iSazonov I created https://github.com/PowerShell/PSRP-Client-Library if you want to experiment. cc @PaulHigin

[PaulHigin]

If we want to create a new managed version of WSMan client, then I feel we should start with an RFC.

[iSazonov]

... and continue with tests :-)

Seems it will be large and complex RFC.

[SteveL-MSFT]

I agree with @PaulHigin that the intent here is:

1. remove dependency on omi-psl-provider native library
2. provide public api to create remote PSRP session (I'll rename it to PSRP instead of WSMan specific)

So it would make sense to have an RFC for the apis.

[iSazonov]

How this correlate with https://www.dmtf.org/standards/ws-man ?

[SteveL-MSFT]

@iSazonov PSRP over WSMan relies on the PowerShell Remoting Protocol which is built on top of WS-Man (or SSH now in PSCore6) which is the same as the one you linked to. WS-Man is a SOAP based protocol that goes over HTTP(S).

[iSazonov]

So we should port this client and get direct dependency on native OMI library?

[SteveL-MSFT]

@iSazonov the goal here is to remove dependency on OMI library altogether and just have C# code

[iSazonov]

I see OMI project is actively updated. Shouldn't this issue be addressed there? I mean OMI client library ported at first in OMI project? What is a reasonable compromise?

[PaulHigin]

PowerShell remoting uses OMI only as a bridge for non-Windows platforms. Its support of WinRM client is incomplete and problematic. My goal is to completely remove OMI as a dependency. I agree with @SteveL-MSFT that the best way to do this is to investigate implementing WinRM client in cross-platform managed code, resulting in an RFC that outlines the work required.

[iSazonov]

It seems I started to understand :-)

1. We really will not have a conflict with the OMI project?
2. Having two client (Windows (WMF) and the new one on Unix) is seems a problem too. CoreFX reimplemented HttpClient to exclude curl and get the _same behavior_ on all platforms.
   I assume that we are doomed to the same thing - to have single managed WinRM client library for all platforms including Windows 10 (not only Windows 7 without WMF4). In other words, PowerShell Core uses the new managed client, Windows PowerShell uses WMF client.
   It even simplified development that could be done on Windows.

[SteveL-MSFT]

@iSazonov I've had discussions with the OMI team internally and there is no conflict or overlap. We should use the same client code for both Windows and non-Windows although that would not happen initially as some capabilities we get from WinRM are not a priority for non-Windows.

[iSazonov]

@SteveL-MSFT Could you please update the issue description and title that we want to implement WinRM client on managed code?

Is there someones (firms) to whom this may be useful and who could be contribute/test? You could blog post to announce the new project.

Also I hope your team prepares the RFC (I have no idea who else could do it.)
Currently, I can only review a code in the repo and maybe reorganize/cleanup it to make it easier to add the new experimental code.

[SteveL-MSFT]

@iSazonov I think this specific item is pretty specialized and complicated so unlikely for someone in the community to be able to contribute. Since we have the new repo for this work, I'm going to close this item. It's not blocking at this time, but will become blocking in the future if more customers want to use PSRP over WSMan from non-Windows.

[iSazonov]

Today I researched this a bit and came to the conclusion that it could be useful for other projects on managed code. There is nothing on GitHub like WSMan on C#. I hope the project will not be frozen for a long time. Ping me when it will start.

[SteveL-MSFT]

@iSazonov to set expectation, I don't expect to start on this until at least April 2019

[iSazonov]

@SteveL-MSFT @PaulHigin What is a status of "WSMan on C#"? We receive continuous issues for remoting from Unix-s.

[sakno]

Guys, any progress on this?