John Howard - Senior Program Manager in the Hyper-V team at Microsoft : Information

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 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.

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.

Virtualization launch day

jhoward — Mon, 08 Sep 2008 23:30:00 GMT

Today is (was) Virtualization Launch day. Although the keynote presentations were streamed live (in fact I'm just watching Bob Muglia finish up as I'm typing this), they will be available later this afternoon for on-demand viewing here.

Some of the highlights:

Microsoft Hyper-V Server is coming within the next 30 days and will be free
System Center Virtual Machine Manager 2008 (SCVMM) is coming within the next 30 days.
Live migration will be in the next release of Hyper-V in Windows Server 2008 codename "R2"

Microsoft Hyper-V Server
There's more information on Microsoft Hyper-V Server here as first announced back at TechEd last year. It will be available for free. Microsoft Hyper-V Server contains the same fundamental technology present in the Hyper-V role in Windows Server 2008, but Hyper-V is the only capability of Microsoft Hyper-V Server. It must be managed remotely. You may have noticed if you've watched the streaming media, the screenshot showed a command-line configuration utility - this is a simple way of configuring the server for things such as IP configuration, computer name, enabling remote desktop etc. More on that to follow soon.

System Center Virtual Machine Manager 2008
There's more information on SCVMM here. The main announcement today was that SCVMM 2008 will be available within 30 days. The demonstration showed SCVMM managing Virtual Server 2005 R2 SP1; Windows Server 2008 with Hyper-V; Microsoft Hyper-V Server and VMWare ESX 3.5.

Live Migration
This was the first time we've made any announcements about the feature set in Windows Server 2008 codename "R2". Live migration is the ability to move a running virtual machine from one physical server to another with little or no perceptible downtime from an end user perspective - today's keynote showed a video being played while the virtual machine on which Windows Media Player was running was "live-migrated". Although there are many more improvements in the next release that we've been working on for many months now, there will be a fuller disclosure at the PDC conference at the end of October this year, and also at WinHEC in November.

Cheers,
John.

Hyper-V: Eight useful links and tidbits for 08-08-08

jhoward — Fri, 08 Aug 2008 21:45:00 GMT

I've had a few links I've been meaning to post up for some time now, so here's a small collection of eight of them on the 8th of the 8th, 08...

WMI/Development using Hyper-V

The WMI SDK for Hyper-V has recently been updated with code samples in C# and VBScript
Want some WMI samples in Powershell? Try James's library on CodePlex

Clustering

A hotfix for increased functionality in Hyper-V Clustering
Official Step-by-Step Guide for setup and testing Hyper-V Failover clustering:
A couple of nice blog walkthroughs for setting up clustering from Robert & Jose

Assorted other stuff

Hotfix for running Network Load Balancing (NLB) in a virtual machine
Adding synthetic driver support to WinPE

Cheers,
John.

Do I have the latest BIOS installed? (And a cheap laptop repair)

jhoward — Sun, 03 Aug 2008 21:45:12 GMT

For Hyper-V to operate correctly, it is strongly advised, and in many cases, required, to install the latest BIOS onto your hardware for hardware virtualization features to operate correctly.

While some OEMs provide fantastic information, my experience is that all too often, you get frustratingly minimal information about BIOS updates:

A release date
A version number
Verbiage like “This improves stuff”. (Thanks. Really helpful!)

What they don’t generally tell you is what you really wanted to know:

Do I need it?
What will it mend or break?
How do I tell whether I already have this version?

While most folks would need psychic powers to answer the first of those two, this off-topic post focuses on the last question.

Why is this relevant? As it happens, I was rummaging through drawers a couple of days back as we're moving offices at work, and stumbled across a very old laptop of mine. I figured it was worth trying to revive – it had a few problems with overheating and a noisy fan which was why it had been ignored for so long. I stripped it down (there’s frighteningly useful information on the Internet for this), removed the CPU cooler and found the fan blades had been scraping the casing (in fact, it had worn a groove in the metal).

The choice was around $70+ for a replacement, or a bit of packing material and a clean with the Hoover. That was a really tough decision when the laptop is worth little more than $70 and was already on its way out to pasture. So a bit of thermal grease before re-installing the cooler and reassembly to see whether things had improved. (Amazingly, without a single screw left over! Way ahead of my track record or expectations.)

Sure, the laptop ran. In fact, I’m typing this post on it now. The fan was much quieter due to not scraping any more, but it was still permanently running, even when idle. It was still was on the noisy side, but that’s cheap mechanics for you. Next stop then was the BIOS, the whole point of this post.

Off to the Internet to find a new BIOS was released a year or so back. I knew that this laptop hadn’t been turned on in way over a year, so it was out of date for sure. But how would most users would know what version of the BIOS they currently have? I came up with four ways – I’m sure there’s plenty more.

1) msinfo32

2) The registry

3) Query WMI either through a script, scriptomatic, or a built in tool called wbemtest. Hit connect and select root\cimv2. Hit the query button and enter “select *from win32_bios” and apply. Double click the returned result and hit “Show MOF”

4) Reboot the machine, and examine the BIOS splash screen (some computers), or enter BIOS setup and it will be in there somewhere usually.

(Which then got me sidetracked and I found one computer which didn’t tell me anywhere what version was installed. But fair enough, I think the way to update it is to rip out an EPROM and shove it in a burner. A sticker told me the version instead though. Classic computing!).

But back to the plot… Alas, on the laptop, the BIOS updater didn’t run under Vista. Uuuuurgh.

Problem solved with a separate disk and a temporary XP installation, but why on earth this particular OEM requires a separately downloaded program be installed to flash the BIOS, I’ll never know…

And did the BIOS update fix the fan running permanently? Sadly, not that I could notice except when first turned on. But the CPU temperature at idle was around 3 degrees cooler, so the new thermal paste probably helped. But as always, it was “fun” finding these things out …. Now to get rid of Java JRE 7 on it. Uuuuurgh (again).

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.

Hyper-V: RTM available on Windows Update

jhoward — Wed, 09 Jul 2008 16:37:00 GMT

Just a quick note to mention that Hyper-V RTM (KB950050) was made available on Windows Update yesterday.

See here for more information on the RTM release. Note that the Vista SP1 management tools are not currently available through Windows Update and need to be upgraded seperately.

It's a "recommended" update.

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.