Digging into PowerShell Direct

Adam Driscoll's Blog - Wed, 25-Nov-15 11:42

Available in Windows 10 and the Windows Server 2016 Technical Preview, there is a new feature of PowerShell and Hyper-V that enables you to connect to guest machines that lack network access: PowerShell Direct. The standard PSSession cmdlets along with Invoke-Command now offer a VMID and VMName parameter. Simply run any of these commands as you normally would with a remote machine and you have access to a remoting session to the guest. It worked perfectly for me.


After playing with it a bit, I was curious to find out just how it works. The first place I looked was in the guest where there is a new service installed called the “Hyper-V VM Session Service” (vmicvmsession). It’s initially stopped but when I attempted to connect via Enter-PSSession from the host machine, the service was automatically started.

On the client end, I popped open .NET Reflector and dug into the Enter-PSSession cmdlet. This cmdlet can be found in the System.Management.Automation.dll. This is where you will see the new properties for VMName and VMID.


When a VM name or ID is specified, a new HyperVSocketConnectionInfo class is used rather than the typical WSManConnectionInfo class.


There were a bunch of interesting classes associated with Hyper-V remoting. They implement the glue necessary to open the connection and allow the PowerShell remoting proctol to go over the Hyper-V socket.


One class that is interesting is the RemoteSessionHyperVSocketClient class. It’s responsible for initiating the socket connection to the guest. In the constructor to the client, it instantiates a HyperVSocketEndPoint to pass to the Socket constructor.


Interesting to note is the protocol type is listed as ICMP and the socket family is a 0x22 magic number. Looking at the AddressFamily enumeration, this address family is not listed. Also, the address family is not registered with IANA. The endpoint’s serialized value is a combination of the address family, VMID and service ID. The service ID depends on whether or not this is the first connection to the guest.


On the first connection, the first step is to send the username and domain name.


Next a string is sent to indicate whether or not a password will be sent and then the password is sent. Afterwards, the client checks for a failure string.


Once this socket is open, standard PS Remoting protocols seem to be used just as you would with a WSMan connection.

Overall, it’s a super handy feature and it’s interesting to see how it’s being accomplished. I do wonder what the magical address family 0x22 will be called or if it will remain 0x22.



Categories: Powershell

Upcoming features in PowerShell Tools for Visual Studio

Adam Driscoll's Blog - Tue, 01-Sep-15 18:53

Long time no blog! I wanted to showcase a couple neat features coming to PowerShell Tools for Visual Studio. My hope is that we can get some feedback before pushing to the gallery for the world to enjoy.

Windows Forms Support for PowerShell

The Windows Form designer is handy for throwing together some drag and drop UI. I spent some time futzing with creating a CodeDOM provider for PowerShell. The Windows Form designer talks CodeDOM so we need to translate the PowerShell AST into a CodeDOM format in order to get the form designer to understand a PowerShell script. The other half of the equation is taking an existing CodeDOM and translating it into a functioning PowerShell script. Some of the challenges were that, until recently, PowerShell didn’t support classes so we had to fake it. Right now the CodeDOM provider is targeting PowerShell v3+. It uses the AST to create CodeDOM CompileUnits.

Once you have the latest build installed, you will have access to a new item template (need a new icon!).


Adding a new file of this type will create two files on disk. One is the designer code. The other is the event handling and execution file. The designer file contains all the code to render the UI and hook up the event handlers found in the other file. The execution file invokes the designer code and then shows the UI.





The designer file shouldn’t be edited by hand. The form designer is using the PoshTools CodeDOM provider to generate that on the fly.

Double clicking the form in the Solution Explorer window will show an error. Still trying to nail this one down!


To fix the error, just add references to System.Drawing and System.Windows.Forms.


From there you should be able to drag and drop items from the Toolbox on the form. Adjusting the properties should work. You can also hook up event handlers by doing actions like double clicking on buttons.

Would love to hear feedback! I need to fix the issue with the references before this will be committed to the main branch.

PowerShell Command Explorer

One of the neat tools in the PowerShell ISE is the command browser. It allows you to view different modules and the module within them. It also allows you to select different parameters and sets, view help and execute commands. Well thanks to Erwin de Vreugd, we now have that functionality within PoshTools!

After installing the updated build, you can access the Command Explorer by naviation to View->Other Windows->PowerShell Command Explorer. It provides very similar functionality to what is in the PowerShell ISE. This feature is looking very complete and will be merged into the main branch in a couple days. Check it out below!


Please play and provide feedback.

Categories: Powershell

Thread Slivers eBook at Amazon

Syndicate content