On Windows PowerShell and other admin-related topics

System Center Virtual Machine Manager vCheck

System Center Center Virtual Machine Manager (SC VMM) is part of the Microsoft System Center family, used to manage virtual infrastructures. The 2008 R2 version supports managing both Microsoft Hyper-V and VMware (communicating via VMware vCenter), while the 2012 version which was released in April 2012 added support for Citrix XenServer. Among the added benefits of using SC VMM for managing your hypervisor infrastructure is capabilities such as Physical to Virtual (P2V) conversion, creating virtual machines based on templates as well as having a centralized console for management. The 2012 release also added capabilities for managing private cloud infrastructures, where the managed hypervisors will be abstracted under the new Fabric bar:


There are many additional changes in the 2012 release, including the ability to manage services, storage, networking, cluster creation and many more. If you are interested in learning more I would recommend you to watch the TechNet Edge video Virtual Machine Manager 2012: Technical Overview as well as dig into the product documentation (link in the Resource section below).

Most, if not all, Hyper-V production environments I have worked with use SC VMM for management. One thing that many administrators may miss however, is a quick glance at the status of the environment. You do of course see the status of the hosts and virtual machines by opening the console, but other things such as old checkpoints and the use of dynamic virtual hard disks instead of Fixed size virtual hard disks is not easily discoverable. Since SC VMM is based on Windows PowerShell (for example, you get a “View Script” button showing the complete PowerShell code when creating a new virtual machine), gathering this information and presenting it in a report is not so difficult. Let me introduce the SC VMM vCheck:


SC VMM vCheck

If you work with both PowerShell and VMware, there is a good chance you have seen and used Alan Renouf`s very useful vCheck script:

vCheck is a vCenter checking script, the script is designed to run as a scheduled task before you get into the office to present you with key information via an email directly to your inbox in a nice easily readable format.

For more information and detailed usage guidance, see this article.

Beginning with the 6.0 release of vCheck, Alan added the support for Plugins, making it easier for the community to contribute with their own checks. I had several snippets of PowerShell code for checking various things such as VMs with snapshots, so when I saw the new Plugins capability added to vCheck I thought it would be a good opportunity to provide a SC VMM Plugin. Here is the initial checks in the SC VMM Plugin for vCheck:

  • SC VMM Connection Plugin
  • General Information
  • SC VMM Basic Host Information
  • Hyper-V Cluster Shared Volumes
  • Hyper-V VMs with snapshots
  • SC VMM New VMs
  • SC VMM VM Operating System Statistics
  • Hyper-V VMs with mounted ISO
  • Hyper-V Legacy VM NIC Adapters
  • Hyper-V VMs with static MAC address
  • SC VMM Dynamically Expanding Disks
  • SC VMM Dynamically Expanding Disks Consolidation Forecast
  • Hyper-V Integration Components Version
  • Hyper-V 2008 R2 SP1 Capacity Report

As you can see I have divided the plugins into two categories, one for SC VMM which works across all supported hypervisors, as well as some specific for Hyper-V.

vCheck contains a ps1-file named GlobalSettings.ps1, where you can specify the name of the SC VMM server, e-mail settings (if you want the report e-mailed to you) as well as HTML color codes. Here you can see two examples of the same report using different colors:

image  image

You can download the plugin from this link:

SC VMM vCheck Plugin Download

If you want to add a new Plugin, all you need to do is to create a ps1-file in the Plugins-folder, preferably in a subfolder. Then you add the following 7 variables at the top of the file, and your code at the bottom. The main script will pick up objects from the Plugins, so make sure you output objects with only the desired properties. For example Get-VM | Select-Object name.

We can look at the VM Operating System Statistics as an example:

$Title = "VM Operating System Statistics"
$Header ="VM Operating System Statistics"
$Comments = "VM Operating System Statistics"
$Display = "Table"
$Author = "Jan Egil Ring"
$PluginVersion = 1.0
$PluginCategory = "SC VMM"

# Start of Settings
# End of Settings

$VMs | Group-Object operatingsystem | Select-Object name,count | Sort-Object count -Descending

This is actually a PowerShell “one-liner” turned into a vCheck Plugin. Note that the $VMs variable contains all virtual machines managed by SC VMM and is created in the SC VMM Connectivity Plugin. The settings section is not used by the above plugin, however, this is a section intended for Plugin specific settings such as the threshold for how old snapshots you want to include in the report.

Over time the SC VMM Plugin will hopefully grow by added community contributions. If you want to contribute, or have suggestions for new Plugins, please add them to the SC VMM Plugin site`s comment section, as more people will discover them there compared to this article.

If you want to hear more about the SC VMM vCheck I was interviewed to talk about it on the Get-Scripting podcast, you can download the episode from here.



System Center Virtual Machine Manager 2012 on Microsoft TechNet

System Center Virtual Machine Manager 2008 and 2008 R2 on Microsoft TechNet

Automate a task in System Center Virtual Machine Manager 2012 based on the “View Script” button


May 31, 2012 Posted by | Hyper-V, System Center, Windows PowerShell | | Leave a comment

Hyper-V: How to unbind a physical NIC from a Virtual Switch using WMI and PowerShell

If you`re not already familiar with networking in Microsoft Hyper-V I would recommend you to have a look at this whitepaper from Microsoft, which described how networking works in Hyper-V.

The following solution will describe a problem which might occur when configuring virtual networks in Hyper-V. Consider the following scenario:

  • You`re about to configure a new external virtual network in Hyper-V using Hyper-V Manager remotely from another computer. This is a common scenario when working with the Core edition of Windows Server 2008/2008 R2.
  • When selecting the physical NIC to bind to the new virtual network, you choose the adapter which you are remotely connecting to the Hyper-V host through.

What happens in this scenario is that the Virtual Switch Management Service is binding the external Ethernet port for the selected NIC to the Microsoft Windows Virtualization network subsystem. What normally should happen next is that the converted Ethernet port should be bound to the new virtual switch you are creating. However, this never happens since the NIC you are remotely managing the Hyper-V host through is no longer available in the parent operating system. This leaves the NIC in an “orphaned” state, since you cannot use the NIC in the parent operating system, and it`s not in use by any virtual networks.

To resolve this issue, whether using the full GUI version or the Core version of Windows Server, you need to manually unbind the the Ethernet port. There is an UnbindExternalEthernetPort available on the Msvm_VirtualSwitchManagementService WMI class, which is fully documented in this article on MSDN.

To invoke the WMI method we can use Windows PowerShell. To ease the procedure I`ve created a PowerShell function you can use if you ever come into the need for manually unbinding an external Ethernet port in Hyper-V:


Function Select-List
    Param   ([Parameter(Mandatory=$true  ,valueFromPipeline=$true )]$InputObject, 

    begin   { $i= @()  }
    process { $i += $inputobject  }
    end     { if ($i.count -eq 1) {$i[0]} elseif ($i.count -gt 1) {
                  $Property=@(@{Label=“ID”; Expression={ ($global:Counter++) }}) + $Property
                  format-table -inputObject $i -autosize -property $Property | out-host
                 $Response = Read-Host “Select NIC to unbind”
                  if ($response -gt “”) { 

function Remove-HVExternalEthernetPort {

$ExternalEthernetPort = Get-WMIObject -class “Msvm_ExternalEthernetPort” -namespace “root\virtualization” | Select-List -Property name

$HVSwitchObj = Get-WMIObject -class “MSVM_VirtualSwitchManagementService” -namespace “root\virtualization”

if ($ExternalEthernetPort) {
else {
throw “An error occured. Choose a valid ExternalEthernetPort from the provided list”


Note: The Select-List function is a modified version of the Select-List function available in the PowerShell Management Library for Hyper-V available on CodePlex (see link below).

You can either paste the function into a PowerShell session or save it into ps1-file and dot source it. When done you can invoke the function like this:


When you`ve entered the index number for the NIC you want to remove, a return value of 0 indicates the operation succeeded. Any other value indicates an error (look at the previous mentioned MSDN-article for more information).


More resources on managing Hyper-V using PowerShell

PowerShell Management Library for Hyper-V – this is an excellent PowerShell module for managing Hyper-V available on CodePlex

System Center Virtual Machine Manager 2012: Scripting

System Center Virtual Machine Manager 2008 R2: Scripting

Hyper-V WMI Using PowerShell Scripts

Script: Determining Virtual Switch Type Under Hyper-V

August 30, 2011 Posted by | Hyper-V, Hyper-V R2, Scripting, Virtualization, Windows PowerShell | , , | 1 Comment

Enable Persistent Mode for Cluster Resource Groups using the PowerShell Failover Clustering module

In Failover Clustering in Windows Server 2008 R2, Persistent Mode is intended to allow resource groups to come online on the node which an admin last moved them to. This setting is enabled by default when a virtual machine is created with Failover Cluster Manager. If you create virtual machine via System Center Virtual Manager this setting is not enabled.

By default, cluster roles have this setting disabled, except for Hyper-V virtual machine cluster roles, which have this enabled by default. This setting is useful when the cluster is shutdown and later started, in order to better distribute the resources across the nodes and allow them to come online faster, as they were likely spread across the nodes before the cluster was offlined. Otherwise, all the resources will attempt to restart on the first nodes which achieve quorum and compete for resources. This only applies to a group if it did not failover after being placed by the administrator. If a group has failed over since the last administrator placement, it is brought online on the node which the administrator last move it to.

Reference and more info regarding the Auto Start, Persistent Mode and Group Wait Delay features is available on the Clustering and High-Availability blog.

Auto Start can be enabled/disabled in bulk by marking all Cluster Resource Groups in Failover Cluster Manager and selecting “Enable auto start”/”Disable auto start”.

For Persistent Mode the only available option in Failover Cluster Manager is to right click each Cluster Resource Group and selecting/de-selecting the checkbox for “Enable persistent mode”:


To change this setting for all Cluster Resource Groups in an automated fashion you can use the Failover Cluster module for PowerShell, which I wrote an introduction to here.

Here is an example on how you can do this:

Import-Module FailoverClusters
$clustergroups = Get-ClusterGroup -Cluster cluster01.domain.local
foreach ($clustergroup in $clustergroups) {
#To enable persistent mode: x To disable persistent mode: 4294967295

Although you can change the Auto Start setting in bulk in Failover Cluster Manager you might also want to do this in an automated fashion:

Import-Module FailoverClusters
$clustergroups = Get-ClusterGroup -Cluster cluster01.domain.local
foreach ($clustergroup in $clustergroups) {
#To enable Auto Start: 1 To disable Auto Start: 0

You can also change the Group Wait Delay cluster-wide property from the PowerShell Failover Clustering module, how to do this is explained in the above referenced blog-post from the Clustering and High-Availability blog.

For the next version of System Center Virtual Machine Manager I would expect that Persistent Mode is enabled by default, since Microsoft do recommend customers to enable this setting.

Update 08.12.2011: The value of the DefaultOwner property for configuring Persistent Mode is the number of the node you want to be the default owner. In example a value of 1 means the first node in the cluster.

June 3, 2011 Posted by | Failover Clustering, Hyper-V, Hyper-V R2, Scripting, Windows PowerShell, Windows Server 2008 R2 | , | 3 Comments

Hyper-V R2 and storage location for snapshot differencing disks

I recently worked with a Hyper-V case, where the differencing disk files (.AVHD) for snapshots didn`t appear at the expected location. As we figured this out, I would like to share the experience we had regarding this.

A virtual machine has two important directories, the VM root and the snapshot root. The VM root is where we store the virtual machine configuration file (XML) and the saved state files (.BIN and .VSV). The snapshot root is where we store the config and saved state files for each snapshot of a virtual machine.

Virtual hard disks (.VHDs) are stored where ever the user specifies when creating the virtual machine (or when creating a new virtual hard disk).

What has changed in Hyper-V between Windows Server 2008 and Windows Server 2008 R2 is the placement of .AVHD files (these are the differencing disks created for each snapshot). In Windows Server 2008 the .AVHD is always created in the snapshot root location, which by default are located at C:\ProgramData\Microsoft\Windows\Hyper-V\Snapshots. This caused a lot of people problems – as they would run out of space on the partition where the snapshot root folder was. In Windows Server 2008 R2 the .AVHD file is always created in the same location as its parent virtual hard disk.

This means that with R2 .AVHD files will always appear beside their respective .VHD files. The one exception to this is if you bring across a Windows Server 2008 virtual machine with .AVHDs already in the snapshot root. In this case new .AVHDs will be created beside their parent .AVHDs (in the snapshot root).


Microsoft TechNet Resources

Hyper-V in Windows Server 2008
Hyper-V R2 in Windows Server 2008 R2

February 23, 2010 Posted by | Hyper-V, Hyper-V R2, Windows Server 2008, Windows Server 2008 R2 | | 1 Comment