Repository navigation
WinRM Plugin Registration and Modification #1193
Description
Overview
On Windows, the PowerShell installer will not automatically enable receiving incoming requests. The feature shall be activated as a post-install step that requires Administrator-level authorization (due to the WinRM plugin's System32 placement requirement).
Changes Required
Enable-PSRemoting Changes
Cmdlet implementation should be changed to also
- Copy pwrshplugin.dll from %ProgramFiles%\PowerShell\ (aka $PSHOME) to %windir%\System32\PowerShell
- Create a the necessary plugin configuration file in %windir%\System32\PowerShell
- Register the plugin as a WinRM endpoint (Proposed name = PowerShell.)
Get-PSSessionConfiguration should work with these changes.
Activity
alexandair commentedon Jul 20, 2016
How is Get-PSRemoting different than Get-PSSessionConfiguration?
UPDATE: Is this expected?
PS C:> Get-PSSessionConfiguration
Get-ChildItem : Cannot find drive. A drive with the name 'WSMan' does not exist.
HemantMahawar commentedon Jul 20, 2016
Aleksandar Nikolić (@alexandair) ... that was left over from previous thinking. Cleaned it up .. cc Mike Richmond (@mirichmo)
mirichmo commentedon Aug 7, 2016
Due to time constraints for the upcoming release, I implemented a partial solution to this issue. The script Install-PowerShellRemoting.ps1 resides in $PSHOME for Windows releases and will automatically register the included plugin as a WinRM endpoint for PS remoting. The script must be run with Administrator rights because it copies the plugin dll into a versioned directory within System32.
This issue should remain open until I have time to implement the full solution.
20 remaining items
joeyaiello commentedon May 22, 2017
I believe that most of this logic is already encapsulated in
Install-PowerShellRemoting.ps1, but we should bring it intoEnable-PSRemoting.Porting Enable-PSRemoting and its Tests (#2671)
daxian-dbw commentedon Aug 8, 2017
Mike Richmond (@mirichmo) This issue was closed automatically after merging #2671. If this issue shouldn't be closed due the pending NanoServer scenario, feel free to re-open it.
mirichmo commentedon Aug 8, 2017
The Nano Server Scenario (registering a different instance of PowerShell Core) is covered by the install script and that still exists. I filed #4528 to document this.
BatmanAMA commentedon Jan 14, 2019
It sounds like this is resolved, however on a new install of powershell 6.1.1 (on WS 2016)
enable-psremotingfails to register a powershell.6 (or powershell.6.1.1) endpoint. I need to still use theinstall-powershellremoting.ps1script.Is this intended? It may be worth clarifying in the docs what the psremoting setup procedure is and removing the reference to this issue. Let me know what you're thinking and I'll happily go submit a pull request to the docs repo.
benmccallum commentedon Dec 3, 2020
After installing PS 7.1 and in the installer checking "Enable Remoting" or whatever the option was I couldn't remote. Full details on this SO post here.
I found a kind of solution which is giving the windows user I'm trying to connect with Full Control of
C:\Windows\System32\PowerShell\7.1.0, but I'd obviously like to know if something else has gone wrong and it seems kinda of related to what this installer was doing though I used Enable-PSRemoting in a 7.1 isntance so not sure...Any help would be appreciated!
Porting Enable-PSRemoting and its Tests (PowerShell#2671)