There was WG conclusion about root of the issue #6321 (comment)

There was WG conclusion about root of the issue #6321 (comment)

I think Paul may have been confused there, Get-PSSession -ComputerName is and has always been focused purely on WSMan. It sends a SOAP request to the WSMan service to ask it to enumerate the number of shells open and has it return that list. There is nothing here that can be replicated under ssh and even if there was it would be part of a new -HostName parameter to match up with how other PSRemoting cmdlets like Invoke-Command and Enter-PSSession. In short getting -ComputerName to work on non-Windows requires the PowerShell team to start shipping the Microsoft.WSMan.Management module on non-Windows which requires more work with the omi library to get working properly. They've repeatedly said in the past they have don't want anything to do with WSMan anymore so instead of waiting forever for this to be re-implemented I thought at least a better error saying this only works on Windows is best.

This PR has 19 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Label      : Extra Small
Size       : +18 -1
Percentile : 7.6%

Total files changed: 3

Change summary by file extension:
.cs : +15 -1
.resx : +3 -0

Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

Hmm, I see Paul said that we can enumerate any PSSession objects which was created in current process.

Yep and using -ComputerName is for sessions on a completely different host. In fact it uses a mechanism in the WSMan service and not PowerShell itself to track the sessions on the remote host. Maybe how PowerShell tracks that information can be expanded in the future but it shouldn’t hold up something like this.

@jborean93 For my education, does -ComputerName return all remote pssessions on the remote computer or only sessions created from the current pwsh process?

When you do Get-PSSession -ComputerName foo PowerShell internally runs the following:

$getParams = @{
    ResourceURI = 'Shell'
    Enumerate = $true
    ComputerName = 'foo'
    SessionOption = (New-WSManSessionOption)
}
Get-WSManInstance @getParams

In protocol terms this sends the following WSMan POST message to foo:

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:n="http://schemas.xmlsoap.org/ws/2004/09/enumeration" xmlns:w="http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd" xmlns:p="http://schemas.microsoft.com/wbem/wsman/1/wsman.xsd" xmlns:b="http://schemas.dmtf.org/wbem/wsman/1/cimbinding.xsd">
  <s:Header>
    <a:To>http://foo:5985/wsman</a:To>
    <w:ResourceURI s:mustUnderstand="true">http://schemas.microsoft.com/wbem/wsman/1/windows/shell</w:ResourceURI>
    <a:ReplyTo>
      <a:Address s:mustUnderstand="true">http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</a:Address>
    </a:ReplyTo>
    <a:Action s:mustUnderstand="true">http://schemas.xmlsoap.org/ws/2004/09/enumeration/Enumerate</a:Action>
    <w:MaxEnvelopeSize s:mustUnderstand="true">512000</w:MaxEnvelopeSize>
    <a:MessageID>uuid:B03C7765-66AC-4DAB-B84D-BC62464A1AC8</a:MessageID>
    <w:Locale xml:lang="en-US" s:mustUnderstand="false"/>
    <p:DataLocale xml:lang="en-US" s:mustUnderstand="false"/>
    <p:SessionId s:mustUnderstand="false">uuid:00DC848B-B247-485C-B144-EB709AA1586A</p:SessionId>
    <p:OperationID s:mustUnderstand="false">uuid:CB4C0368-D3A8-45D0-AE6E-2C1B90FAD70E</p:OperationID>
    <p:SequenceId s:mustUnderstand="false">1</p:SequenceId>
    <w:OperationTimeout>PT60.000S</w:OperationTimeout>
  </s:Header>
  <s:Body>
    <n:Enumerate>
      <w:OptimizeEnumeration/>
      <w:MaxElements>32000</w:MaxElements>
    </n:Enumerate>
  </s:Body>
</s:Envelope>

This Enumerate action tells the WSMan service on foo to return all "shells" that have been opened on the service. Note there is no client information like the process or host it is from which means foo will be returning all shells it knows about. After receiving this request foo will return the following EnumerateResponse

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:n="http://schemas.xmlsoap.org/ws/2004/09/enumeration" xmlns:w="http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd" xmlns:p="http://schemas.microsoft.com/wbem/wsman/1/wsman.xsd" xml:lang="en-US">
  <s:Header>
    <a:Action>http://schemas.xmlsoap.org/ws/2004/09/enumeration/EnumerateResponse</a:Action>
    <a:MessageID>uuid:142D87D6-7CBC-4E9E-9D4F-95CD0EE5CAA2</a:MessageID>
    <a:To>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</a:To>
    <p:OperationID s:mustUnderstand="false">uuid:CB4C0368-D3A8-45D0-AE6E-2C1B90FAD70E</p:OperationID>
    <p:SequenceId>1</p:SequenceId>
    <a:RelatesTo>uuid:B03C7765-66AC-4DAB-B84D-BC62464A1AC8</a:RelatesTo>
  </s:Header>
  <s:Body>
    <n:EnumerateResponse>
      <n:EnumerationContext/>
      <w:Items>
        <rsp:Shell xmlns:rsp="http://schemas.microsoft.com/wbem/wsman/1/windows/shell">
          <rsp:ShellId>E578F8FB-5A82-4491-AC46-E04EDBD41CD7</rsp:ShellId>
          <rsp:Name>WinRM1</rsp:Name>
          <rsp:ResourceUri>http://schemas.microsoft.com/powershell/Microsoft.PowerShell</rsp:ResourceUri>
          <rsp:Owner>DOMAIN\vagrant-domain</rsp:Owner>
          <rsp:ClientIP>192.168.56.12</rsp:ClientIP>
          <rsp:ProcessId>832</rsp:ProcessId>
          <rsp:IdleTimeOut>PT7200.000S</rsp:IdleTimeOut>
          <rsp:InputStreams>stdin pr</rsp:InputStreams>
          <rsp:OutputStreams>stdout</rsp:OutputStreams>
          <rsp:MaxIdleTimeOut>PT2147483.647S</rsp:MaxIdleTimeOut>
          <rsp:Locale>en-US</rsp:Locale>
          <rsp:DataLocale>en-US</rsp:DataLocale>
          <rsp:CompressionMode>XpressCompression</rsp:CompressionMode>
          <rsp:ProfileLoaded>Yes</rsp:ProfileLoaded>
          <rsp:Encoding>UTF8</rsp:Encoding>
          <rsp:BufferMode>Block</rsp:BufferMode>
          <rsp:State>Connected</rsp:State>
          <rsp:ShellRunTime>P0DT0H2M29S</rsp:ShellRunTime>
          <rsp:ShellInactivity>P0DT0H2M29S</rsp:ShellInactivity>
          <rsp:MemoryUsed>62MB</rsp:MemoryUsed>
          <rsp:ChildProcesses>0</rsp:ChildProcesses>
        </rsp:Shell>
        <rsp:Shell xmlns:rsp="http://schemas.microsoft.com/wbem/wsman/1/windows/shell">
          <rsp:ShellId>D76BA8D1-C52A-4E10-8A28-46262426AC09</rsp:ShellId>
          <rsp:Name>Runspace1</rsp:Name>
          <rsp:ResourceUri>http://schemas.microsoft.com/powershell/PowerShell.7</rsp:ResourceUri>
          <rsp:Owner>DOMAIN\vagrant-domain</rsp:Owner>
          <rsp:ClientIP>192.168.56.12</rsp:ClientIP>
          <rsp:ProcessId>6900</rsp:ProcessId>
          <rsp:IdleTimeOut>PT7200.000S</rsp:IdleTimeOut>
          <rsp:InputStreams>stdin pr</rsp:InputStreams>
          <rsp:OutputStreams>stdout</rsp:OutputStreams>
          <rsp:MaxIdleTimeOut>PT2147483.647S</rsp:MaxIdleTimeOut>
          <rsp:Locale>en-US</rsp:Locale>
          <rsp:DataLocale>en-US</rsp:DataLocale>
          <rsp:CompressionMode>XpressCompression</rsp:CompressionMode>
          <rsp:ProfileLoaded>Yes</rsp:ProfileLoaded>
          <rsp:Encoding>UTF8</rsp:Encoding>
          <rsp:BufferMode>Block</rsp:BufferMode>
          <rsp:State>Connected</rsp:State>
          <rsp:ShellRunTime>P0DT0H2M18S</rsp:ShellRunTime>
          <rsp:ShellInactivity>P0DT0H2M16S</rsp:ShellInactivity>
          <rsp:MemoryUsed>97MB</rsp:MemoryUsed>
          <rsp:ChildProcesses>1</rsp:ChildProcesses>
        </rsp:Shell>
      </w:Items>
      <w:EndOfSequence/>
    </n:EnumerateResponse>
  </s:Body>
</s:Envelope>

In this case foo has 2 shells that are open, one for Microsoft.PowerShell and another for PowerShell.7. They are both Connected which means they are still active and in use by a client. These could be Disconnected and waiting to be reconnected but the point is that the WSMan service reports all shells it has open. PowerShell then uses the information of each shell and filters out the results that don't match whatever the filter criteria specified by the user was. It also filters out any shells that don't have a resource uri prefix of http://schemas.microsoft.com/powershell/ to only return PowerShell sessions.

Ultimately it's all sessions managed by the remote service not just ones opened by the current process/computer. This is why -ComputerName is purely a WSMan thing as it has no idea about SSH PSSessions or any other connection type.

Thanks for the full answer!

I believe the user must have the appropriate permissions for WSMan to return the list of sessions. In this case, the user could connect to the remote computer via SSH, get a list of all pwsh processes and even connect to them via local socket. Maybe this is what Paul meant.

I believe the user must have the appropriate permissions for WSMan to return the list of sessions

It certainly needs permission to perform the Enumerate action but I'm not aware of any extra permissions applied to what WSMan returns. Typically the access checks is done when you attempt to open one of the PSSessions as now you need to reauthenticate as the same user it was created with.

In this case, the user could connect to the remote computer via SSH, get a list of all pwsh processes and even connect to them via local socket. Maybe this is what Paul meant.

Potentially, honestly I don't see Get-PSSession continuing to be used for enumerating PSSession's remotely. It could be expanded in the future to somehow track active PSSessions on the current host using a common mechanism in PowerShell and then combined with Invoke-Command to provide remote access. The benefit of Get-PSSession -ComputerName ... on Windows is the ability to get disconnected sessions and re-connect them on the new client. As WSMan is the only PSRemoting protocol that supports disconnected sessions (and custom transports cannot do so) then it makes sense only keeping this as Windows only.

As WSMan is the only PSRemoting protocol that supports disconnected sessions (and custom transports cannot do so)

Eh, this will definitely be in demand for the management tool that is PowerShell. If WSMan does this, then users will expect the same from any custom transport that replaces WSMan. It would be better for UX if the base cmdlets didn't change and were independent of transport.

I honestly feel like PSRemoting is inferior in pretty much most circumstances for interactive use which is where you typically want disconnection support. Using pure ssh with tools like tmux offer such a better experience and will be what I typically recommend going forward.

Someone may want to reimplement disconnection support for custom transports but it’ll require a lot of work and an even more special server side protocol to make use of it. Until that time I think it’s safe to just make this functionality Windows only.

@SteveL-MSFT it's been over 3 months without any review by someone from the PowerShell team. Any chance this can be added to the next cycle.

📣 Hey @jborean93, how did we do? We would love to hear your feedback with the link below! 🗣️

🔗 https://aka.ms/PSRepoFeedback

Microsoft Forms