John Howard - Senior Program Manager in the Hyper-V team at Microsoft : Windows Server 2008

Explaining the Hyper-V authorization model, part five

jhoward — Fri, 09 Oct 2009 21:51:00 GMT

Hyper-V uses a role based authorisation model for access checks. This series of articles takes a look at the model; defines the available primitives; and walks through a couple of examples. (I actually wrote most of this many months ago – only finally found the time to post it up!).

Quick links: Part1; Part 2; Part 3; Part 4

This post describes a change to the authorisation model in Hyper-V for Windows Server 2008 R2. If you recall from part one, I mentioned that there are 33 operations defined in AZMan for Windows Server 2008, and 34 operations for Windows Server 2008 R2.

The new operation has ID 355, ‘Allow Virtual Machine Snapshot’.

Why (to me) is this useful? Have you ever been confronted with a screen such as the following where you want to make Hyper-V Manager the foreground application, but accidentally hit the ‘Snapshot’ action in the MMC? I assure you, I have, several times.

The problem with accidentally hitting that action is that you could now find your production virtual machine using a differencing disk, with reduced performance (at least in v1 – not the case in R2), or the possibility of physical disk space running out. Further, to merge the changes back to the parent VHD so that a differencing disk is no longer being used, you need to delete the snapshot, shut down the virtual machine, wait for the merge to complete and then restart the VM. This is particularly painful when the VM in question is your ISA server for outbound Internet connectivity, or your Exchange server your clients (wife and children in my case) are using for email?

In part six, I’ll look at a solution that I personally use at home on my Windows Server 2008 R2 production environment that builds on what’s been learnt so far to ensure that I can’t accidentally snapshot critical production VMs, but am able to snapshot test VMs to my hearts delight.

Cheers,
John.

Explaining the Hyper-V authorization model, part four

jhoward — Fri, 18 Sep 2009 22:29:00 GMT

Hyper-V uses a role based authorisation model for access checks. This series of articles takes a look at the model; defines the available primitives; and walks through a couple of examples. (I actually wrote most of this series many months ago – only finally found the time to post it up!).

Quick links: Part1; Part 2; Part 3; Part 4

In parts two and three, I walked through a specific scenario. However, you’re probably asking after having read them how I knew what operations are needed, and when, and in what scope. Well, luckily I can walk across the corridor and speak to our development team. Obviously this isn’t practical for most of you reading this, but there are, of course other ways of discovering which access checks are failing. A great resource recently published on Technet is http://technet.microsoft.com/en-us/library/dd282980(WS.10).aspx. However, there’s a sneakier way…. Let’s take a step back through part three, and delete the role assignment and role definition “Service Access” I created to cause a deliberate access check failure.

Next, I turned on auditing for object access. (I’m ignoring the fact that local policy may be over-ridden by group policy in a domain environment – this walkthrough so far is entirely on a workgroup configuration). Start the Local Security Policy snap-in under Administrative tools, and navigate to Security Settings/Local Policies/Audit Policy and change to auditing Success and Failure.

Once done, log back on as user Joe or John and start Hyper-V Manager to validate the user gets the familiar ‘You do not have the required permission to complete this task.’ message.

Now log on as a user with local admin rights and start the event viewer. Select the Security log under Windows Logs, and optionally apply a filter for just events 4665-4667 (actually just 4666 is probably enough).

What you’ll see is the following Audit Failure message for event ID 4666: Joe failed an access check to operation Read Service Configuration (operation ID 100) in scope “blank” (ie the default scope).

So with that knowledge, it’s easy to debug issues in authorisation models that you develop.

In the next part of this series, I’ll look through a really useful change in Windows Server 2008 R2 (and Microsoft Hyper-V Server 2008 R2) which leads me in to a walkthrough in part six of an authorisation policy example I use on my home servers.

Cheers,
John.

Explaining the Hyper-V authorization model, part three

jhoward — Thu, 10 Sep 2009 04:52:00 GMT

Hyper-V uses a role based authorisation model for access checks. This series of articles takes a look at the model; defines the available primitives; and walks through a couple of examples. (I actually wrote most of this series many months ago – only finally found the time to post it up!).

Quick links: Part1; Part 2; Part 3; Part 4

In part two, I started creating the scenario of separating the view two users have when opening Hyper-V Manager so that they only see their own VMs. To do that, I created two VM Scopes, one for each user, and moved the users’ VMs to the required VM scopes. I mentioned that some more steps were still required. This part of the series walks through those steps.

The first part of the additional steps I’ve pretty well covered to death in my remote management of Hyper-V series. As my two users, John and Joe are not local administrators; they need to be granted explicit access to WMI namespaces (and Distributed COM Users if managing remotely). By far the easiest way to achieve this is using HVRemote. (Note, I’m assuming you’re following best practice, and using remote management as the server is running Hyper-V Server, the standalone SKU, or a Server Core installation of Windows Server 2008/2008 R2.)

From an elevated command prompt when logged on as a local administrator, run

cscript hvremote.wsf /add:john

(Use /add:domain\account if the Hyper-V machine is domain joined)

If you look at the output carefully, note the line that says “Adding john to AZMan role Administrator” near the bottom. Apart from a typo I need to correct in a future version, what HVRemote has done is add john to the ‘Administrator’ role assignment in the default scope. This is simply a limitation in HVRemote. At the time of writing, HVRemote cannot cope with VM Scopes. (In fact it is hard coded to always update the role assignment called ‘Administrator’ in the default scope – on my big list and will be covered in the future).

If John and Joe are now administrators in the default scope, we’ve not performed any separation as administrators in the default scope can view all VMs. There are two ways to resolve this. Either we update policy using Authorisation Manager to undo the generalisation HVRemote has made here, or use a parameter available in HVRemote when adding the account.

Method 1 Use Authorisation Manager

Select the Role Assignment ‘Administrator’ in the root scope to find the user which has been added.

Right click on the user and choose delete (or simply hit the delete key)

Method 2 Use a parameter to hvremote

*Caveat this may not work in future releases – it does as of version 0.7 though.

From an elevated command prompt when logged on as a local administrator, run

cscript hvremote.wsf /add:john /noazman

(Use /add:domain\account if the Hyper-V machine is domain joined)

If you compare this output to the previous hvremote output, notice there is no role assignment update in AZMan.

The last part to get our user separation in place require a little thought to get your head around, and a little knowledge of the Hyper-V design.

We have a service called VMMS (Virtual Machine Management Service). There are two operations in our authorisation model which are required to be able to perform operations on the VMMS. VMMS always performs its access checks for these operations in the default scope.

The operations are

Read Service Configuration, and
Reconfigure Service

What this means is that the users I’m separating, John and Joe, must be authorized to these operations in the default scope. It is not sufficient to just have them an ‘administrator’ in the VM Scope. Based on our knowledge from the previous parts, this is easily achieved:

Create a Role Definition ‘Service Access’ containing the two operations in the default scope
Create a Role Assignment ‘Service Access’ linked to the ‘Service Access’ role definition in the default scope
Add John and Joe to the role assignment ‘Service Access’ in the default scope

Authorisation manager should look like the following when done:

All that remains validate the configuration is to log on as those users and start Hyper-V Manager (or use Hyper-V Manager remotely in the case of a server core or Microsoft Hyper-V Server installation).

Here, I’m logged on as John

And here, I’m logged on as Joe

So that works as expected. With the information so far, I hope I’ve provided everything you need to enable you to build a model which makes sense for your own unique implementation. It’s a question of sitting down and working through how to map your organisational needs into authorisation model primitives. There is no single right answer which fits everyone, so building a mapping is not something I can help you with!

In the next part of this series, I’ll take a look at how you could debug issues with a custom authorisation model you develop.

Cheers,
John.

Explaining the Hyper-V authorization model, part two

jhoward — Wed, 02 Sep 2009 21:22:00 GMT

Hyper-V uses a role based authorisation model for access checks. This series of articles takes a look at the model; defines the available primitives; and walks through a couple of examples. (I actually wrote most of this series many months ago – only finally found the time to post it up!).

Quick links: Part1; Part 2; Part 3; Part 4

Part one provided information on the primitives available in the AZMan model and looked at the out-of-box Hyper-V configuration. Building on that information, part two takes a deeper look at scopes.

In part one, I talked about the top level scope (aka root or default scope) as the place where global policy is defined. I mentioned that you can also define more constrained scopes and place virtual machines in those scopes.

The first question to answer is “How can you create a ‘Virtual Machine’ scope?”. Scopes exist at an application level. You can either right-click on an application to create a new scope, as shown in the screenshot below, or use a script if you prefer automation (as I do). (If you’re interested in the specifics of API calls, take a look at http://msdn.microsoft.com/en-us/library/aa375769(VS.85).aspx).

Note that the script is the barest minimum – obviously I would recommend you make something more resilient for general use.
Save the following code as “CreateScope.vbs”.

' Make sure the script is passed a scope to create

szScope = wscript.arguments.named("scope")

if szScope = "" then

    wscript.echo "CreateScope /scope:<name>"

    wscript.quit

end if

' Need to have an object referencing the store

set oAuthStore = _

   CreateObject("AZRoles.AZAuthorizationStore")

' Initialise the store so that we can update it

oAuthStore.Initialize 0, _

   "msxml://C:\ProgramData\Microsoft\Windows\" & _

   "Hyper-V\InitialStore.xml"

' Open the Hyper-V services application in the store

Set oApplication = _

    oAuthStore.OpenApplication("Hyper-V services")

' Create a new scope

Set oNewScope = _

    oApplication.CreateScope2(szScope)

' Submit it to the store

oNewScope.Submit

To create a scope called “My test VM scope”, from an elevated command prompt, type

cscript createscope.vbs /scope:“My test VM scope”

If you already have the Authorisation Manager MMC open after walking through part one, you need to reload the authorisation store by right-clicking on InitialStore.xml in the treeview on the left and selecting Reload. If the Authorisation Manager MMC is not open, open it now and load InitialStore.xml.

When you expand out the tree, you’ll see that a new scope called “My test VM scope” has been created:

You can also see that a “VM Scope” has the same primitives available under it as the “Default” Scope – Groups, Role Definitions, Task Definitions and Role Assignments. You can use the MMC to create role definitions; assign operations to role definitions; create role assignments; link role assignments to role definitions; and assign accounts to role assignments at both the default scope level and at the VM Scope level.

Side note:

Personally, to avoid confusion, I would avoid using role definitions in a VM scope unless you really need to keep a role definition so specific that is has to be tied to a particular VM scope. There is little reason to not create all the role definitions at the default scope level.

At this point, you probably have a question: “Why would I need a ‘Virtual Machine’ scope?” And a great question it is, too. To answer it, let’s consider the following simple scenario:

You have a shared Hyper-V machine. It is used by two users called “John” and “Joe”. Both John and Joe have a single VM of theirs on that server called “Johns VM” and “Joes VM” respectively.

You want the system configured so that John cannot even see that Joe is a user or has VMs on that machine, and visa-versa. John must be able to perform all operations on his virtual machine, and Joe must be able to perform all operations on his virtual machine. Neither Joe or John should be administrators on the physical machine.

Without virtual machine scopes, this is not possible. Let’s work through how you would configure that scenario. I’m going to start with the blank InitialStore.xml again for this. Using CreateScope.vbs, create scopes called “Johns VM Scope” and “Joes VM Scope”. Reload InitialStore.xml in Authorisation Manager.

Within each of these new VM scopes, I’ll now use Authorisation Manager to create a new role assignment called ‘Administrator’ (not to be confused with the default scope role assignment ‘Administrator’ – AZMan permits role assignments with the same name in different scopes), and link it to the default scope ‘Administrator’ role definition.

Right-click “Role Assignments” under the VM scope and choose New Role Assignment…

In the dialog, select the role definition ‘Administrator’ in the default scope(called ‘Where Defined: Application’ in the UI) by checking it, then hit OK.

The tree view should look something like this:

The next step is to put “John” into the Administrator role assignment in the VM Scope ‘John’s VMs” and to put “Joe” into the Administrators role assignment in the VM Scope ‘Joe’s VMs”. To do this, right-click the newly added role assignment and choose Assign Users and Groups, then From Windows and Active Directory.

After making the necessary changes, your policy store should look like the following:

Important to remember and note is that neither John or Joe are local administrators on the machine. Let’s take a step forward and assume that John and Joe have already created a virtual machine. In the screenshot below, I’m logged on as the local administrator. Remember that built in administrators are administrators in the default scope in the default policy store, and hence can see both virtual machines.

The magic sauce needed to make the separation is to move Joes VM into the scope ‘Joes VM Scope’ and move Johns VM into the scope ‘Johns VM Scope’. Now as much as I write my own scripts for just about everything, there are certain times where it makes no sense to reinvent the wheel. If you download BackupVMsAndScopeScripts.zip and expand the files, there is a script called SetScope.vbs

Run the script:

cscript setscope.vbs “Johns VM” “Johns VM Scope”
and cscript setscope.vbs “Joes VM” “Joes VM Scope”

You’ll get a big spew of output from each command. I’ll leave it an exercise for the reader to modify the script to their needs or develop their own. You want to look at the very last bit of the output which will say “0” if the update succeeded.

That’s it from a VM configuration standpoint, but there are still some nuances which needs resolving before John and Joe can use Hyper-V Manager to get their custom view of only their VMs. As it’s involves several steps, I’ll cover this in part three.

Cheers,
John.

Explaining the Hyper-V authorization model, part one

jhoward — Tue, 01 Sep 2009 05:28:00 GMT

Hyper-V uses a role based authorisation model for access checks. This series of articles takes a look at the model; defines the available primitives; and walks through a couple of examples. (I actually wrote most of this series many months ago – only finally found the time to post it up!).

Quick links: Part1; Part 2; Part 3; Part 4

As the term ‘Role Based Authorisation Model’ implies, Hyper-V has an authorisation layer which performs access checks to grant or deny an account access to operations based on roles the account is a member of. That is not to say everything in Hyper-V has an authorisation protection layer – we also use traditional NT ACL-based security mechanisms. However, this series of articles concentrates just on the authorisation model.

A term I should introduce at this point is “AZMan”. AZMan is, in short, an engine and toolset for making role based access checks and defining policy. AZMan is a component built into Windows. Hyper-V uses AZMan to control role based authorisation.

When you install Hyper-V, the system is configured with a policy store, the policy store being nothing more than a file on disk called ‘InitialStore.xml’. InitialStore.xml contains the most simple of authorisation policies: local administrators are authorised to perform all operations protected by a policy check.

There are two registry keys Hyper-V uses to define attributes about the policy store. They are both under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Virtualization.

StoreLocation points to a file called InitialStore in a hidden directory c:\ProgramData.
ServiceApplication defines which application in the policy store is used.

Before looking at the contents of InitialStore.xml, let’s define some primitives which Hyper-V uses in AZMan.

(Note that AZMan is a very flexible model, and Hyper-V does not use all the primitives available in AZMan. Also these articles do not cover more advanced modeling capabilities where you can, to some extent, build nested models).

Application

Policy stores define the authorisation model for zero or more applications. An application is top-level container which contains all the other primitives used by an application. Examples of applications could be ‘My Financials Application’ or (not by any coincidence!) ‘Hyper-V services’.

Operations

Operations are specific items or actions being guarded by an access check in an application. For example, when a user tells a system to “Create a Virtual Machine”, Hyper-V makes an access check.

Role Definitions

As the name implies, this is the definition of a specific role, such as a Hyper-V administrator, or a Hyper-V Network Administrator, or standard user. It is defined by a name and zero or more operations which are permissible in this role definition. So with the examples I just gave, you could choose to setup the store such that an administrator role definition contains all operations, a network administrator role definition contain the operations for altering, creating or deleting virtual networks, and standard users can only connect and interact with virtual machines.

Role Assignments

Role assignments are where users and groups are placed or “assigned” in the model. A role assignment can be stand alone or linked to one or more role definitions.
A standalone role assignment doesn’t make too much sense, as without any role definition links, it is nothing more than an orphaned grouping of accounts.
When you link a role assignment to a role definition, you are saying that the accounts in the role assignment have would pass access checks for the operations defined in the linked role definition. If you link a role assignment to multiple role definitions, accounts in the role assignment would pass access checks for the superset of operations defined by all the linked role definitions.
Role assignments can be created at multiple levels or “scopes”.

Scopes

Scopes are a more advanced feature in the authorisation model. Scopes can be thought of as the “level” where role definitions, role assignments and other AZMan primitives reside. Each AZMan policy store contains a single top level scope. A good way to think of the top level scope is the place where global policy is defined.

Side note

Internally on the Hyper-V team, this tends to be referred to as the ‘default’ or ‘root’ scope. Whether that is correct or not in AZMan terminology is another question! I believe the correct term is “Application” scope.

You can also create additional “more constrained” scopes, and place virtual machines in them. For the purposes of Hyper-V, it makes sense to think of these as VM specific scopes, or VM Scopes for short. Using VM scopes is a topic I’ll cover in more detail in later parts of this series.

So with knowledge of those primitives, let’s take a look at the out-of-box policy store. To use the management tools for AZMan requires a full installation of Windows Server rather than server core. (Or you can take a copy of the file across to a separate Vista or Windows 7 installation). As the policy store is in a hidden and ACL’d directory, you need to be a local administrator to open the file.

Start azman.msc

Right click on Authorisation Manager in the tree view on the left and select Open Authorisation Store. Navigate, or enter the path, to InitialStore.xml (again, note \ProgramData is a hidden directory – you can type it in though).

Once open, the first thing to notice is that there is a single application defined: ‘Hyper-V services’.

This matches the registry key ‘ServiceApplication’ in the screenshot higher up this article. Next, I’ve expanded out a couple of nodes so that you can see where Role Definitions and Role Assignments fit in to the hierarchy.

(Note the Hyper-V authorisation model does not use Task Definitions or Authorisation Rules, and I won’t be talking about Groups in this series of articles)

You can see that we have a single role definition ‘Administrator’ and a single role assignment ‘Administrator’ defined. First, examine the ‘Administrator’ role definition by right clicking on it, selecting properties and choosing the Definition tab.

This is where we can see which operations are covered by a role definition. There are 33 operations in Hyper-V in Windows Server 2008 and Microsoft Hyper-V Server, and 34 operations in Windows Server 2008 R2 and Microsoft Hyper-V Server R2.

If you select a role assignment, Authorisation Manager displays a list of accounts who are members of that role assignment – the default being the builtin administrators group.

As an aside – if you are walking through this and are using a domain joined machine (the above screenshot is from a workgroup machine), the default accounts listed in the “Administrator” Role Assignment will be domainname\administrators. This is actually a bug (as far as I can tell) in the AZMan console. You can verify this by opening InitialStore.xml in an editor:

You’ll notice that the SID listed is S-1-5-32-544 which is the SID (Security Identifier) of the builtin\administrators group - http://support.microsoft.com/kb/163846 has more information.

So that explains how the default policy in Hyper-V is setup such that local administrators have access to all operations. With an understanding of the primitives, it is trivial to extrapolate how to modify the model to grant other accounts full access to Hyper-V without needing to be local administrators on the Hyper-V machine itself – you simply need to add accounts to the ‘Administrator’ role assignment in the default scope. This is exactly what Ben blogged about in January last year.

In the next part, I’ll take a look at scopes.

Cheers,
John.

HVRemote refresh

jhoward — Sat, 08 Aug 2009 02:21:00 GMT

So after some 22,000 downloads (thank you) in the 8 months since first released, HVRemote has undergone a refresh to make it even easier to configure Hyper-V Remote Management and diagnose issues.

The major change in version 0.7 is the ability to perform some verification of the configuration and provide hints as to what to follow if it detects an error through the use of the new /target option. Below is an example of the new bit of output running hvremote /show /target:servername from a Windows 7 client where everything is working just fine (yes, it is fine for the ping to timeout, that just means it’s blocked by the firewall).

HVRemote 0.7 fully supports Windows Server 2008 R2, Microsoft Hyper-V 2008 R2 and Windows 7. In addition, the home page has undergone a refresh to cover the some of the most commonly asked questions, and the documentation has been brought up to date.

For a list of other changes, please see the documentation.

Cheers,
John.

Linux Integration Services for Hyper-V - Two announcements

jhoward — Tue, 21 Jul 2009 21:46:00 GMT

Yesterday, we announced that the Linux Integration Components for Hyper-V have been released under a GPL v2 license for inclusion in future versions of the Linux kernel. More information on this can be found in the presspass article here.

The second announcement is that today, we released RC2 (Release Candidate 2) of the Linux Integration Services for download. These include support for RHEL (Red Hat Enterprise Linux), versions 5.2 and 5.3, both x86 and x64, plus SLES (SUSE Linux Enterprise Server 11) x86 and x64 .

These provide drivers for Linux running on both v1 (Windows Server 2008 with KB950050 applied, or Windows Server 2008 SP2), and Windows Server 2008 R2 RC (Build 7100). In addition, these can be used on the standalone products Microsoft Hyper-V Server 2008 and it's R2 RC release (Build 7100).

You can obtain the Linux ICs through Microsoft Connect. If you have feedback - please send it to linux_ic@microsoft.com.

At the current time, we support single-processor Linux guest operating systems. Mouse support can be found here. Note that as this is still a release candidate, you should not use them for production workloads.

Cheers,
John.

Hyper-V: How to remove disabled virtual network adapters from the parent partition

jhoward — Thu, 02 Jul 2009 04:01:00 GMT

In May, I mentioned that we introduced a checkbox in the Hyper-V UI for Windows 7 and Windows Server 2008 R2 which determines whether a virtual NIC is created in the parent partition for External Virtual Networks. (To get a better understanding of Hyper-V networking and what this means, take a look at this article.)

Many customers follow our best practice of having at least two physical NICs, one for use by the parent partition (aka Management Operating System), and one or more for use by virtual machines. But using the “v1” UI, there’s no option to not have the parent virtual NIC created. Two common ways to resolve this are to disable the virtual NIC it in “Network Connections” on the control panel, or unbinding all protocols from the virtual NIC. The disabling option tends (in my experience) to be the more common choice of the two.

There are, of course, several scripts out there to create what I termed a “dedicated” network (ie one which is dedicated for use only by virtual machines) last year. Ben has a couple of samples here in both VBScript and PowerShell, and Robert has a sample here. These are better approaches to disabling NICs or removing protocol bindings.

To date, I haven’t come across a script which removes disabled virtual NICs in the parent partition. So here is one such example. This will hopefully assist you in being more “compliant” with our best practice recommendations in an existing Hyper-V deployment.

Obviously with any script which does destructive things, I urge caution and that you make careful note of your configuration before running it, and remember the standard disclaimer on my blog.

//// VirtualSwitchManagementService object.  Logical wrapper class for Switch Management Service//functionVirtualSwitchManagementService(    Server,    User,    Password    ){    //    // Define instance fields.    //        this.m_VirtualizationNamespace  = null;        this.m_VirtualSwitchManagementService = null;             //    // Instance methods    //            VirtualSwitchManagementService.prototype.DeleteInternalEthernetPort =     function(        InternalEthernetPort        )     /*++    Description:        Deletes an internal ethernet port            Arguments:        InternalEthernetPort - Msvm_InternalEthernetPort to delete            Return Value:        SWbemMethod.OutParameters object.    --*/     {        var methodName = "DeleteInternalEthernetPort";         var inParams = this.m_VirtualSwitchManagementService.Methods_(methodName).inParameters.SpawnInstance_();                inParams.InternalEthernetPort = InternalEthernetPort.Path_.Path;                return this.m_VirtualSwitchManagementService.ExecMethod_(methodName, inParams);    }     //    // Utility functions    //        VirtualSwitchManagementService.prototype.WaitForNetworkJob =     function(        OutParams        )     /*++    Description:        WMI calls will exit with some type of return result.  Some will require         a little more processing before they are complete. This handles those         states after a wmi call.    Arguments:        OutParams - the parameters returned by the wmi call.    Return Value:        Status code    --*/     {        if (OutParams.ReturnValue == 4096)        {            var jobStateStarting        = 3;            var jobStateRunning         = 4;            var jobStateCompleted       = 7;                var networkJob;             do            {                WScript.Sleep(1000);                                networkJob = this.m_VirtualizationNamespace.Get(OutParams.Job);             } while ((networkJob.JobState == jobStateStarting) ||                      (networkJob.JobState == jobStateRunning));             if (networkJob.JobState != jobStateCompleted)            {                throw(new Error(networkJob.ErrorCode,                                networkJob.Description + " failed: " + networkJob.ErrorDescription));            }                        return networkJob.ErrorCode;        }         return OutParams.ReturnValue;    }            //    // Aggregate functions    //    VirtualSwitchManagementService.prototype.DeleteInternalEthernetPortAndWait =     function(        InternalEthernetPort        )    /*++    Description:        Deletes an internal ethernet port            Arguments:        InternalEthernetPort - Msvm_InternalEthernetPort to delete            Return Value:        SWbemMethod.OutParameters object.    --*/        {        var outParams = this.DeleteInternalEthernetPort(InternalEthernetPort);         var wmiRetValue = this.WaitForNetworkJob(outParams);         if (wmiRetValue != 0)        {            throw(new Error(wmiRetValue, "DeleteInternalEthernetPortAndWait failed"));        }    }     //    // Constructor code    //        if (Server == null)    {        Server = WScript.CreateObject("WScript.Network").ComputerName;     }        //    // Set Namespace fields    //    var locator = new ActiveXObject("WbemScripting.SWbemLocator");     this.m_VirtualizationNamespace = locator.ConnectServer(Server, "root\\virtualization", User, Password);        //    // Set Msvm_VirtualSwitchManagementService field    //    var physicalComputerSystem =             this.m_VirtualizationNamespace.Get(                    "Msvm_ComputerSystem.CreationClassName='Msvm_ComputerSystem',Name='" + Server + "'");     var list = physicalComputerSystem.Associators_(                        "Msvm_HostedService",                        "Msvm_VirtualSwitchManagementService",                        "Dependent");             this.m_VirtualSwitchManagementService = list.ItemIndex(0)}  //// main//  var wshShell = WScript.CreateObject("WScript.Shell"); var g_NvspWmi   = null;var g_CimV2     = null; Main(); function Main(){    g_NvspWmi   = new VirtualSwitchManagementService();     WScript.Echo("Looking for root\\cimv2...");    var locator = new ActiveXObject("WbemScripting.SWbemLocator");    g_CimV2 = locator.ConnectServer("", "root\\cimv2", "", "");            WScript.Echo("");    WScript.Echo("Looking for internal (parent) virtual nics...");    var list = g_NvspWmi.m_VirtualizationNamespace.ExecQuery("SELECT * FROM Msvm_InternalEthernetPort");    for (i = 0; i < list.Count; i++)    {        var next = list.ItemIndex(i);         // find correpsonding Win32_NetworkAdapter        var adapters = g_CimV2.ExecQuery("SELECT * FROM Win32_NetworkAdapter WHERE GUID='" + next.DeviceID + "'");        for (j = 0; j < adapters.Count; j++)        {            var adapter = adapters.ItemIndex(j);            if (adapter.NetEnabled == false)            {                WScript.echo("Deleting '" + next.ElementName + "' because it is disabled.");                g_NvspWmi.DeleteInternalEthernetPortAndWait(next);            }            else            {                WScript.echo("Not deleting '" + next.ElementName + "' because it is enabled.");            }        }    }     WScript.Echo("");    WScript.Echo("Finished!");}

The script should be saved with a .js extension to run it from the command line. Or you can get it as a text file from here.

One thing I would note is that after running the script, you’ll notice in the “v1” UI when you select an External Virtual Network, the message “This virtual network switch cannot be configured. You might not have permission to perform this task, or it might have been reconfigured in the parent partition” is displayed. This limits your ability to change the network type to an Internal or Private network. However, you can still remove the network if necessary.

Another point to note is that if you are running Hyper-V v1 RTM on Windows Server 2008 SP1, have disabled virtual NICs in the parent partition, then apply Service Pack 2, disabled NICs are re-enabled after applying the service pack. Hence, I would recommend you remove disabled virtual NICs from the parent partition if you have no need for them prior to applying SP2.

And for completeness, if you ever need to completely remove all virtual networks from your system (it crops up as a question every now and then), there’s a useful script you can find here. Obviously though, I recommend extreme caution before running that script.

Cheers,
John.

And again, thanks to Keith for his assistance :)

New in Hyper-V Windows Server 2008 R2 Part 2 – MAC Spoofing

jhoward — Thu, 21 May 2009 21:29:00 GMT

Our Virtual Switch got smarter in Windows Server 2008 R2. In Windows Server 2008, VMs are susceptible to MAC spoofing. MAC spoofing is where a (generally) malicious machine pretends to be another machine on a network (there are legitimate applications which do spoof MAC addresses though – Network Load Balancing being one such example).

A MAC (Media Access Control) address in physical NICs is burnt in, although it can usually be over-ridden. In a virtual machine environment, there’s no physical counterpart, so we have to “make up” our own addresses. In fact, that can sometimes cause other networking issues which I talked about last year.

The virtual switch in Hyper-V is a learning layer 2 switch – in other words, it routes packets based on MAC addresses. Therefore, if a malicious VM starts sending out packets with a MAC address owned by another machine, it causes the switch to re-learn. This in turn can cause DoS (Denial of Service) attacks, and the potential for the malicious virtual machine to see packets which weren’t destined for it. Hence, in our security recommendations, we state that as a security best practice, you should consider (in Hyper-V v1 at least) placing virtual machines of a similar security integrity level on the same virtual switch and not share the switch with virtual machines of a different security integrity level.

In Windows Server 2008 R2, we introduced several changes in the switch to make it smarter. Each virtual switch port has a new property (exposed in our WMI model as AllowMacSpoofing) which is off by default. We also expose this property in the settings page for a virtual machine. Note that to see this setting, you must be using the UI from Windows Server 2008 R2 or RSAT in Windows 7 Client.

When the checkbox is not checked (i.e. the port is in “secure” mode):

The MAC address set in the Virtual NIC settings page (either static or the dynamically assigned on) is the only MAC address a virtual machine can specify for the source MAC address in any packets it sends.
The virtual machine will only receive unicast packets with a destination MAC address matching the address in the virtual NIC settings page, and packets destined for its MAC won’t be flooded to other ports.
As our virtual switch is a learning switch, we maintain various internal structures including a routing table. When the virtual machine starts and we power-on the virtual NIC, we pin the MAC address in the virtual NIC settings page into the routing table to ensure it cannot move to another port. We stop any more learning on that port.
When traffic needs to be flooded by the switch to switch ports, we do not flood traffic to ports running in “secure” mode.
Attempts to override the MAC address inside the virtual machine are ignored.

When the checkbox is ~~not~~ checked (i.e. the port is in “less secure” mode):
(6/15/2009 - fixed typo, removed word "not" above)

The virtual machine can send and receive traffic using any MAC address
The virtual machine receives flooded unicast packets
Learning is enabled on the switch port so that multiple MAC addresses can be learnt on that port. No pre-population of the routing table is performed and MAC addresses for a port are learnt as traffic passes through the switch.
Virtual machines can override their MAC address.

The above applies to virtual NICs used by virtual machines. We treat virtual NICs in the parent partition slightly differently and there is no setting to put that NIC into “secure” or “less secure” mode. The virtual NIC in the parent partition is always pinned in the routing table, but they receive flooded unicast traffic, learning is enabled on the switch port and can send using any MAC address.

Cheers,
John.

And thanks again for Keith Mange for pulling the above information together :)

Using Hyper-V Manager "v1" against Windows Server 2008 R2

jhoward — Thu, 07 May 2009 02:18:00 GMT

I had a couple of emails overnight asking whether it is possible to use Hyper-V Manager "v1" (as in KB952627 for Windows Vista SP1, or part of RSAT in Windows Server 2008) pointing to a machine running Windows Server 2008 R2 RC or Microsoft Hyper-V Server 2008 RC.

The short answer is yes, this works. The slightly longer (and intentionally non-exhaustive answer) is:

Bug fixes in the "v2" UI are not in "v1" UI
You won't have access to new features the "v2" UI exposes
You may see a warning when managing a "dedicated" network

The first two points are somewhat obvious, but it's that last point I wanted to expand a little further on in this post.

If you're not familiar with a "dedicated" network (otherwise known as an External Virtual Network for which the management operating system is not allowed to share the network adapter), take a trip back to my post a couple of days ago. The "v1" UI only knows about External Virtual Networks which have a virtual NIC in the parent partition. When it sees an external switch without the parent virtual NIC, it assumes that manual intervention or scripting has taken place to alter the network in some way. Hence, it blocks you being able to change the network into an Internal or Private network.

Somewhat aside to this (but I only say it as I know I’ll get plenty of email from the diligent readership I have letting me know....), you may notice that when using the v1 UI for managing a dedicated network, the "Enable virtual LAN identification for parent partition checkbox if enabled. Further you can set the VLAN ID, click OK and won't see an error – it will appear to succeed. The operation itself is meaningless as there is no virtual NIC in the parent partition to apply the VLAN ID to - if you subsequently were to re-open Virtual Network Manager using the "v1" UI, you'd note that the change had not been applied. It simply a bug and is fixed in the "v2" UI.

Cheers,
John.

Hyper-V RC Release Download Links

jhoward — Wed, 06 May 2009 05:41:00 GMT

Today, the last of the download links for the Microsoft Hyper-V Server 2008 R2, Windows Server 2008 R2 RC (Release Candidate) release, Windows 7 client and the Remote Server Administration Tools (RSAT) for Windows 7 RC have gone live.

Windows Server 2008 RC Download

If you have an MSDN or Technet subscription, the download has already been live for a few days.

As of today, you can also download directly. Follow this link and choose the "Download the RC now!" link at the top right of the page.

Microsoft Hyper-V Server 2008 RC Download

This is the standalone virtualization solution using the same Hyper-V technology present in Windows Server 2008 R2. It can be downloaded here.

Windows 7 RC Download

Follow this link to the TechNet Evaluation Center.

RSAT RC Download for Windows 7

The RSAT tools are packaged in KB958830 which you can obtain by following this link. Make sure you download the right architecture for your needs. Note that these require Windows 7 Client build 7100 to install successfully and do not install on Windows Vista.

Once you have installed the update, to enable Hyper-V Manager, in the Control Panel, open Programs and Features. From here, choose "Turn Windows features on or off" and navigate down through Remote Server Administration Tools/Role Administration Tools and ensure Hyper-V Tools is selected.

Note that if you have a full installation of Windows Server 2008 RC, the Hyper-V role management tools are available without enabling the Hyper-V role itself.

Cheers,
John.

Hyper-V and in-place upgrade to Windows Server 2008 R2 Release Candidate

jhoward — Wed, 06 May 2009 04:08:00 GMT

A cautionary note for those of you performing an in-place upgrade of a machine running Windows Server 2008 with the Hyper-V role enabled, to Windows Server 2008 R2 Release Candidate.

During the installation, you will see the following compatibility report message stating that you should turn off the Hyper-V role:

This warning is incorrect, and you should not do this as the virtual machines will not be present, and virtual network configuration will be lost once the role is re-enabled.

You will see a similar message if you have virtual machines running at the time of upgrade, but it is a “hard block” (in other words, you cannot proceed further). In the case where you hit the hard block, running VMs should be cleanly shut down prior to upgrade. However, I re-iterate, you should not remove the role itself.

One other point to note is if you have online snapshots or virtual machines in a saved state. Saved states are not compatible between Hyper-V in Windows Server 2008 and Windows Server 2008 R2 RC build, so you should ensure you cleanly shut down VMs and delete online snapshots prior to upgrading to avoid the following message after the upgrade is complete:

Cheers,
John.

New in Hyper-V Windows Server 2008 R2 Part 1 – Dedicated Networks

jhoward — Tue, 05 May 2009 04:43:00 GMT

I thought I’d start a series of posts highlighting some of the smaller changes in Hyper-V in Windows Server 2008 R2. There’ll be plenty of people covering the larger features such as Live Migration, so I figured someone needs to cover the other fun stuff!

Many of the improvements are not visible from an end use perspective – changes such as code cleanup, bug fixes, optimizations for performance and scalability. But many are visible, and this post covers one such change.

I did a post back in June last year covering how networking works in Hyper-V and followed it up with a description of the uses for the different types of networks. That second post left you somewhat dangling, as the “best practice” type of network for virtual machine connectivity is what I called (as there wasn’t an official name back then), a “dedicated” network. This type of network is depicted below. But, there was no way to create such a network in Hyper-V “v1” user interface without scripting.

This type of network has a virtual network switch bound to a physical NIC, but no virtual NIC present in the Parent partition (aka Root partition or “Management Operating System”). In other words, it can only be used by virtual machines, not the parent partition.

Robert did come up with a script to create a dedicated network, but the “v2” UI (present in full installations of Windows Server 2008 R2 and RSAT in Windows 7 client) has a new checkbox to do just this, marked “Allow management operating system to share this network adapter”.

The good news is that using the “v2” UI, you can target both a “v1” and a “v2” server running the Hyper-V role (or Microsoft Hyper-V Server) and this checkbox and functionality is available.

Hence, if you have not so far scripted a way to create a “dedicated” network, or have chosen to simply disable the virtual NIC in the parent partition or even unbound all protocols from that virtual NIC, now’s the time to revisit your configuration.

One thing I should mention is the default when creating a new external virtual network – in particular the (not recommended) case of a single physical NIC machine being remotely managed. The default is that the checkbox is not checked. Hence, you should be sure that if you do not allow the management operating system to share the network adapter, there is an alternate NIC available for management. Obviously in the single physical NIC machine scenario, not checking this box would probably mean a trip to the server room… Hopefully the warning is clear enough!

Cheers,
John.

Hyper-V Security Guide available

jhoward — Wed, 01 Apr 2009 06:19:00 GMT

The Hyper-V Security Guide is now available online or for download as a Word document. It covers hardening, delegation (including using SCVMM), and protection mechanisms for virtual machines.

You can read it online here, or download the Word document(s) here.

It even includes a link to HVRemote :)

Cheers,
John.

Hyper-V KB967902 on Windows Update today

jhoward — Wed, 25 Mar 2009 08:22:00 GMT

Just a quick heads up – as posted on our team blog earlier this month, KB967902 resolves an issue in Hyper-V regarding a certificate expiration issue.

This was released earlier today on Windows Update. A restart will be required to complete the installation.

Cheers,
John.