PowerShell in Hyper-V 2008 R2

Hyper-V Server 2012 may be the focus on all the blogs out there now, but 2008 R2 still has a large installed base and is likely to have it for some time. In addition to the expansion of PowerShell to version 3 in the 2012 releases, numerous cmdlets were built-in to manage Hyper-V. These weren’t exactly new in that version. Many of them had been freely available for Hyper-V Server 2008 R2 as well. This post will take a quick look at that library.

How To Get The PowerShell Library for Hyper-V Server 2008 R2

The PowerShell library for the 2008 R2 editions of Hyper-V is hosted on Codeplex. Make sure you download the version that matches your hypervisor (with or without service pack 1). Make sure that you unblock the .ZIP before you extract it, even if the computer you ultimately place the library on is not the one you intend to run it on. The block status exists in an alternate data stream so it follows the file wherever its moved or copied to. To unblock it, right-click on it in Windows Explorer and go to Properties. There will be an “Unblock” button; click it and then click OK. If the ZIP file isn’t unblocked, each file within it will be blocked and you’ll run into lots of issues attempting to execute the files.

If PowerShell isn’t enabled on your Hyper-V system, run the following:

DISM /Online /Enable-Feature /FeatureName:NetFx2-ServerCore /FeatureName:MicrosoftWindowsPowerShell

The feature names themselves are case-sensitive but everything else can be typed however you like. The first feature installs the Core-specific edition of the .Net Framework 2.0, which is required for full PowerShell functionality. In some cases, installing PowerShell may require a reboot of the system.

With PowerShell installed, you can place the extracted files in a temporary location on the target machine. At an elevated command prompt on that machine, execute “install.cmd”. This will create a “HyperV” subfolder in the Program Files folder and copy all the scripts to that location. It will also import a few items into the registry. Most of these are benign. The only one to take note of is the conversion of the PowerShell execution policy to “Remote Signed”.

Mostly for informative purposes, be aware that “RemoteSigned” is potentially a security risk. In the default mode (Restricted), scripts aren’t allowed to run at all. There are other options, viewable on Technet. One mode allows scripts to run if they’ve been digitally signed; unfortunately the signature requires a certificate from an authority that the target computer trusts, and for Internet distribution, that means a non-trivial out-of-pocket expense for the signer. Most people publishing free scripts on Codeplex and similar sites aren’t going to go to that trouble. The RemoteSigned mode is a fairly reasonable compromise as it allows scripts to run, provided that someone has taken the time to unblock the files first. Of course, there’s nothing stopping you from unblocking a malicious or poorly coded script, but then there’s nothing stopping a coder that is inept or truly determined to spread malicious script from purchasing a digital certificate, either.

[optin-monster-shortcode id=”lwzgfpb294pntqna”]

Why It Matters

This is the library that actually got me to take a serious look at PowerShell. Like anyone else, I trend toward stasis — I knew how to manage my systems, including Hyper-V, using other methods and tools. I didn’t have a lot of incentive to learn PowerShell. However, there eventually comes a point in every administrator’s life in which a scripted command-line operation is the only realistic way to achieve the desired outcome. If it hasn’t happened to you yet, rest assured that it will, and it will happen multiple times in your career. I don’t recall at this time what it was that drove me to looking for a Hyper-V scripting solution, but I know that once I had this library, I spent two weeks tearing it apart and using it to build a foundational understanding of PowerShell. PowerShell is the direction that Microsoft is heading for scripting solutions across its product spectrum and other companies are following in their footsteps. Quite simply, the longer you wait to get on the PowerShell bandwagon, the worse it’s going to be for you when that time finally comes. PowerShell and its cmdlets will certainly become more powerful, but its scope and complexity is only going to grow.

Using the Library

To make the commands available, you need to execute the following after starting PowerShell:

Import-Module HyperV

If you’d like to permanently load the module (or any other PowerShell module), there are a few ways you can achieve this. Probably the easiest way is to create a “profile.ps1” file in %userprofile%\My Documents\WindowsPowerShell. You’ll have to create the WindowsPowerShell subfolder, and that is exactly how you must spell it. Anything you put inside profile.ps1 will run every time you start a PowerShell prompt with your user account. For purposes of this point, insert the Import-Module command as it appears above and you’ll have those cmdlets available in each PowerShell session.

Getting Acquainted

There are a huge number of commands inside this library. What I would first recommend that you do is go to the downloads page for the module; under “Recommended Downloads”, there is a ZIP file that contains the documentation for this module. It is very thorough and well-laid out. My only complaint is that the author didn’t place page numbers on the individual pages. I’m a big fan of printed material, so I did wind up jumping through a few hoops to get page numbers added.

One thing to keep in mind is that even though this library is related to what released with the 2012 editions, they are not the same library. The commands have a different name format, syntax, and in some cases capabilities.

Some Things You Can Do With This Library

Move-VM

This is a LiveMigration cmdlet. Would you like to have your own “Maintenance Mode” that operates the way you want it to? This is the cmdlet you want to become familiar with.

Merge-VHD

and

Remove-VMSnapshot

Like most PowerShell cmdlets, the above are pretty self-explanatory. Test and development environments often use differencing disks to distribute changes to a master image. Combined with Invoke-VMShutDown and some careful scripting, you can cycle through and merge any differencing disks — even on a schedule. If you want to ensure that no snapshot ever gets past a certain age, this is a great place to start.

Test-VMHeartbeat

Do you have your own monitoring system? The Test-VMHeartbeat cmdlet is a good usage for it. This cmdlet requires successful communication with the integration services inside the VM. This could be seen as a negative since a VM without those components is always going to fail that test, but it’s also a positive because just knowing that a VM is powered on may not be a sufficient test. A powered VM might be sitting at a blue screen or in some other unresponsive state.

Note

Although I had really good luck with this library, it doesn’t have the full vetting that the built-in 2012 editions do. I had troubles setting vNIC VLANs using this library, and I participated in a LinkIn conversation in which another individual reported that they had intermittent troubles with a more involved scripting set. So, as with anything else, be warned that your mileage may vary.

Get out there and start your scripting!