It was decided by committee (#15862) to remove this experimental feature. It was an interesting idea but the implementation did not cover important cases, and could not be updated easily to do so.
Some Azure images have run into this problem where Start-Job fails even when running in pwsh child process rather than Windows PowerShell child. Fix is to guard against the missing registry entry.
This is based on an issue, where Enter-PSHostProcess on a locked down (WDAC enforced) machine allows any admin to connect to any another local hosted PowerShell process and execute commands as that user. This amounts to privilege escalation on the policy locked down machine and something we want to prevent.
Fix is to check for system lock down and disable Enter-PSHostProcess cmdlet with an error message.
Adds warning messages to the Enable-PSRemoting and Disable-PSRemoting cmdlets that informs the user that the cmdlets only affect PSCore6 remoting endpoint configurations and not Windows PowerShell configurations.
PR Context
As documented, Enable-PSRemoting and Disable-PSRemoting affects all PowerShell remoting on a Windows system, and Windows users will likely expect the cmdlets to continue working this way in PSCore6. However, these cmdlets currently affect only PSCore6 remoting endpoints when run in PSCore6 and have no effect on Windows remoting endpoints.
Remoting relies on Windows native crypto APIs to pass a secure string. Of course these APIs don't work on non-Windows. However, the remoting code does not expect this to fail so ends up in a hang waiting for an event that never happens.
Have not figured out how to return an error to the user in the case `Get-Credential` is called within a PSSession. Currently it just quietly closes the remote connection. @PaulHigin can you give a pointer to where this code would exist? Debugging the current code, it has a bunch of error handlers which just result in the pssession being closed and not sure where throwing is appropriate.
Fix https://github.com/PowerShell/PowerShell/issues/8723
## PR Context
Fix is to provide implementations of the Win32 native pinvoke apis that throw an exception. The reason to do it this way is that there's a bunch of code that calls some of the APIs of the wrapper .Net class to setup structures that eventually get passed to the win32 api. Throwing in the managed class causes other things to fail early that should work on non-Windows.
Dongbo Wang