You dont have javascript enabled! Please enable it!

What’s New in PowerShell For Hyper-V In Windows Server 2016 Technical Preview 2? #HyperV #PowerShell #WS2016

5 Min. Read

Hello folks,

In October last year, Microsoft released Windows Server Technical Preview 1 bits along with System Center Technical Preview and Windows 10 Technical Preview.

On Monday, May 4th, 2015, during the Ignite conference, Microsoft released Windows Server 2016 Technical Preview 2 bits along with System Center Technical Preview 2.

Windows 10 is slated to be released on July 29th onwards, the upgrade for Windows 10 will be made available through Windows update, so make sure to reserve your free upgrade by completing the registration and you have sufficient bandwidth to download the update.

As we can see that 2015 is an exciting year, however the final release of Windows Server 2016 and System Center is not until 2016! When? don’t ask me, I don’t know…    

In today’s blog post we will look at what’s new in PowerShell for Hyper-V in Windows Server 2016 Technical Preview 2 versus Technical Preview 1.

The Hyper-V PowerShell module includes several significant features that extend its use, improve its usability, and allow you to control, automate and manage your Hyper-V environment entirely.

The Hyper-V PowerShell module in Windows Server 2016 TP1 ships with 186 PowerShell cmdlets.

If we look into PowerShell on Windows Server 2016 TP2 and count the Hyper-V cmdlets that are available at our disposal.


As you can see we have 204 cmdlets in Hyper-V 2016 TP2 versus 186 in Hyper-V 2016 TP1, so we have 18 new cmdlets so far Winking smile

One important note to mention is that starting with Windows Server 2016 TP2 and Windows 10, Microsoft will ship two Hyper-V PowerShell modules in-box Version 1.1 and Version 2.0 to help you manage cross-versions Hyper-V hosts 2012, 2012 R2, and 2016.


What are these new cmdlets? Let’s compare Hyper-V 2016 TP1 and TP2 modules side by side and explore the difference.

I will use the Compare-Object cmdlet, but before doing this you need to capture the XML file with all Hyper-V PowerShell cmdlets from WS2016 TP1 and TP2 hosts.

TP1 Host: Get-Command -Module Hyper-V | Export-Clixml C:\HyperV-TP1-Compare.xml

TP2 Host: Get-Command -Module Hyper-V | Export-Clixml C:\HyperV-TP2-Compare.xml


The result above will be a table telling you what is different. Every PowerShell cmdlet that’s in the reference set (HyperV-TP1-Comapre.xml), but not in the difference set (HyperV-TP2-Compare.xml), will have a <= indicator (which indicates that the cmdlet is present only on the left side). However If a cmdlet is on the difference Hyper-V TP2 host but not on the reference TP1 host, it will have a => indicator which is our case here with 18 new cmdlets and 6 updated cmdlets on the right side. Finally, PowerShell cmdlets that match across both sets won’t be included in the difference output.

All the previous PowerShell cmdlets that are available in Windows Server 2012 R2 and 2016 TP1 Hyper-V are available as well in Windows Server Technical Preview 2 in addition to the following:


Let’s dive in and discover what these new cmdlets bring to Hyper-V 2016 in TP2.


Trust is the biggest blocker to cloud computing adaption. Microsoft in Windows Server 2016 they are doing a lot of work in the Hyper-V core platform to start providing these guarantees. Even if you trust or don’t trust your IT administrator, no one can access your data!

A virtual TPM (Trusted Platform Module) can be injected into a VM. Then you can enable BitLocker in the VM and protect your data from anyone outside of the VM. So you can now have a virtual machine running on someone’s else Hyper-V server or on someone’s else infrastructure and you can know that you are the only one who has access to that data.

As for the deployment side, this can be done through Active Directory Attestation or through TPM Attestation, the TPM Attestation requires TPM Version 2.0 chip to be installed on the physical host.

For demo purposes only, you can add Virtual TPM for a Virtual Machine using the following steps (this is not secure):

1. Enable Hyper-V 2016 TP2
2. Install-WindowsFeature –Name Isolated-UserMode
3. Restart Hyper-V Host
4. Create a Gen2 VM
5. Install the Guest OS, then make sure to enable Remote Desktop, and finally turn off the VM.
6. Configure Virtual TPM by run the following cmdlets:

7. Start the VM, vTPM should show up in the Guest OS under device manager

Note, the VM console access is not available for shielded VM, therefore you need to access the VM through RDP.


Microsoft published a step-by-step installation and validation guide for Windows Server Windows 2016 TP2 (build #10074) and System Center VMM for Guarded Fabric Hosts and Shielded VMs. You can download the full guide from here.

Enable-VMConsoleSupport, Disable-VMConsoleSupport

The VM Console Support is for human interface devices which is a part of the USB specification for external peripherals, limited functionality at the moment, but it looks like that we will be able to connect and inject direct HID devices into the guest OS.


Get-VHDSet, Optimize-VHDSet

There is a new type of VHD file that Microsoft introduced in Windows Server 2016 TP2 called VHD Set (VHDS) and it’s necessary for some of the new shared VHDX functionality that we have. The Shared VHDX file still exists, so if you have existing guest clusters using the VHDX file you can continue to use those VHDX files for guest clusters. However, you will not be able to do the online resize and the host-based backup. The good news is that Microsoft will provide tools to do a very quick and easy upgrade from a VHDX, to a VHDS file so you can take advantage of that.



Get-VHDSnapshot, Remove-VHDSnapshot

The Get-VHDSnapshot and Remove-VHDSnapshot are used to manage the new Shared VHD Set File (VHDS). Limited functionality at the moment.


New-VMGroup, Get-VMGroup, Rename-VMGroup, Remove-VMGroup, Add-VMGroupMember, Remove-VMGroupMember

The VM Group cmdlets are to group multiple virtual machines into one group, for example, a three-tier application which is consists of a back-end database, mid-tier application, and front-tier web server, or if you want to manage a group of Virtual Machines altogether.

First, you need to create a new Group and choose the Group Type (VMCollectionType or ManagementCollectionType


Next, you can start adding Virtual Machines into the group using Add-VMGroupMember / Remove-VMGroupMember. Limited functionality at the moment.

Get-VMHostCluster, Set-VMHostCluster

Microsoft is providing a single view of an entire Hyper-V cluster through WMI. You can manage an entire Hyper-V cluster like it were just one big Hyper-V Server.

So for example with Get-VM, if you actually point it to a single Hyper-V host you get all the virtual machines on that particular host, however, if you point it at your Hyper-V cluster, what’s going to do, it’s going to return all the virtual machines on that cluster, so you can take the output and pipe it into all various PowerShell commands, makes it a lot easier to start operating on a cluster of Hyper-V using PowerShell.

Get-VMHostCLuster –ClusterName <ClusterName> -Credential $Cred

Set-VMHostCluster -ClusterName <ClusterName> -SharedStoragePath \SOFS\SHARE1

Start-VMTrace, Stop-VMTrace

The VMTrace is targeted to trace Virtual Machines based on different informational levels such as (Error, Info, Warning, Verbose, Off).


Add-VMSwitchTeamMember, Set-VMSwitchTeam, Get-VMSwitchTeam, Remove-VMSwitchTeamMember

In Windows Server 2012 / R2, when we create a Teaming vSwitch, we will create first an LBFO team (New-NetLbfoTeam), and that creates a new teamed adapter in the system, and finally, we connect that adapter into the Hyper-V vSwitch. However in Windows Server 2016 TP2, Microsoft introduced a new teaming mode called SwitchEmbeddedTeaming, this will allow us to simply connect all the physical adapters directly into the Hyper-V virtual switch, and then the virtual switch internally will handle the spread of traffic between these adapters from the inside of the switch, so the virtual switch will handle that traffic coming in and going out more efficiently.

First, you need to create a New vSwitch and enable Switch Embedded Teaming is the following:

Note: Please note that this is not working in the current (build #10074).  HyperV_PoSh_TP2-17


The process to upgrade a virtual machine version requires to shut down the VM, and do a manual upgrade. This is a one-way process so you can either do this through PowerShell or through the Hyper-V Manager console. To upgrade the VM Configuration File through PowerShell, you need to run the following cmdlet from an elevated Windows PowerShell:


If you want to automate the upgrade VM version process, then make sure to check this post.

I will update this blog post as soon as Technical Preview 3 will come out!

Note: This is the current release of Technical Preview #10744 build, so we’ll have to wait and see the changes in the next bits…

Until next time… Enjoy your weekend!


Photo of author
About the Author
Charbel Nemnom
Charbel Nemnom is a Senior Cloud Architect, Swiss Certified ICT Security Expert, Certified Cloud Security Professional (CCSP), Certified Information Security Manager (CISM), Microsoft Most Valuable Professional (MVP), and Microsoft Certified Trainer (MCT). He has over 20 years of broad IT experience serving on and guiding technical teams to optimize the performance of mission-critical enterprise systems with extensive practical knowledge of complex systems build, network design, business continuity, and cloud security.

Under The Hood: How Does Savision’s Dashboards Work? #Savision #SCOM #SysCtr

Using Windows 10 Client HyperV – Whitepaper


Let me know what you think, or ask a question...

error: Alert: The content of this website is copyrighted from being plagiarized! You can copy from the 'Code Blocks' in 'Black' by selecting the Code. Thank You!