Windows Server 8 Hyper-V Management Improvements

Another big investment by Microsoft in Windows Server 8 Hyper-V was how we interact with the product. With lots more functionality, and some of it being very advanced and not required by everyone, they had to decide how to present it in the GUI.  And with huge cluster scale out (up to 64 hosts per cluster) and target markets such as hosting and large enterprise, automation was of great importance.

The GUI – Hyper-V Manager console (HMC)

On the face of it, the GUI has not changed much.  There is no ribbon bar and things can be found where they previously were in the Windows Server 2008 Hyper-V and Windows Server 2008 R2 Hyper-V HMCs.

Often we fire up the HMC to just look for information.  Tabs have been added in the lower centre pane of HMC to show us information, e.g. summary, memory, networking, and Hyper-V Replica (aka Replica).

Nested Nodes

When you open the settings of a VM to change it’s configuration you will notice that the CPU and Networking nodes on the left are nested.  There are sub-nodes with more settings.  This is done for some reasons including:

  • It cleans up the GUI  Even with newly added scroll bars, there’s only so much you can squeeze into a single screen without making things messy and unusable.
  • It hides away advanced features that should only be used by engineers who know that they do and know that they need them, e.g. the NUMA override settings.

Clustering Interaction

A classic problem for the forums was when a person would edit the settings of a VM in the HCM and live migrate the VM from one host to another in a host cluster.  Their new settings were lost because the cluster database was not updated.  You had to either use Failover Cluster Manager (FCM) to edit the VM settings (auto-update of settings) or remember to manually update the VM resource in FCM after editing it the VM in HCM.

Now, HCM will detect that a VM is clustered and prevent you from editing the settings.  You must use the FCM instead, and quite right too!


Have you ever been ticked off when you use VMConnect to get a console connection to a VM and then you fail it over to another node in a Hyper-V Cluster?  Actually, ticked off isn’t the right word the first time you see this: you crap yourself when VMConnect loses the console connection to the VM and confusingly tells you that the VM must have been deleted!  That’s changing in Windows Server 8.  Yes, VMConnect will disconnect – briefly.  The source host for the VM will redirect the VMConnect session to the VM on the destination host.  No more tingling in the left arm or tightening of the heart when working on a VM at midnight.  Hyper-V engineers and their doctors thank you, Microsoft!

PowerShell 3.0 Cmdlets

The big change is that Hyper-V will have built-in PowerShell (POSH) cmdlets for the very first time in Windows Server 8.  Even from a POSH-disabled person like me, the cmdlets looked easy to use and very powerful to me in the hands on lab that I did.  For you POSH purists, I’ve been told that the Hyper-V POSH cmdlet specs were written so things would be done the POSH way.

With some hep I had created a script that read in some specs from a CSV file, created a bunch of differential disks, created lots of VMs, and connected them to those disks.  One test lab up and running in a few minutes, that could be recreated in a moment’s notice.  I’m sure with more practice, I could have made the script much more elegant than I had in the limited time window.

It’s this sort of thing that the POSH cmdlets are intended to enable.  Big hosting companies can automate deployment from their “control panels”.  Enterprises can automate bulk configuration changes.  We people who demo can deploy a new lab in seconds.  And with POSH 3.0 Workflows you can build complex scripts that work reliably and in an orchestrated manner across many machines and applications.

Just like Exchange, not every admin function is in the GUI.  Some things will have to be done in POSH.  I guess I will have to learn it after all these years of saying “I will have to learn PowerShell”.

PowerShell: Use the PowerShell Integrated Scripting Environment (ISE) GUI

Those of us who are old enough started working with computers from a scripting interface (BASIC) or via green screen.  You old geezers with punch cards probably find PowerShell really easy.  Those who have grown up using the Windows GUI must find PowerShell totally alien – searching for help  and configuring a machine from a command prompt.

You can make things a little easier using ISE, the Integrate Scripting Environment.  You can add this Windows feature (a subset of Windows PowerShell in Windows 8) to make scripting and configuring a little easier.

The Commands pane allows you to find cmdlets in any or all modules.  Select it, hit Insert and it goes into a PowerShell pane (bottom-left).  Or you can Copy the cmdlet, and paste it into the script pane (middle).


In my previous posts I’ve talked about using help and get-member to figure out what a cmdlet can do.  With ISE, you have Intellisense.  In my example, I’ve used Insert to put the Get-NetAdapter cmdlet into the PowerShell pane.  Then I typed the hyphen and Intellisense kicked in, presenting everything that was valid from that point onwards. 

If you don’t know the cmdlets you’re working with, this is a nice way to figure out things in an environment that can be a little more helpful.

If you run the cmdlet in the bottom-left scripting pane, then the results appear in the top-left pane.  If you write a script in the middle pane and hit the green run arrow that appears in the menu bar, then you see the results in that top-right pane as well.  That keeps the whole environment nice and clean, and allows you to modify things quickly without jumping from window to window.

Technorati Tags: ,,

PowerShell: Get More Information On Your CmdLets

With the PowerShell Window, you can run Help or Get-Help to go looking for information of syntax and flags.  If you want, you can even use the get-member cmdlet, such as:

Get-NetAdapter | Get-Member

There’s two things that are happening with the above command.  Get-NetAdapter is being run, and then we’re using a pipe to send the output as an input to Get-Member.  Get-Member will list all of the attributes of the Get-NetAdapter output, including methods and properties.  You might want to filter that down, and you can do that by running:

Get-NetAdapter | Get-Member –MemberType Property

Where did I get –MemberType from?  Look at the titles of the columns from the previous command.  One of them was called MemberType.

I could have just as easily used:

Get-NetAdapter | Get-Member –Name *Interface*

That would have limited the results to attributes of Get-NetAdapter that contained “Interface” in their name.

Technorati Tags: ,

Hyper-V & PowerShell – Getting The Host On The Network

Note: I’d normally configure TCP-IP at this point but the cmdlets that I seem to need to use either are not working correctly or are very confusing – that’s pre-beta software for you!  I’ll try to return to that topic at a later point if I find a solution.

When you install Windows without some clever imaging solution, the machine comes up with some random (not completely) computer name.  You can PowerShell this if you want:

Rename-Computer MyNewComputerName –restart

In a previous blog post I mentioned that POSH (PowerShell) is great for scripting.  You can put a whole load of these commands in a single PS1 file and run it.  This cmdlet is an example of where you’d need user input.  In that case, the following embeds the prompt for a new computer name inside of the Rename-Computer cmdlet.  When you run this, the embedded Read-Host cmdlet is run and provides the user input to the Rename-Computer cmdlet.

Rename-Computer (Read-Host “Enter a new computer name”) –restart

Once that reboot is done, you can join a domain.  The following cmdlet does just that.  It will fire up a traditional Windows prompt for a user name and password to do the domain join.

Add-Computer –DomainName “demo.internal” –Restart

Want some help and examples beyond what you can get from Get-Help?  Try this:

Get-Help Add-Computer –Online

That should fire up your web browser and bring you to an official MSFT web page for the cmdlet in question.  A nice example you’ll find for Add-Computer is that you can use the –OUPath flag to specify a location to place the new computer object in your domain.  I tend to have a special OU for Hyper-V hosts so that’s where I’d place the computer object.  So instead of using the default computer object creation location (and probably forgetting to move the object to the correct one before the reboot), I can save some human effort by running:

Add-Computer –DomainName “demo.internal” –OUPath “OU=Hyper-V, OU=Servers, OU=Company, DC=demo, DC=com” –Restart

And that’s your host named and in the domain, all ready to manage with SCVMM.

Hyper-V & PowerShell – Enable Hyper-V

Windows 8 includes native PowerShell cmdlets for Hyper-V for the first time ever.  You can use this to manage Hyper-V from the command prompt and to automate complex and/or repetitive tasks.  In fact, Hyper-V appears to be going down the Exchange route where only so much is revealed in the GUI, and everything is in PowerShell.  I’d expect System Center Virtual Machine Manager to provide that additional GUI functionality (and use PowerShell under the hood).

But before you even get to doing Hyper-V cmdlets, you’ll need to enable the Hyper-V role.  One could use Server Manager, but we’ll use the Server Manager cmdlets instead.  You can learn lots more about this cmdlets in the chapter that I wrote on Server Manager in Mastering Windows Server 2008 R2.

PowerShell cmdlets are a subset of modules.  To use a cmdlet you have to load the relevant module.  Which one?  You can run a cmdlet to find that out:

Get-Module –ListAvailable

You’ll notice that PowerShell works in the format of Verb–Noun (action-thing to manage) with optional flags.  In this case it’s retrieving the list of all available modules that can be imported.

Then I can run the following to import the Server Manager module to get access to the relevant cmdlets:

Import-Module ServerManager

Try this: type in half of ServerManager and press <TAB>.  This should autocomplete the text for you.

If I now run the following cmdlet then I get a list of all imported modules:


Note: that if I knew what I was doing, I would have just run the Import-Module cmdlet to import ServerManager.

What cmdlets are not available to me?  There’s a cmdlet for that.  I can run Get-Command but that lists every available cmdlet.  I want to see the ones in the ServerManager module:

Get-Command –Module ServerManager

It turns out that I have:

  • Get-WindowsFeature: list what features and roles are available, and what their install status is (indicated by an X).
  • Install-WindowsFeature: install a feature or role
  • Uninstall-WindowsFeature: install a feature or role

Need some help? That’s built in too:

Help Get-WindowsFeature

We want to know what the state of the machine is so we can run


This spits out a list of every role, role service and feature that you can install or uninstall via Server Manager.    You should note the name(s) of the ones you want to work with because you you’ll need them for the next step.

When you check the help of Install-WindowsFeature you’ll see some interesting flags:

  • -Whatif: It doesn’t run the cmdlet, but it simulates it.  It will tell you (to the best of its ability) if the command will work or not.
  • -Restart: forces and automatic reboot to happen, rather than prompting for it.  I know that enabling Hyper-V requires a reboot so this is useful.

For example this will simulate the install of the Hyper-V role:

Install-WindowsFeature Hyper-V –Restart –Whatif

If I’m happy, and I know a reboot of the new host is OK then I can run:

Install-WindowsFeature Hyper-V –Restart

A progress bar will appear in the PowerShell window, and the new host will reboot so the Hyper-V role can be enabled and started up.

That sounds like we’d done a lot of cmdlet-ing?  We actually could have consolidated it into two commands or a 2 line script:

Import-Module ServerManager

Install-WindowsFeature Hyper-V –Restart

That simple .PS1 script could have been stored in a file share, attached to a Windows deployment, or used in many different ways to automate a Hyper-V enablement.  And that’s just the tip of the iceberg.

What if you want to uninstall Hyper-V?  Well that uninstall is just like the install:

Uninstall-WindowsFeature Hyper-V –Restart –Whatif

Hyper-V is now up and running, and ready to manage.  Sure, you can use the Hyper-V console, and to be honest, that is my primary tool.  But many will want to use PowerShell for automation.  Here’s how you can get started:

Import the modules with:

Import-Module Hyper-V

And list the cmdlets:

Get-Command –Module Hyper-V

There’s lots there to get playing with!