Porting Enable-PSRemoting and its Tests#2671
Conversation
7d27163 to
701bb47
Compare
|
Can you please resolve the conflict? |
|
At some point. I'm trying to find time to resolve the test failures. |
|
cool ! |
701bb47 to
4f54950
Compare
e9168ff to
cb2a7e7
Compare
0f08a9f to
7ee2f3b
Compare
|
@mirichmo I am not sure how I missed this being assigned to me as a reviewer. But I will review it today. |
|
The tests aren't passing yet so it still needs some work. You are always welcome to take a look though |
|
@mirichmo I went through the code changes and made some minor changes in my fork. I also made some fixes in the test file. Overall I think this looks good and is the right way to implement WinRM based remoting enabling and endpoint management. Please see the patch file I sent you offline that has my minor changes. |
7ee2f3b to
b1e93ac
Compare
PSSessionConfiguration cmdlets.
6b2ed25 to
1db21fd
Compare
|
@daxian-dbw This is ready for merge now. |
It seems we need update docs - should we set the label? |
|
@iSazonov good point. I added the label to both this PR and the issue. |
Fixes #1193 for most scenarios. The remaining scenario to be addressed is the Nano Server bring-up scenario. To continue supporting that scenario, I left the Install-PowerShellRemoting script in place.
This change
This change also introduces a behavioral difference. The PSRemoting and PSSessionConfiguration cmdlets are now context-sensitive and only work for endpoints that match the PowerShell type. For example, Get-PSSessionConfiguration, when run in PowerShell Core, will only return PowerShell Core WinRM endpoints. It will only modify PowerShell Core WinRM endpoints and cannot be used to configure Windows PowerShell endpoints.