Powershell: "cert:" disables output when used with Invoke-Command

[Voriaz]

When using Invoke-Command with a command containing "cert:" the console output is disabled

Steps to reproduce

Invoke-Command -ComputerName mycomputer.local -Credential $creds -ScriptBlock {Set-Location cert: ; Write-Host "Hello !"}

Expected behavior

Concole should print: "Hello!"

Actual behavior

Console print nothing

Environment data

PS C:\> Invoke-Command -ComputerName mycomputer.local -Credential $creds -ScriptBlock {$psversiontable}

Name                           Value
----                           -----
WSManStackVersion              3.0
SerializationVersion           1.1.0.1
PSRemotingProtocolVersion      2.3
PSEdition                      Core
OS                             Microsoft Windows 10.0.17763
PSVersion                      7.1.0-preview.3
GitCommitId                    7.1.0-preview.3
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}

PS C:\> $psversiontable

Name                           Value
----                           -----
PSVersion                      5.1.17763.1007
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17763.1007
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

I've tested with different commands : ls, dir, sl, Get-ChildItem. ans it is same error.
When using ps 5.1 on remote server, it is working normaly.

[doctordns]

Works here:

PS C:\Foo>  Invoke-Command -ComputerName cookham1 -ScriptBlock {Set-Location cert: ; Write-Host "Hello !"}
Hello !

[iSazonov]

I can not reproduce too.

[vexx32]

Interestingly it looks like @Voriaz is remoting _from_ Windows PowerShell _to_ pwsh. I'd be suspecting a bug in 5.1, but if there is one I don't imagine it will be able to be fixed.

[Voriaz]

I'm remoting from powershell 5.1 to pwsh 7. I've also tried from pwsh to pwsh and it is the same. So, I think the bug is not in 5.1 but in 7.

[iSazonov]

@PaulHigin Could you please comment the issue?

[PaulHigin]

/cc @anmenaga

I am able to repro this and it is not a regression but a result of module compatibility, implicit remote module loading.
The Set-Location cert: command requires the PowerShell certificate module, which is not compatible with PS6+, and so is loaded through Andrew's module implicit remoting.

Invoke-Command -cn . -config PowerShell.7-preview { Set-Location cert: ; Write-Host "Hello!" }

When this (implicit remote module loading) is done within a remote session, the implicit remoting code (I think through the steppable pipeline object) changes the execution context host reference from the running command serverhost to the runspace serverhost. Write-Host uses the serverhost to send a host invocation command back to the client, which then performs the Write-Host to console.

A remote running command should always use the command serverhost for client host callbacks, and using the runspace serverhost introduces a race condition. Basically, the remote command completes before the runspace Write-Host message arrives on the client, and so Invoke-Command closes the session before it can be processed. This can be seen by adding a delay to the script to get the expected output.

Invoke-Command -cn . -config PowerShell.7-preview { Set-Location cert: ; Write-Host "Hello!" ; sleep 1 }
Hello!

I don't think it is worth trying to fix since it is a rare case and there are workarounds. One workaround is to create a persisted session instead of an implicit session.

$session = New-PSSession -cn . -config PowerShell.7-preview
Invoke-Command -session $session { Set-Location cert: ; Write-Host "Hello!" }
Hello!
$session | Remove-PSSession

[iSazonov]

@PaulHigin Thanks for deep explanations!

I don't think it is worth trying to fix since it is a rare case and there are workarounds.

While PowerShell Core loads modules with the compatibility feature such issue can be raised.
At the very least, we could add this to the documentation (a workaround with creating an explicit session, or maybe it is possible to create a warning for the user at run time).

[doctordns]

I would like this fixed one day, but as you say it's a rare case. So at a minimum, can we make sure this is documented along with the workaround? And maybe leave this issue open and leave it for a rainy day to fix sometime in the future?

[iSazonov]

With compatibility feature enabled it is not a rare case. :-(

[doctordns]

medium-rare?

I still think it low priority to fix in PowerShell. The real solution is to have all modules not need compatibility and to work natively.