John Howard - Senior Program Manager in the Hyper-V team at Microsoft : How to Articles

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.

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 :)

Hyper-V Resolving Event ID 4096

jhoward — Sun, 28 Dec 2008 22:25:00 GMT

Over the break I’ve been taking over Christmas, one of my goals was to move the remainder of my Virtual Server “production” VMs across to Hyper-V. But when nearing completion, I noticed that Server Manager was reporting a role error:

Looking at the detail of the event logs, it was Event ID 4096 from Hyper-V-Config saying that The Virtual Machines Configuration {GUID} at ‘{Directory}’ is no longer accessible: The system cannot find the path specified. (0x80070003)

This is a pretty common error many people hit, and in my case it was due to some rearranging of directories and moving virtual machines around until I had it “just right” in terms of how I like to set my own servers up. By personal preference (nothing more), I like to keep the configurations, snapshots and VHDs for my virtual machines under a single directory on a per VM basis – in my case v:\virtual machines. However, when playing earlier with my new server, I’d been using the v:\vms directory (hence the specific error in the screenshot below).

So in Hyper-V Manager, under Hyper-V Settings, I enter V:\Virtual Machines in the text boxes for both Virtual Hard Disks and Virtual Machine Configuration files.

Then, when using the New Virtual Machine wizard, I check “Store the virtual machine in a different location” but keep the default directory set above, and get to the Connect Virtual Hard Disk step, the wizard populates the default directory for a new VHD in a sub-directory under V:\Virtual Machines named the same as the Virtual Machine.

If you examine the directory structure of V:\Virtual Machines\Test after completing the wizard, you end up with this (if you also take a snapshot)

Your VHD is in the main directory, and the configuration and snapshot data-root are under the Virtual Machines and Snapshots subdirectories under “Test” (or whatever you name your virtual machine). In other words, everything for that virtual machine is in a single location which was the primary intent.

Anyway, (as I frequently do in my blog posts), I somewhat digress. Back to the Event ID 4096 which indicated there was a problem with V:\VMs, the original location I was using when moving virtual machines across from Virtual Server.

If you navigate to \ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines on your system drive (note that ProgramData is a hidden directory), you’ll notice that there are a number of symbolic links to configuration files. There are two in the screenshot below (one being highlighted) which points to the V:\VMs\… directory.

So it’s a simple case of very carefully deleting that or those links (just use the “del” command) which refer to the old directory, and cycling the VMMS service (net stop vmms, then, net start vmms). After this, the error will no longer be logged. Please be extremely mindful not to delete links referring to VMs you want to keep! Onwards with the rest of the migration now…

Cheers,
John.

How to detect UAC elevation from VBScript

jhoward — Wed, 19 Nov 2008 23:32:00 GMT

While working on the next version of HVRemote yesterday evening, one of the things I wanted to address based on feedback from various people was to have the tool (written in VBScript) detect whether it is being run from an elevated command prompt. While this is relatively easy to determine using low-level languages from the GetTokenInformation API, this is not callable from VBScript without a helper. I couldn't find a pre-existing COM object in Windows Vista or Windows Server 2008 which indirectly exposed this API, or anything built in to the Windows Scripting Host. As I didn't want to ship HVRemote with a separate helper binary, I had to go digging for an alternate solution.....).

The one thing I didn't want to do was to have the script try to do something active which might (or might not) work, returning some form of permission denied in the failure case. I wanted something passive. I discovered the whoami command displays the System Manadatory Label. So, if you can see where this is heading, although this can be classified as a "glorious hack", it's straight-forward to passively determine elevation through examining the output of whoami /all (or whoami /groups which is a little more terse and still gives the information we need). All you need to know is the SID strings for integrity levels.

I also discovered an interesting thing about the Exec method of the Windows Scripting Host along the way, which certainly bemused me for a while. I drew a blank on it from Internet searching too. It appears that if the command being "Exec"'d has a lot of output (such as whoami /all), unless StdOut is drained, Exec blocks indefinitely. You learn something new every day :)

Here's the sample script - save it as elevated.vbs and run as "cscript elevated.vbs". I've stripped the sample code down to a bare minimum to just demonstrate the logic - you should add the appropriate error handling if you take advantage of it in your own scripts. (Or download here and rename to a .vbs extension)

Dim oShell, oExec, szStdOut

szStdOut = ""

Set oShell = CreateObject("WScript.Shell")

Set oExec = oShell.Exec("whoami /groups")

Do While (oExec.Status = cnWshRunning)

   WScript.Sleep 100

   if not oExec.StdOut.AtEndOfStream then

       szStdOut = szStdOut & oExec.StdOut.ReadAll

   end if

Loop

select case oExec.ExitCode

   case 0

       if not oExec.StdOut.AtEndOfStream then

           szStdOut = szStdOut & oExec.StdOut.ReadAll

       end if

       if instr(szStdOut,"S-1-16-12288") Then

           wscript.echo "Elevated"

       else

           if instr(szStdOut,"S-1-16-8192")  Then

               wscript.echo "Not Elevated"

           else

               wscript.echo "Unknown!"

           end if

       end if

   case else

       if not oExec.StdErr.AtEndOfStream then

           wscript.echo oExec.StdErr.ReadAll

       end if

end select

Hope someone finds this snippet useful, but as always, see my blog disclaimer.

Cheers,
John.

Configure Hyper-V Remote Management in seconds

jhoward — Sat, 15 Nov 2008 03:02:00 GMT

Update 19th Nov - v0.3 now released!

It has been a little quiet on the blog front, but sometimes, at least in this case, I hope I've come up with something worth waiting for. Announcing "HVRemote"...., a tool to "automagically" configure Hyper-V Remote Management. (Amazing what can be done with a few days vacation to kill before you lose them at the end of the year....).

I'm not going into the gory detail here as I've created a PDF containing the documentation, and a site on http://code.msdn.microsoft.com/HVRemote where you can download the tool and the documentation. All I ask, is that if you find the tool useful, drop me an email or a comment. Thanks!

What does the tool do: It reduces the manual configuration steps needed for Hyper-V Remote Management that I blogged about back in March this year 1, 2, 3, 4 and 5 down to one or two commands.

It can configure Full installations and Server Core Installations of Windows Server 2008 with the Hyper-V role enabled, plus configure Microsoft Hyper-V Server. It runs across all locales (I've tested English and Japanese) and it doesn't matter if the server is domain or workgroup joined.
It can configure Vista SP1 and Server 2008 configured with the Hyper-V Remote Management tools. Again, doesn't matter if the client is domain or workgroup joined.

Quick how-to:

1. Server: To give or remove a user access permissions:

hvremote /add:domain\user or
hvremote /remove:domain\user

2. Server & Client: Display current settings (server or client): (Screenshot is client side)

hvremote /show

The other useful options are:

3. Find out all the command line options: hvremote /help or hvremote /?

and a couple of client side options:

4. Client: Add firewall exception for MMC: hvremote /mmc:enable
5. Client: Allow anonymous access to Distributed COM: hvremote /AnonDCOM:grant

I've tried this out with a a lot of test "guinea pigs" internally at Microsoft, and using the script literally dropped their remote configuration time down to seconds. Hopefully it will do the same for you.

But I must also point you to the disclaimer on my blog, the disclaimer in the documentation, and the license conditions at http://code.msdn.microsoft.com/HVRemote before use:

HVRemote and the associated documentation are provided "as-is". You bear the risk of using it. No express warranties, guarantees or conditions are provided. It is not supported or endorsed by Microsoft Corporation and should be used at your own risk.

Cheers,
John.

How to use uniquely identify a virtual machine in Hyper-V

jhoward — Wed, 17 Sep 2008 01:13:30 GMT

When managing a large number of virtual machines, there is often a need to tag it in some way with one or more properties uniquely identifying it for administrative purposes. One example would be to identify a virtual machine as belonging to a person, team or business unit.

The Hyper-V WMI namespace has a number of BIOS properties which can be set when a virtual machine is turned off. As these properties are part of the virtual machine configuration, they are separate from the VHD or backing storage used by the virtual machine. These properties can also be read from within a guest operating system.

To start with, let’s look at the following four properties and the default values they are initialized to when a virtual machine is created:

Property	Default value
BIOSSerialNumber	Randomly generated
BaseBoardSerialNumber	Same value as BIOSSerialNumber
ChassisSerialNumber	Same value as BIOSSerialNumber
ChassisAssetTag	Randomly generated (but different to BIOSSerialNumber

All these properties are numeric and in the format "XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XX".

Windows provides WMI classes that expose these settings inside a guest operating system. The table below shows the relationship between the WMI properties of the virtual machine and WMI properties as seen by a guest operating system.

Property of Msvm_VirtualSystemSettingData	WMI class & property in guest operating system
BIOSSerialNumber	Win32_BIOS.SerialNumber
BaseBoardSerialNumber	Win32_BaseBoard.SerialNumber
ChassisSerialNumber	Win32_SystemEnclosure.SerialNumber
ChassisAssetTag	Win32_SystemEnclosure.SMBIOSAssetTag

To illustrate how these values can be queried, I set the values to something less random and more easily identifiable. Here’s a partial output of a query against Msvm_VirtualSystemSettingData obtained using the wbemtest application on the parent partition. (Ignore the BIOSGUID property for a few moments).

instance of Msvm_VirtualSystemSettingData
{
   BaseBoardSerialNumber = "2222-2222-2222-2222-2222-2222-22";
   BIOSGUID = "{AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE}";
   BIOSSerialNumber = "1111-1111-1111-1111-1111-1111-11";
   ChassisAssetTag = "4444-4444-4444-4444-4444-4444-44";
   ChassisSerialNumber = "3333-3333-3333-3333-3333-3333-33";
};

The next step was to generate something to query the WMI properties inside the guest operating system. I used a bit of scriptomatic assistance to come up with the following bit of VBScript – there’s plenty of other alternatives around of course including wbemtest again, a bit of PowerShell, ...

Const wbemFlagReturnImmediately = &h10

Const wbemFlagForwardOnly = &h20

Set objWMIService = GetObject("winmgmts:\\.\root\CIMV2")

set colBIOS = objWMIService.ExecQuery( _

 "SELECT SerialNumber FROM Win32_BIOS", _

 "WQL", wbemFlagReturnImmediately + wbemFlagForwardOnly)

set colBB = objWMIService.ExecQuery( _

 "SELECT SerialNumber FROM " & _

 "Win32_BaseBoard", _

 "WQL", wbemFlagReturnImmediately + wbemFlagForwardOnly)

Set colSE = objWMIService.ExecQuery( _

 "SELECT SerialNumber,SMBIOSAssetTag " & _

 "FROM Win32_SystemEnclosure", _

 "WQL", wbemFlagReturnImmediately + wbemFlagForwardOnly)

For Each objItem in colBIOS

   WScript.Echo _

     "BIOS:            SerialNumber:   " & _

     objItem.SerialNumber

Next

For Each objItem in colBB

   WScript.Echo _

     "Baseboard:       SerialNumber:   " & _

     objItem.SerialNumber

Next

For Each objItem In colSE

   WScript.Echo _

     "SystemEnclosure: SerialNumber:   " & _

     objItem.SerialNumber

   WScript.Echo _

     "SystemEnclosure: SMBIOSAssetTag: " & _

     objItem.SMBIOSAssetTag

Next

This yielded the following output:

So the last problem I had to solve was the BIOSGUID value which I’d set in the virtual machine configuration to AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE. I use the word “problem” because I couldn’t see where or if this was propagated to the guest operating system in the WMI namespace. Nothing like a good challenge… :)

As searching the WMI namespace drew blank (or to be more accurate I missed it), I turned to some other thoughts. First was a registry search, but that also drew a blank.

I did know that the BIOS GUID is used during PXE boot – here’s a screenshot of the same virtual machine configured with a legacy network adapter for PXE install – you can see the contrived GUID being displayed:

Next call was a utility I found from an Internet Search called ROM BIOS Explorer. Here’s a screenshot of it running inside the guest operating system. As you can see from the hex-dump on the left hand side, starting at the highlight at offset 0x49, you can see the contrived GUID clearly. The utility also indicates it’s in the “Type 1: System Information” structure in the BIOS.

So that means the information is there – it was just a question of how to access it from inside the guest operating system. Next stop was an Internet search for Type 1: System Information which yielded (among others), this document about SMBIOS on Microsoft.com.

This shows that the table contains a Serial Number and UUID (another term for a GUID). So back to the Internet to refine the search to include the term “UUID” which led me to a pretty old SMS document which had exactly what I was looking for: Type 1, System Information UUID is exposed in Win32_ComputerSystemProduct.

Back to scriptomatic to do a query, and it was there all along!

There's also one other useful link I found along the way. To see a sample script on how to modify Msvm_VirtualSystemSettingData please see here.

Cheers,
John.

PS Thanks to my colleague Frank Berreth for pulling much of the information for this post together.

Hyper-V: Why does Hyper-V Manager not always work over VPN connection? Access Denied or RPC server unavailable errors.

jhoward — Fri, 08 Aug 2008 07:55:51 GMT

This post examines a problem several people have reported when running Hyper-V Remote Management tools over a VPN connection - specifically hitting an error “Access denied. Unable to establish communication between ‘SERVER’ and ‘CLIENT’”. In some variations, I’ve seen RPC errors such as “RPC server unavailable. Unable to establish communication between ‘SERVER’ and ‘CLIENT’.”

And an example of an RPC error case:

To be explicit up front, I am talking about this only occurring over a VPN/RAS connection – when connected using a wired or wireless connection without VPN, everything works normally. If things are not working on wired/wireless, follow my series of remote management posts to configure everything first.

Diagnosing the issue took a bit of sleuthing. So let’s dive in. A big clue is in the first message – it implies there is some form of communication between the Hyper-V enabled server and the Remote Management client. Indeed, that is correct – there is a DCOM callback. So let’s start by looking at the IP configuration on the laptop machine I’m using for this walkthrough after the VPN connection has been established.

Note that the DHCP assigned address for the VPN connection is 192.168.200.6, and the DHCP assigned address for the Internet connection is 192.168.1.119.

Let’s run a network trace network trace on the Hyper-V enabled server to see what’s going on. I’m running the network trace while starting Hyper-V Manager on the laptop:

The two highlighted lines show that the Hyper-V enabled server is making an attempt to connect to my local wireless IP address on my broadband connection, 192.168.1.119, rather than the DHCP assigned IP address for my machine on the internal network, 192.168.200.6.

What’s also interesting in the trace are ARP packets from the Hyper-V enabled server at 192.168.200.218 to “HPCRAPTOP”:

Notice that the server is asking where 192.168.200.14 is, and netmon is resolving 192.168.200.14 to the IP address of the laptop. So that indicates all is not well with DNS since we know above that the DHCP assigned address on the VPN connection is 192.168.200.6. Let’s do an nslookup to examine the DNS entry for the laptop.

Indeed, the laptop from a DNS perspective is incorrect and explains why netmon is resolving 192.168.200.14 to my laptop. (Although I didn’t mention it, I happen to know that this DNS entry, 192.168.200.14, was the IP address assigned to the laptop when it was last connected directly to the internal network.)

So as an experiment and first workaround, let’s edit \windows\system32\drivers\etc on the Hyper-V enabled server to add an entry for my laptop as 192.168.200.6, the current IPv4 address for VPN and see what happens.

Yes, that works. But it’s hardly what I could describe as a desirable or every-day-workable solution. If you’re walking through with me, remember to remove that entry hosts to see if there are any other workarounds.

Well there is one interesting workaround which I mentioned in my remote management configuration series. However, I absolutely do NOT recommend this one unless you really need to as you are lowering the security of your machine. Changing this setting is NOT necessary for remote management in a domain environment, but it is in a workgroup environment (my home environment I’m using for this is domain based). Here are the settings to change in dcomcnfg on the management client:

Why this works is related to WMI/DCOM fallback, but I’m far from claiming to be an expert here and will walk swiftly away from any further explanation. However, I re-iterate, I absolutely do not recommend you change this setting unless you need to.
So let’s step back a bit now and try and understand a bit more about the DNS issue. The obvious thing to think may be to run “ipconfig /registerdns” from an elevated command prompt on the remote management machine to correct the DNS registration. Let’s see what happens, while at the same time running a network trace on the ISA server with a filter for just the DNS protocol.

If you’re ahead of the game, you may notice this is a very interesting capture! Maybe not if you’re aware of my home setup, so let me explain why. 192.168.15.2 is the external internet address of my ISA server (in turn connected to a VOIP router). The destination being resolved to a host with name starting ‘ns’ is my ISP’s DNS server. Looking at the frame details, you can see the packet is a DNS update request for the laptop. Unsurprisingly, if you look at the response from the ISP in packet 3949, the response is “NotAuth”. Afterall, they’re not authoritative for DNS of my domain. I am!

This routing to the external network through ISA is normal expected behaviour. So I’m still yet to find a good solution. But all is not lost (of course). Let’s take a different tactic and look a little closer at the Vista SP1 inbox VPN client configuration (as in one which hasn’t been created by what-ever the equivalent of CMAK, or Connection Manager Administration Kit, for Vista – and no, I’ve no idea what the replacement technology is. But it does remind me to do some research for another day....).

I’m assuming you’re already familiar with configuring a PPTP or L2TP VPN connection in Vista – that’s a little outside of the scope of this post. But here’s the IPv4/Properties/Advanced/DNS dialog tab of the VPN connection I’ve created to connect back to my home network. Look at the bottom three items relating to DNS registration:

Hmmmm. These look extremely promising . Logically, it sounds like I want all three: I want to specify a DNS suffix for this connection which is that of my internal domain; Yes, I want to register the connection’s address in DNS; and I’d like to use the DNS suffix in the DNS registration. So I changed it to look like this:

After saving the changes, let’s run that DNS-filtered network trace on the ISA server again while re-establishing the VPN connection:

Looks good as a DNS update was sent to the internal DNS servers, not to the external ISP. It shows the update for the IPv4 address of the remote management client as 192.168.200.4 with a success response in the following packet. And ipconfig on the client?

This confirms the trace above – the remote management client has IP address 192.168.200.4. What about an nslookup of the laptop?

Excellent. Everything is looking rosey – the DHCP assigned IP address of the laptop acquired from the VPN connection is in DNS on the internal servers. Therefore, the Hyper-V enabled server should be able to locate the laptop when making it’s DCOM callback, so let’s fire up Hyper-V manager and see what happens:

Voila! Hope you found that useful.

Cheers,
John.

Hyper-V: Why is networking reset in my VM when I copy a VHD?

jhoward — Wed, 23 Jul 2008 01:36:53 GMT

This is a question I’ve seen come up a few times so figured it was time to examine why in a little more detail. In Virtual Server, you were able to copy VHDs and the associated VMC (Virtual Machine Configuration) file from one host to another, add the VMC to the other host and everything would work. In Hyper-V however, this is not the case due to improvements in our security model.

The supported way of copying a virtual machine from one Hyper-V enabled server to another is to use the export and import functionality in Hyper-V Manager. However, there are few situations I’ve seen where some creative workarounds have been necessary.

Consider the case where you store a VHD on a different physical drive than the VM configuration, and the physical drive holding the configuration gets corrupted or re-imaged for some reason and the original configuration is “lost”. Let’s suppose further that the virtual machine contains some very specific IP configuration settings on one or more network adapters – maybe it’s a router of some kind, for example.

In this scenario, the obvious thing to do is to create a new virtual machine with a similar configuration, add the VHD(s) and start it up. When you log on to the VM, you’ll see that the originally configured IP settings are no longer present. The reason for this is that the “GUID” of the original network adapter was stored in the “lost” configuration. So when a new configuration is created, when a synthetic NIC is added, a new GUID is generated. When the virtual machine starts, plug-and-play see this new NIC, as a completely different NIC, just like as you would in a physical machine.

Of course, you can, in most circumstances (I’m not aware of any Microsoft applications which you can’t do this on) reset the IP configuration, change the application(s) to bind to the new network adapter and all is good. Apart, that is, from that reminder from Windows that another adapter already has that IP address, as shown below.

There's a KB article outlining how to remove those hidden network adapters. (Although targeted for XP, this appears to also work on Windows Server 2008).

So that explains what’s going on. The rest of this article really just digs a tad deeper for a little more insight into how Hyper-V operates under the covers, and see if there’s another way to approach this.

Let’s go back and go through what we’ve done so far:

Created a (Windows Server 2008) virtual machine with a single “synthetic” NIC
Assigned a static IPv4 address of 192.168.200.248.
Deleted the virtual machine using Hyper-V manager (this doesn’t delete the VHD).
Created a new virtual machine using the same VHD and a single “synthetic” NIC.
In Network Connections (ncpa.cpl), you see Local Area Connection n where n does not match what would have been seen in the original VM
For that same “Local Area Connection n” network connection, you’ll see the device name is “Microsoft Virtual Machine Bus Network Adapter #m” where m does not match what you would have seen in the original VM (or may have been missing entirely).

Now perform the steps in the KB article so that we can see the “old” NIC in device manager. From an elevated command prompt:

set devmgr_show_nonpresent_devices=1
start devmgmt.msc
On the menu bar: View/Show hidden devices
Expand the Network adapters node

There are two NICs. Let’s take a closer look at the dimmed adapter (the one highlighted) by selecting properties, switching to the details tab and selecting Hardware Ids from the dropdown. In particular, notice the first line highlighted which is a GUID, in this example, starting f61bbefc-.

This is the VMBus “Channel Offer GUID” for the “old” NIC. Let’s do the same with the currently configured NIC.

Notice that the highlighted GUIDs are different – the new one, in my case, starts 944fafdc. (Another way to retrieve this GUID is to extract it from the registry – a little harder, but absolutely possible.) Now a bit of background information – let’s take a look at the XML configuration file for the current virtual machine. By default, the XML configuration files are stored under \programdata\microsoft\windows\hyper-v\virtual machines. BUT – it’s totally unsupported to edit these files manually, and we entirely reserve the right to change the format at any point in time. There’s no harm though taking a peek at a section of it. Notice the highlighted line (ChannelInstanceGuid) matches 944fafdc….

So you’ve probably now worked it out. We know the old “ChannelInstanceGuid” from the device manager screenshot above, and need to create a VM configuration with that same ChannelInstanceGuid. As I mentioned above, it’s totally unsupported to hand-edit the configuration file, so we have to use an alternate mechanism. We expose this property in our WMI model (http://msdn.microsoft.com/en-us/library/cc136992(VS.85).aspx). Specifically, it’s the first element of the array Msvm_SyntheticEthernetPortSettingData.VirtualSystemIdentifiers[] which needs updating. I’ll leave the actual scripting sample up to someone else – there’s various examples out there on the Internet of how to use the Hyper-V WMI model.

Hope that was of interest.
Cheers,
John.

Hyper-V: MAC Address allocation and apparent network issues MAC collisions can cause

jhoward — Wed, 16 Jul 2008 06:02:00 GMT

In a physical only world, you don’t usually have to worry about MAC addresses that much as each NIC vendor carves off a MAC address from their ranges which have been allocated to them. However, in a virtual environment, you have to be a little more careful, particularly if you are using dynamic MAC address assignment. This post looks at how Hyper-V allocates dynamic MAC addresses and some potential problems you can face. So often it can be the last thing people think to check, but can be the root cause of otherwise unexplained network oddities.

Here’s a screenshot of a typical MAC collision problem – pings sometimes work, sometimes fail – and this is all on a local isolated network.

To start the walkthrough, I have a base install of Windows Server 2008 on a server with a single physical NIC – against best practice, but it serves fine for demonstration. I have already installed the RTM update (KB950050) to the server, but have not yet added the Hyper-V role. Let’s look at an output of “ipconfig /all”. You can see that the MAC address of the physical NIC is 00-13-20-F5-F8-7D and I’m obtaining an IP address from a DHCP server on the private test network I’m using.

Now let’s use Server Manager to enable the Hyper-V role. Note that Server Manager allows you to create an external virtual network switch during role enabling, but I am choosing not to do this. Let’s see what has happened in the registry after the Hyper-V role is enabled. Specifically, I’m looking at two keys which have been created under HKLM\Software\Microsoft\Windows\NT\CurrentVersion\Virtualization, as-yet unpopulated: MinimumMacAddress and MaximumMacAddress, plus another key in the worker node, CurrentMacAddress – again as-yet unpopulated. (The astute walking through this in front of a machine will notice that CurrentMacAddress also appears in the Virtualization node. That key is not used though.)

Next, I’m going to create my first virtual machine. As I haven’t created any virtual network switches yet, I’ll leave the network disconnected. I don’t need a hard disk. Also, I’m deliberately choosing not to start it. Let’s see what’s happened in the registry. MinimumMacAddress and MaximumMacAddress have been populated with 00-15-5d-c8-6a-00 and 00-15-5d-c8-6a-ff respectively – a range of 256 possible MAC addresses.

So where did this range come from? The first three bytes are the Microsoft IEEE Organizationally Unique Identifier, 00-15-5D which we use in Hyper-V. The next two bytes, C8-6A are derived from the lowest two octects of an IPv4 address on the server (the first IP address as NICs are enumerated). If you look at the second screenshot in this post, the IPv4 address on the only NIC on this server was 192.168.200.106. In Hex, this is “C0.A8.C8.6A”. The last two octets or bytes are C8 and 6A. The last byte of the address range is automatically generated with a minimum 00 and maximum FF.

You can probably now realize, that while this algorithm will work for many people, it may not necessarily be perfect and cause MAC address range clashes. To cope with multiple Hyper-V enabled servers, you would need to ensure address ranges are managed at a higher level across those servers, such as the use of SCVMM.

Let’s go back to the virtual machine I created. By default, when a virtual machine is created, it is allocated a dynamic MAC address. This can of course be changed in the settings for the virtual machine. Here’s the setting for the blank virtual machine. Notice that it’s set to Dynamic and the MAC address in the “Static” boxes show 00-00-00-00-00-00

Now I’m going to start the Virtual Machine and open the settings. Although some settings cannot be changed while a virtual machine is running (including changing static/dynamic MAC, or the static MAC itself), notice that the boxes under the static MAC address radio button are now populated with the first MAC address in the range defined in the registry: 00-15-5D-C8-6A-00.

Now for a bit of fun (and to make the walkthrough a bit simpler), let’s change the registry so that the maximum MAC address is 00-15-5D-C8-6A-02. (I’ll also do a reboot just to make sure the change takes effect) This change means that we are limited to three possible dynamically assigned MAC addresses, the last octet being 00 (in use by the “Blank” VM), 01 or 02.

Now, I’m going to create another virtual machine named 6A-01 and power it on, then create a third virtual machine named 6A-02 and power that on too. Let’s look at the settings for each of these while all three virtual machines are running. As expected 6A-01 has a MAC address ending 6A-01 and 6A-02 has a MAC address ending 6A-02. That’s why we have the “CurrentMacAddress” registry key to track what MAC address to assign to VMs in turn.

Can you guess though at this point what would happen though if I create another virtual machine and power it on? I don’t have any MAC addresses left in my available range and all MAC addresses are currently in use.

Did you guess correctly? Let’s now power off the very first virtual machine (“Blank”) I created with MAC address 6A-00, and then try to run through the New Virtual Machine Wizard again with my “No MAC Addresses Available In Range” virtual machine. Try to guess what will happen at the end.

The virtual machine starts successfully and now has a duplicate MAC address to the first virtual machine I created, ‘Blank’:

Last quiz question: What would happen then if I tried to start “Blank” – will it start or not? After all, it has already been allocated a MAC address ending 6A-00.

Actually, we will detect this as you can see above and stop the virtual machine from powering on. So in some ways, on a single Hyper-V enabled server, we’re relatively immune to duplicate MAC addresses across virtual machines running on a single server. However, due to the algorithm for choosing the ranges of MAC addresses, while relatively safe, there is no guarantee of being unique across an entire network. And of course, chances are that you will want packets from or to virtual machines on a Hyper-V server to “hit” the physical network.

So hopefully that gives you a better idea why it is important to manage MAC addresses across multiple servers in a virtual machine environment. While the walkthrough above was specific to Hyper-V, the same types of issues could arise in Virtual Server.

Cheers,
John.

Deploying Windows Vista SP1 with "slipstreamed" Hyper-V RTM. Part 3.

jhoward — Thu, 03 Jul 2008 17:32:00 GMT

The first two parts of this mini-series dealt with deploying Windows Server 2008 – either as the root partition with the RTM Hyper-V role enabled, or as a child partition (virtual machine) with the Hyper-V RTM Integration Services installed. This third part covers an additional step for using the same technique for deploying Windows Vista SP1.

The Windows Vista SP1 Integration Services for Hyper-V RTM are in a different KB and included in vmguest.iso which holds the Integration Services in Hyper-V. Currently, there isn’t a separate download available, but you can extract it really easily if you have a Windows Server 2008 machine up and running with the Hyper-V role enabled. There are a number of tools available to extract from ISOs, but let’s do this a slightly different way by using a virtual machine itself – remember that ISOs can be mounted in virtual machines directly.

Below is a Windows Server 2008 virtual machine with vmguest.iso mounted in its virtual CD/DVD device. (vmguest.iso resides on the parent partition file system under \windows\system32\language). Notice that there are a couple of .MSU packages under \support\amd64 and \support\x86. We need two files for KB950214:

\support\amd64\Windows6.0-KB950214-x64.msu and
\support\x86\Windows6.0-KB950214-x86.msu

I’ve taken a copy of these across to the WDS server to work on. I can use the same process as for the first part in this series to insert the package into a Windows Vista SP1 Business x64 WIM. You’ll probably want to add KB950214 (unpublished) for the Hyper-V RTM Integration Services and KB952627 for the Vista SP1 Hyper-V RTM Management Tools. The latter is available as a separate download from the links below, and is not present on vmguest.iso

Please also take careful note of the warning I put in my first post in this series about the /s: parameter to pkgmgr

Remember to use an elevated Windows PE Tools Command Prompt for the packaging steps and choose the right architecture MSU for the WIM you are updating! Now you just need to make sure that WIM is present in WDS and deploy a virtual machine (or indeed a physical machine).

Cheers,
John.

Hyper-V: Locate Hyper-V enabled servers in your domain

jhoward — Mon, 30 Jun 2008 23:25:00 GMT

It seems an eternity ago (May 2007) that I put up a post describing how to determine which domain-joined servers are running Virtual Server in your domain(s). Well that same functionality is present in Hyper-V, only the SCP or "Service Connection Point" in Active Directory is different - "Microsoft Hyper-V".

Here's a sample VBScript code. Save the contents as "FindServers.vbs" (text file download) and run from an elevated command prompt "cscript FindServers.vbs".

On Error Resume Next

Const SCP = "Microsoft Hyper-V"

' Add as many lines as needed for the domains in your org.

DoQuery "DC=YOURDOMAIN,DC=com", "YOURDOMAIN", SCP

Sub DoQuery(szDomainDN, szDomainShortName, szSCP)

    Set oConnection = CreateObject("ADODB.Connection")

    Set oCommand = CreateObject("ADODB.Command")

    oConnection.Provider = ("ADsDSOObject")

    oConnection.Open "Ads Provider"

    oCommand.ActiveConnection = oConnection

    oCommand.Properties("Page Size") = 99

    oCommand.Properties("Searchscope") = &H2 'ADS_SCOPE_SUBTREE

    oCommand.Properties("Chase Referrals") = &H60

             'ADS_CHASE_REFERRALS_ALWAYS

    oCommand.CommandText = _

       "select distinguishedName from 'LDAP://" & _

       szDomainDN & "' " & _

       "where objectCategory='serviceConnectionPoint' " & _

       "and cn='" & szSCP & "'"

    Set oRecordSet = oCommand.Execute

    If Err Then

       wscript.echo _

           "ERROR: Unable to find Domain Rooted at: " & _

            szDomainDN

       exit sub

    End If

    If Not oRecordSet.EOF Then

       wscript.echo szDomainShortName & ":" & _

                    oRecordSet.RecordCount

       ' If you want to enumerate the machine names,

       ' uncomment this block of code

       'oRecordSet.MoveFirst

       'Do Until oRecordSet.EOF

       '    szNodeName = _

       '      oRecordSet.Fields("distinguishedName")

       '    'Trim "CN=<szSCP>,CN="

       '    szNodeName = _

       '      mid(szNodeName, InStr(szNodeName,",CN=")+4)

       '    'Trim the domain DN

       '    szNodeName = _

       '      Left(szNodeName,InStr(szNodeName,",")-1)

       '    wscript.echo szNodeName

       '    oRecordSet.MoveNext

       'Loop

    else

       wscript.echo szDomainShortName & ": 0"

    end if

    set oRecordSet = Nothing

    set oCommand = Nothing

    oConnection.Close

    set oConnection = Nothing

End Sub

To use the script, edit the call right at the top to "DoQuery", inserting the appropriate domain for your organisation. Add multiple lines if you have multiple domains. If you want a list of machine names, uncomment the code-block starting "oRecordSet.MoveFirst" and ending "Loop"

So I'm sure you're wondering, how many servers are actively running at Microsoft? With a bit of additional work using the script as the starting point, a simple database and some Excel macro wizardry, I happen to have been tracking the stats internally for some time now. While I can't share the scale, exact numbers and date-ranges for the graph below, you get an idea of the overall trend over a "few" months. (Don't worry about why there's two lines - the blue line is the important one). What I can say is that the current number is in the thousands. Many, many, thousands.

Cheers
John.