GeezerVison is showing github.com — Invoke-Command : Windows Principal functionality is not supported on this platform. · Issue #6435 · PowerShell/PowerShell
Invoke-Command : Windows Principal functionality is not supported on this platform. #6435DescriptionSometimes, When I try to execute a remote command in a PowerShell Session from PowerShell in Linux, I get this error:
Invoke-Command : Windows Principal functionality is not supported on this platform.
From PowerShell in Mac works fine, but with PowerShell in Linux doesn't.
Steps to reproduce
We are connected to a Linux powershell session though a PowerShell session in a system with sshd Subsystem powershell /usr/bin/pwsh -sshs -NoLogo -NoProfile.
Once into the system, we want to execute a command to another Linux powershell session
$pss = New-PSSession -Hostname x.x.x.x -Username xxx -Port xx -KeyFilePath ~/.ssh/xxx
Invoke-Command $pss { $PSVersionTable }
Expected behavior
Name Value
---- -----
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
WSManStackVersion 3.0
SerializationVersion 1.1.0.1
Platform Unix
OS Linux 3.10.0-693.5.2.el7.x86_64 #1 SMP Fri Oct 20 20:32:50 UTC 2017
PSVersion 6.0.1
PSEdition Core
GitCommitId v6.0.1
Actual behavior
Invoke-Command : Windows Principal functionality is not supported on this platform.
At line:1 char:1
+ Invoke-Command $pss { $PSVersionTable }
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Invoke-Command], PlatformNotSupportedException
+ FullyQualifiedErrorId : System.PlatformNotSupportedException,Microsoft.PowerShell.Commands.InvokeCommandCommand
Environment data
> $PSVersionTable
Name Value
---- -----
PSVersion 6.0.2
PSEdition Core
GitCommitId v6.0.2
OS Linux 3.10.0-693.21.1.el7.x86_64 #1 SMP Wed Mar 7 19:03:37 UTC 2018
Platform Unix
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0But if I execute Enter-PSSession I get an error, and then Invoke-Command runs like a charm.
If we connect to the linux machine though ssh with bash, and execute /usr/bin/pwsh Invoke-Command works at first attempt. ActivityPaulHigin commented on Mar 22, 2018 This looks like a weird double hop issue. I'll try to repro when I get some time. flxflx commented on Jul 19, 2018 I am getting the same error for the following line of code when I am on WSL or connected remotely to a Linux box over ssh.
$nodes | foreach-object { start-job -ScriptBlock $function:createRemoteNode -ArgumentList ($_, ($nodeId++) + $constArgs)} | receive-job -Wait -AutoRemoveJob
neel015 commented on Sep 13, 2018 Facing the same error when trying to run invoke-command using Powershell core 6.1 with Microsoft.Powershell.SDK dlls.
Working on a linux ubuntu 16.04, I am able to run the command from powershelll core directly. However, when I try to run the same script from C#, I am getting the same error message.
$TargetSession = New-PSSession -HostName $TargetComputerName -UserName $Username -KeyFilePath $KeyFilePath
Invoke-Command -Session $TargetSession -ScriptBlock {
get-process
}
JustinGrote commented on Jan 3, 2019 This happens to me when doing SSH remoting from a Linux system to a Windows system via SSH if the commands are wrapped in jobs. Doesn't seem to matter if it's a process job or a runspace job.
Works perfectly fine from Posh 6.1 on Windows to Windows via SSH
Normal SSH Session (works)
PS /tmp> $s = new-pssession -SSHTransport -HostName _REDACTED_ -KeyFilePath /tmp/tmpblvmbP.tmp -UserName _REDACTED_ -Verbose;sleep 1;icm -session $s -scriptblock {echo "test"}
testInside Process via Start-Job (fails)
PS /tmp> start-job {$s = new-pssession -SSHTransport -HostName 172.30.2.89 -KeyFilePath /tmp/tmpblvmbP.tmp -UserName sa-awsmodelingstatus -Verbose;sleep 3;icm -session $s -scriptblock {echo "test"}} | receive-job -wait -AutoRemoveJob
Windows Principal functionality is not supported on this platform.
+ CategoryInfo : NotSpecified: (:) [Invoke-Command], PlatformNotSupport edException
+ FullyQualifiedErrorId : System.PlatformNotSupportedException,Microsoft.PowerSh ell.Commands.InvokeCommandCommand
+ PSComputerName : localhost
Inside Runspace via Start-Threadjob (fails)
PS /tmp> start-threadjob {$s = new-pssession -SSHTransport -HostName _REDACTED_ -KeyFilePath /tmp/tmpblvmbP.tmp -UserName _REDACTED_-Verbose;sleep 1;icm -session $s -scriptblock {echo "test"}} | Receive-job -wait -AutoRemoveJob
icm : Windows Principal functionality is not supported on this platform.
At line:1 char:136
+ ... ingstatus -Verbose;sleep 3;icm -session $s -scriptblock {echo "test"}
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Invoke-Command], PlatformNotSupportedException
+ FullyQualifiedErrorId : System.PlatformNotSupportedException,Microsoft.PowerShell.Commands.InvokeCommandCommand
Steve Lee (@SteveL-MSFT) does your PR #8232 address this?
EDIT: Just tested on 6.2.0-preview3 with #8232 included. It does not 👎 JustinGrote commented on Jan 3, 2019 Tried doing it with -SSHConnection and ran into #8589. SSH Remoting still feels pretty half-baked unfortunately... PaulHigin commented on Jan 5, 2019 Justin Grote (@JustinGrote) Unfortunately I am still unable to repro this error. But the error indicates that there is still some Windows code lurking in Linux code paths. I recently found and fixed a number of similar issues pertaining to Windows impersonation flow. The problem was found during remote debugging but it is possible it is related to your problem (#8451). However, the fix won't be available until the next release (I think Feb), unless you want to build your own version to test with. Also, if you can include the error stack trace, it may pinpoint the offending code path. danports commented on Mar 27, 2019 I am working on a similar scenario as Neel (@neel015) and also ran into this issue on 6.1.3. Here's a stack trace Paul Higinbotham (@PaulHigin):
System.PlatformNotSupportedException: Windows Principal functionality is not supported on this platform.
at System.Security.Principal.WindowsIdentity.GetCurrent()
at System.Management.Automation.RemoteDebugger.CheckForValidateState()
at System.Management.Automation.RemoteDebugger.set_UnhandledBreakpointMode(UnhandledBreakpointProcessingMode value)
at Microsoft.PowerShell.Commands.ExecutionCmdletHelper.ConfigureRunspaceDebugging(Runspace runspace)
at Microsoft.PowerShell.Commands.ExecutionCmdletHelperRunspace.StartOperation()
at System.Management.Automation.Remoting.ThrottleManager.StartOneOperationFromQueue()
at System.Management.Automation.Remoting.ThrottleManager.StartOperationsFromQueue()
at System.Management.Automation.Remoting.ThrottleManager.SubmitOperations(List`1 operations)
at System.Management.Automation.PSInvokeExpressionSyncJob.StartOperations(List`1 operations)
at Microsoft.PowerShell.Commands.InvokeCommandCommand.CreateAndRunSyncJob()
at Microsoft.PowerShell.Commands.InvokeCommandCommand.ProcessRecord()
at System.Management.Automation.Cmdlet.DoProcessRecord()
at System.Management.Automation.CommandProcessor.ProcessRecord() at at <ScriptBlock>, <No file>: line 6
danports commented on Mar 27, 2019 Neel (@neel015) I was able to bypass the problematic code by calling RunspaceFactory.CreateRunspace(new WSManConnectionInfo {...}) to create a remote runspace rather than using New-PSSession and Invoke-Command, which feels cleaner anyhow. SteveL-MSFT commented on Mar 27, 2019
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|
