Andy Dawson's Blog

Building a Hyper-V virtual machine from scratch almost always seems to involve mounting an ISO image at some point during the installation process. I suspect that like us, many other organisations already have a network location in which we store ISO images. The ability to mount an ISO image from our usual network location saves us having to copy the ISO images to the local Hyper-V servers.

The ability to remote mount an ISO image requires that a couple of configuration changes are made. Attempting to remote mount an ISO image without making the configuration changes usually results in an err along the lines of

Inserting the disk failed

Failed to add device ‘Microsoft Virtual CD/DVD Disk’

The file ‘\\RemoteServer\Share\ISO_Image.iso’ does not have the required security settings. Error: ‘General access denied error’

There are two configuration changes that need to be made. The first is ensuring that the Hyper-V hosts can access the share itself that contains the ISO images. As a workaround, you can always grant ‘Everyone’ read access to the share. If you want to control access to individual servers, you need to specify the Active Directory computer object for each server you want to give access to.

The second configuration change that is required to to grant Constrained Delegation on the virtual host objects in Active Directory:

• Log onto a domain controller and open Active Directory Users and Computers from the Administrative Tools menu, or open the remote administration Active Directory tools from another server or client
• Locate the Hyper-V host computer object
• Right-click the object and Select Properties from the context menu
• Select the Delegation tab
• Select the ‘Trust this computer for delegation to specified services only’ radio button and then the ‘Use any authentication protocol’ radio button
• Click the ‘Add’ button:
  
• The ‘Add Services’ dialog will open:
  
• Click the ‘Users or Computers’ button and add the remote server hosting the ISO images. Click OK
• Select the ‘cifs’ service type from the list shown:
  
• Click OK to close the dialog, the computer object properties should look like the following:
  
• Click OK to apply the change
• Repeat the above steps for any other Hyper-V hosts servers.

You should now be able to remote mount ISO images from the server specified.

Those of you who know me or Rik will know that we’re both very keen on Windows Home Server. I’ve seen some time related issues with my Home Server recently, with message in the event log telling me that the time of the system (which seems to drift more than I’d like) could not be updated due to a variety of issues.

Running a manual resync of the server time (open a command prompt and type w32tm /resync) gave the following error:

Sending resync command to local computer
The computer did not resync because the required time change was too big.

I was a little confused by this, as the drift was only a minute or so from what the other PCs in the house were showing. Checking the time synchronisation configuration on the server (open a command prompt and type w32tm /query /configuration) didn’t show any particular surprises except that the MaxNegPhaseCorrection and MaxPosPhaseCorrection were both set to 3600 (one hour) rather than the more normal 54000 (15 hours), however checking the time zone of the machine did; the server was configured to use PST! I could have sworn that I’d updated the time zone when I built the server, but obviously not…

Changing the time zone of the server sorted out the correct time, however running a synchronisation from the command prompt still gave an error:

Sending resync command to local computer
The computer did not resync because no time data was available.

There are a number of other switches that can be used with the w32tm command, one of which is /rediscover, which redetects the network configuration and rediscovers network sources. With the addition of this flag to the command (w32tm /resync /rediscover) gave me a successful time synchronisation:

Sending resync command to local computer
The command completed successfully.

My Home Server is now running on the correct time!

We’ve recently seen an issue running Windows Server 2008 R2 with the Hyper-V role installed on an Acer 6593G laptop. We’d updated the BIOS to the latest version available from the Acer site (1.16 at the time of writing) and Server 2008 R2 would no longer boot once the Hyper-V role was installed.

Rolling back the BIOS to the 1.11 version solved the problem.

We’ve also tested the 1.09 version, which seems to work okay, but have yet to try the 1.13 version which is also available. I’ll update this post when we’ve tried the 1.13 version.

To add domain users to a local machine group using Group Policy, we need to use the Restricted Groups feature.  For the example shown below, I’ll be using a Windows Server 2003 domain functional level.

1. Create a new global/universal security group in Active Directory to contain the users which you wish to add to the local group on the target machines.
2. Make the domain users you wish to add to the local group on the target machines members of this new group.
3. Open Group Policy Editor and navigate to the OU where the target machines reside.  For example, if we have a ‘Desktops’ OU which contains the machines to which we wish to add the domain users, that is the location of the group policy we need to edit or create.
4. If a Group Policy already exists for the OU selected, edit the Group Policy.  If there is no Group Policy for the OU selected, create a new group policy and then edit it.
5. Within the Group Policy, navigate to Computer Configuration –> Policies –> Windows Settings –> Security Settings –> Restricted Groups
6. Right-click on either Restricted Groups in the left pane of the Group Policy Management Editor, or in the right pane, and select Add Group.
7. The ‘Add Group’ window appears:
   
8. Click the ‘Browse’ button to open the ‘Select Groups’ window and select the group created in step 1, above, then click OK.  Click OK on the Add group window.
9. The Properties window for the Restricted Group appears:
   
10. The Properties Window has two membership areas; ‘Members of this group’ and ‘This group is a member of’.  Adding users to the ‘Members of this group’ option would add domain users to the Active Directory group created in step 1, and would remove any members of that group already there. As we added the required users to the group created in step 2, we shouldn’t need to use this option. Adding group names to the ‘This group is a member of’ option adds the security group and its members to the group(s) specified.
11. Click Add next to the ‘This group is a member of’ option and enter the names of the local groups you wish to have the domain users added to (e.g. Administrators, Users, Performance Monitor Users etc.) and click OK.
12. To test that the above steps have worked, log onto one of the target machines, run ‘gpupdate’ from a command prompt and check the local groups specified above for the new members.

One of the issues I’ve seen during our migration of virtual machines to our new Windows Server 2008 R2 Hyper-V cluster relates to network load balancing (NLB).  We have a number of NLB setups running which will need migrating in time.  My first test migration of a pair of NLB virtual machines (actually, technically a trio of servers making up a SharePoint farm) didn’t go as smoothly as I’d hoped.

The machines in question have been running on a Windows Server 2008 Hyper-V machine quite happily for some time.  I followed the procedure we’ve used to migrate other machines to our new Windows Server 2008 R2 Hyper-V cluster, connecting both network adaptors to the appropriate network when the import had completed.  When I looked at the network settings in the GUI, two network adaptors showed up and the configuration at first glance seemed okay.  When looking at the network configuration using ipconfig however, only the values for one network adaptor (the primary, i.e. non-NLB, adaptor) were shown, with the NLB adaptor missing in action.

In addition, NLB manager showed the following error when I tried to reconfigure the cluster:

The solution to the issue is actually simple; in the Hyper-V VM settings for the NLB network adaptor, turn on MAC address spoofing:

This immediately fixed the issues we were seeing with the NLB adaptor of the machines we were migrating.

At Black Marble, we’re in the process of migrating some of our virtual machines to a Windows Server 2008 R2 Hyper-V cluster.  The process of migrating machines from a single Hyper-V host to a Hyper-V cluster is not quite as straightforward as migration of a machine from one single host to another.  In addition, our migrations are made slightly more interesting as our Hyper-V cluster is built on Server 2008 R2 Core machines, so no GUI interface on those machines to help us!

Due to our cluster being Server 2008 R2 Core machines, we do all of our administration remotely.  Once the cluster is built, we rarely spend much time directly connected to the cluster machines.  Most of the administration for virtual machines is done from the Failover Cluster Manager on another server we use as an application server.  While the Failover Cluster Manager allows us to create new virtual guests directly from the interface, there is no apparent way to import virtual machines that already exist onto the cluster directly from the interface.

Importing pre-existing virtual guests onto the cluster therefore becomes a two stage process; firstly import the machine using Hyper-V Manager, then make them highly available.

To import the virtual machine, the following steps need to be taken:

1. On the Hyper-V host running the machine you wish to migrate, export the virtual guest.  In the case of a few of our machines, they were built using differencing disks and we took the decision to merge the disks so we didn’t have base disk stacks littered all over the place.  As our virtual machines were hosted on Windows Server 2008 Hyper-V, this meant that we had to delete any snapshots we had as well and then switch off the machines and allow the background disk merge required in these circumstances to finish before we could merge the differencing disk stack we’d created.
2. Once the export had completed, copy the resultant files to an appropriate location on the CSV disk on the new Windows Server 2008 R2 Hyper-V cluster.  The use of a CSV location is required to allow us to make the virtual guest highly available later.
3. Using Hyper-V manager connected to the specific virtual host in the new cluster the migrated machine should run on initially, import the virtual machine.  Note that with Hyper-V R2, you can choose to duplicate the files so that the virtual machine can be imported again should you need to.
4. Once the virtual machine has been imported, you’ll need to check the settings and may need to connect the network adaptor(s) to the appropriate virtual network(s).  Note that the required virtual networks need to be created individually on each of the Hyper-V cluster nodes.

At this point, you have a virtual guest that has been migrated to its new host, but has not been made highly available.  To achieve this, the following steps need to be taken:

1. Connect to the Windows Server 2008 R2 Hyper-V cluster using Failover Cluster Manager.
2. Right-click on the ‘Services and applications’ header in the left pane of the Cluster Manager and select ‘Configure a Service or Application…’
3. A new window, the High Availability Wizard, will open. Click next on the first page, then select ‘Virtual Machine’ from the list of available service and application types on the next screen and click next
   
4. The imported virtual machines that have not been made highly available will be presented as a list with checkboxes beside them. Select the virtual machines you wish to make highly available and click next
   
5. Click next on the confirmation screen and wait until the wizard completes. Click finish on the summary page, unless you wish to vie the more detailed report (if for example an issues were encountered during the HA wizard).

Your migrated, highly available virtual machines should now be available via the Failover Cluster Manager.  You may wish to modify the properties of the migrated high availability virtual machines to set items such as preferred owner and failover/failback settings before starting them.