Repository navigation
Enable-PSRemoting/Install-PowerShellRemoting should have configuration name that is independent of the version #6470
Copy link
Copy link
Closed
Labels
Resolution-FixedThe issue is fixed.The issue is fixed.WG-RemotingPSRP issues with any transport layerPSRP issues with any transport layer
Milestone
Description
Steps to reproduce
Enable-PSRemotingExpected behavior
Predictable ConfigurationName created that is not tied to the specific version as administrators cannot guess which specific version is installed on the target.
Would make sense to keep the version specific ConfigurationName for side-by-side use, but perhaps we should also create a PowerShell-6 (last one wins, so it may not be the latest)
Actual behavior
ConfigurationName is powershell-6.0.1 or worse powershell-6.1.0-Preview1
Environment data
Name Value
---- -----
PSVersion 6.0.2
PSEdition Core
GitCommitId v6.0.2
OS Darwin 17.4.0 Darwin Kernel Version 17.4.0: Sun Dec 17 09:19:54 PST 2017; root:xnu-4570.41.2~1/RELEASE_X86_64
Platform Unix
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
Resolution-FixedThe issue is fixed.The issue is fixed.WG-RemotingPSRP issues with any transport layerPSRP issues with any transport layer
Activity
SteveL-MSFT commentedon Mar 23, 2018
Also, Enable-PSRemoting and Install-PowerShellRemoting produces different configuration names (one has a
vin front of the version and the other doesn't, we should be consistent and not have thev).Unfortunately,
Install-PowerShellRemoting.ps1is still needed when configuring a remoting endpoint to PSCore6 from Windows PowerShell (like on Windows 10 IoT)Create the default PSSession configuration, not tied to a specific Po…
kalgiz commentedon Apr 11, 2018
Fixed in #6519
Keep uptodate (#1)
Create the default PSSession configuration, not tied to a specific Po…