PowerShell Direct is introduced with Server 2016/Windows 10. it enables you to create a remoting session from the Hyper-V host to a VM using the VM name or ID. I recent discovered a PowerShell Direct failure that I couldn’t explain until now.
Normally you do this:
PS> New-PSSession -VMName w16cn01 -Credential (Get-Credential w16cn01\administrator)
Id Name ComputerName ComputerType State ConfigurationName Availability
-- ---- ------------ ------------ ----- ----------------- ------------
1 Session1 W16CN01 VirtualMachine Opened Available
But on one particular machine I was getting this
PS> New-PSSession -VMName w16as01 -Credential (Get-Credential w16as01\administrator)
New-PSSession : [W16AS01] An error has occurred which Windows PowerShell cannot handle. A remote session might have ended.
At line:1 char:1
+ New-PSSession -VMName w16as01 -Credential (Get-Credential w16as01\adm ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
gDataStructureException
+ FullyQualifiedErrorId : PSSessionOpenFailed
I couldn’t find an explanation for this particular PowerShell Direct failure
I’ve been working with PowerShell v6 and OpenSSH the last few days and I noticed that the PowerShell directory had been removed from the system path by the installation of one of these pieces of software.
W16AS01 had been the first machine I experimented with PowerShell v6/OpenSSH and it was the first to experience this PowerShell direct failure.
I checked W16AS01 and sure enough the PowerShell folder was missing from the system path. Adding the Powershell folder back onto the path (and restarting the machine for luck) then retrying PowerShell Direct gives:
PS> New-PSSession -VMName W16AS01 -Credential (Get-Credential W16AS01\Administrator)
Id Name ComputerName ComputerType State ConfigurationName Availability
-- ---- ------------ ------------ ----- ----------------- ------------
1 Session1 W16AS01 VirtualMachine Opened Available
Looks like I’ve found a solution for this particular PowerShell direct failure