You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have internally been referring to this as the "Nano Server Scenario" aka headless, remote-only remoting activation. The idea is that we need a way to register a non-running instance of PowerShell Core with WinRM. In Nano Server, you can create a remote session (New-PSSession)to the instance of Windows PowerShell running on the system. Once in that session (Enter-PSSession), you can unzip PowerShell Core on Nano Server to make it available for use. The only way to register the new instance of PowerShell Core as a WinRM endpoint is to run Install-PowerShellRemoting.ps1 from within the current Windows PowerShell remote session.
Enable-PSRemoting works to register the running instance of PowerShell Core with WinRM, but the script Install-PowerShellRemoting.ps1 is the only solution to this problem. We should consider building that functionality into a new cmdlet or an existing cmdlet to make it more permanent.
Today Install-PowerShellRemoting.ps1 and Enable-PSRemoting overlap and create PSSessionConfigurations with slightly different names (PowerShell.v6.0.0 vs powershell.6.0.0). We remove Install-PowerShellRemoting.ps1 and add support for -PowerShellHome to Enable-PSRemoting and standardize on the configuration name (I prefer the latter myself).
It was my original intent that the script and cmdlet should produce the same configuration name, so I consider divergence a bug. I prefer it without the "v" as well.
changed the title [-]Add Support for Registering a Separate Instance of PowerShell Core for Remoting[/-][+]Consistent way to enable PSRemoting[/+]on Jan 31, 2018
For this issue, it seems we have a couple of minor things:
Add support for -PowerShellHome to Enable-PSRemoting, however, this makes it a bit more complicated to run on Windows IoT where you initially only have Windows PowerShell Core which won't have the updated Enable-PSRemoting.
Fix Enable-PSRemoting endpoint name to not contain v
Activity
SteveL-MSFT commentedon Jan 10, 2018
Today
Install-PowerShellRemoting.ps1andEnable-PSRemotingoverlap and create PSSessionConfigurations with slightly different names (PowerShell.v6.0.0 vs powershell.6.0.0). We removeInstall-PowerShellRemoting.ps1and add support for-PowerShellHometoEnable-PSRemotingand standardize on the configuration name (I prefer the latter myself).mirichmo commentedon Jan 10, 2018
It was my original intent that the script and cmdlet should produce the same configuration name, so I consider divergence a bug. I prefer it without the "v" as well.
[-]Add Support for Registering a Separate Instance of PowerShell Core for Remoting[/-][+]Consistent way to enable PSRemoting[/+]SteveL-MSFT commentedon Jan 31, 2018
For this issue, it seems we have a couple of minor things:
-PowerShellHometoEnable-PSRemoting, however, this makes it a bit more complicated to run on Windows IoT where you initially only have Windows PowerShell Core which won't have the updatedEnable-PSRemoting.Enable-PSRemotingendpoint name to not containvSteveL-MSFT commentedon Jun 20, 2018
I think what we have is sufficient, so closing this item.