Powershell: Enable-PSRemoting and Disable-PSRemoting cmdlets should affect all remoting endpoints per documentation.

[PaulHigin]

Per PowerShell documentation, Enable-PSRemoting and Disable-PSRemoting cmdlets enable and disable all remoting endpoints on the local machine. But PSCore6 versions of these cmdlets affect only PSCore6 endpoints. The problem with this is that users expect Disable-PSRemoting cmdlet to isolate the local machine from any WinRM/PowerShell connections, but this is no longer true when all Windows PowerShell endpoints remain enabled.

I feel these enable/disable cmdlets should affect all WinRM endpoints on the local machine. The cmdlet behavior should only differ by what default endpoints they create.

Enable-PSSessionConfiguration/Disable-PSSessionConfiguration cmdlets can be used to enable/disable individual endpoints.

Steps to reproduce

# Create/register default PSCore6 remote endpoints
Enable-PSRemoting -Force

# Disable endpoints
Disable-PSRemoting -Force

# From Windows PowerShell check its remote endpoints
powershell.exe -c 'Get-PSSessionConfiguration'

Expected behavior

All PowerShell endpoints on local machine are disabled.

Actual behavior

Only PSCore6 endpoints on local machine are disabled.  Windows PowerShell endpoints remain enabled and so PSRemoting remains enabled.

Environment data

Name                           Value
----                           -----
PSVersion                      6.2.0-preview.2
PSEdition                      Core
GitCommitId                    6.2.0-preview.2-68-gc9fc4ef4ec1256ac7082f55c45d4e400cc642767
OS                             Microsoft Windows 10.0.17763
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[iSazonov]

Can PowerShell Core use Windows PowerShell endpoints and/or vice verse? If yes I agree that the proposal make sense.

[alexandair]

@iSazonov Sure, it can. That's how WindowsCompatibility module works--PowerShell Core on Windows connects to Windows PowerShell endpoint.

[mklement0]

How about:

• keeping the edition-scoped behavior for consistency.

• issuing a _warning_ if Disable-PSRemoting finds endpoints managed by the respective _other_ edition.

• updating the documentation accordingly.

That would avoid the awkwardness of introducing implicit cross-edition _functionality_ (as opposed to _awareness_).

[iSazonov]

If Disable-PSRemoting disable/warn endpoints in both editions then Enable-PSRemoting should works symmetrically.

[joeyaiello]

This one's hard...I strongly agree with @iSazonov's statement that Enable/Disable should be symmetric, but on the other hand, I really don't want us hunting around for and calling powershell.exe to do that (or worse, implementing logic for PS Core to create the endpoint itself).

In my mind, one problem here is that both of these cmdlets have conceptually been helpers/wrappers for "setting up and disabling PowerShell remoting" as opposed to something like New/Remove-WinRMEndpoint.

But I expect the @PowerShell/powershell-committee to have opinions here...

[SteveL-MSFT]

@PowerShell/powershell-committee reviewed this. The current behavior is that Disable-PSRemoting affects the entire system while Enable-PSRemoting is only for the PS being used. We agreed that this behavior should be documented and no code change expected.

[mklement0]

@SteveL-MSFT

We agreed that this behavior should be documented

Documenting this baffling asymmetry is an absolute necessity, but I fear it's not enough to counteract how counterintuitive it is.

[SteveL-MSFT]

@mklement0 if we ever get Enable-SSHRemoting and Disable-SSHRemoting, we can decide to have them scoped to current PowerShell instance and possibly have a -Scope System parameter if needed.

[mklement0]

@SteveL-MSFT:

In line with @joeyaiello's argument: Something like New/Remove-WinRMEndpoint would deserve to be edition-agnostic, because its target is something that _transcends_ a particular PS edition.

Knowing little about SSH-based remoting, it sounds like the same logic would apply there - unless it is truly something PS-specific.

In other words: Anything _but_ *-PSRemoting deserves to be edition-agnostic.

[PaulHigin]

I feel this is a wrong decision by the committee. What is the justification for keeping this behavior that breaks with our public documentation and expected behavior? Updating the cmdlets to be in conformance is relatively easy.

[SteveL-MSFT]

To clarify, the decision from @PowerShell/powershell-committee is to retain the Windows PowerShell behavior.

[msftbot[bot]]

This issue has been marked as answered and has not had any activity for 1 day. It has been closed for housekeeping purposes.