Virtual Varia : Hyper-V RTM

Does restoring a snapshot break domain connectivity? Here’s why.

mikekol — Wed, 18 Mar 2009 23:55:09 GMT

This is a pretty common question on our internal mailing lists, and I’d imagine that it’s common outside of Microsoft as well, so I thought it would make a nice blog post (since I’m way behind on blogging…).

So, you have a VM that’s joined to a domain and working perfectly. You take a snapshot so you can restore to this magical point of workingness at any time, and life is good.

One day, you need to fire up this VM and test something, so you revert to your snapshot and start the VM. That’s when you’re told that the domain doesn’t trust your (virtual) workstation anymore. What the heck just happened? No changes were made to the snapshot! That’s why it’s called a snapshot! Why did this break?

Well, you’re right. No changes were made to snapshot, and that’s part of the problem.

It’s part of the default Active Directory domain policies for a domain member to change the password for it’s account every now and then. You’ve no doubt had to change the password for your User Account occasionally, so this shouldn’t be a surprise. What may be a surprise is that the same thing happens for Computer Accounts. That’s right – computers have accounts, too.

Every now and then (by default, it’s 30 days, but the value is configurable via domain policy), the workstation will negotiate a new password with the domain. It all happens behind the scenes, so you’d never know it. It just works.

Unless you, you know, have a domain-joined VM with snapshots.

The problem comes about because the workstation – at some point – negotiated a new password with the domain and recorded it for future use. Then the snapshot was applied, and you turned your VM into a time traveler. This VM from the past was brought into the future, and has no knowledge of anything that happened in the interim. So, it thinks that it’s old password is still good. And it tries to use that password. And the domain says “um, no”.

Well that’s stupid. Why does Hyper-V let this happen?

It’s not just Hyper-V. Many years ago, in my previous life as a network admin, this happened all the time to my VMWare images. The same thing will happen in any situation where you convince Windows that the computer account password is something that it’s not (like restoring a snapshot or any other kind of backup).

Fine. What can I do about this?

There are three possibilities that I’m aware of. If anyone has any other suggestions, please feel free to leave them in the comments.

If you can, change the default domain policy, or get an exception created for your computer account(s).
This is not the best option because it opens up a security hole (small as it may be).
Log into a local administrator account on the system and leave the domain. Then rejoin it. The computer account will get updated with a new password that your workstation knows. Alternately, you could use NETDOM.EXE to reset the computer account password.
You could even automate this if you need to.
Sysprep the VM and create an unattend file that will configure it to your liking, and that will automatically join the domain for you. Once the machine is sysprep’d, make a snapshot and restore to that one from now on.

Hope that helps.

Announcing the Windows® Image to Virtual Hard Disk Converter (WIM2VHD)

mikekol — Fri, 06 Feb 2009 23:29:00 GMT

It was my New Years Resolution that I’d do an average of 2 blog posts per week this year. So far, I haven’t been doing a very good job of that, but I think I have a good excuse. I’ve been very busy with preparing to release a new tool, and now, I can finally announce it.

Fine citizens of the Virtualization Nation: I present to you the Windows® Image to Virtual Hard Disk Converter, or WIM2VHD as I like to call it.

WIM2VHD is a tool that will create a bootable VHD from a specified Windows 7 or 2008 R2 WIM image (like the INSTALL.WIM file that ships on the installation DVDs) without having to run Windows Setup. That means that you can a Windows 7 or Windows Server 2008 R2 virtual machine up and running much, much faster.

You can use these VHDs in Virtual PC, Virtual Server, Hyper-V, and … some other things, too. We’ll talk more about that later.

You can get WIM2VHD here.
(The release candidate has been released, too...)

I’ve done my best at creating some good documentation for WIM2VHD, which is available from the link above. Please make sure that you read the docs. If you have any questions, feel free to start a discussion thread at the WIM2VHD site.

Here’s a video I made introducing WIM2VHD, and showing it in action. More are one the way.

Please be aware, however, that while the underlying process of creating the VHDs is supported by Microsoft, WIM2VHD is not.

Share this post :

How to use VMConnect to create an .RDP-like shortcut directly to your VMs

mikekol — Wed, 03 Dec 2008 00:42:50 GMT

The Remote Desktop application in Windows has a nifty little feature where you can save all of your custom settings for a specific remote computer to a single .RDP file, and then just use that .RDP file as a shortcut to connect to that remote computer instantly.

VMConnect, which is the name of the application that you use to connect to the console session of a Hyper-V Virtual Machine, doesn’t have that option.

Curses! What is an administrator to do!?!

Well, if your VM is running Windows, you could always Remote Desktop directly into the guest OS, but that won’t connect you directly to the console (i.e. you won’t be able to watch the VM boot).

But there’s a better way. VMConnect allows you to specify the name of the Hyper-V server and the name of the VM you want to connect to on the command line.

So, let’s say that you have a Hyper-V Server called “MyHost” and a VM called “My Guest” that you want to connect to quickly. All you need to do is create a shortcut that points to VMConnect.exe with the following syntax:

Remember to use quotes around the VM name if it contains spaces! Also, if the VM exists on the same machine as the one you’re creating the shortcut on, you can use the name “localhost” for the server.

Click Next, name the shortcut whatever you want, and you’re good to go.

Problems with QueryPerformanceCounter on Windows Server 2003 Multi-Processor Hyper-V guests? Here’s why.

mikekol — Thu, 16 Oct 2008 02:03:00 GMT

A friend of mine from another group came to me with a problem he’s been having on some Windows Server 2003 guests.

They’re doing some nifty stuff with the .NET Stopwatch() class, and some WPF animations, which uses the QueryPerformanceCounter Win32 API to figure out the timing during the animations. Apparently, when they run their code in Hyper-V, the animations look sort of… not good.

They’re using Windows Server 2003 SP2 x86, which has been allocated two virtual processors.

It turns out that our performance guru, Tony Voellm, has already encountered something like this. From Tony’s blog post:

The root issue comes about from the Win32 QueryPerformanceCounter function. By default it uses a time source called the TSC. This is a CPU time source that essentially counts CPU cycles. The TSC for each (virtual) processor can be different so there is no guarantee that reading TSC on one processor has anything to do with reading TSC on another processor. This means back to back reads of TSC on different VP's can actually go backwards. Hyper-V guarantees that TSC will not go backwards on a single VP.

The fix for this is to modify the guest’s BOOT.INI file by adding the /USEPMTIMER switch to your operating system’s boot entry. This tells the system to use a different timer for QueryPerformanceCounter-related tasks, and should alleviate the problem.

Update: It looks like some people are seeing this as an error in their event logs. The event number is 1054, and the event source is UserEnv. This is the same problem with the same solution, it's just a different way of showing up.

-mk

Hyper-V Installation Tricks: Updates

mikekol — Sat, 16 Aug 2008 02:04:40 GMT

I haven’t updated my three part series about different ways to install Hyper-V for our RTM release. I’ve been working on getting some step-by-step videos created, but it’s always been on the back burner, and I was waiting to update the posts until I had the videos ready.

Well, a discussion on an internal DL yesterday lit a fire under me, so now I’m going to sit down and do this. The videos aren’t done yet, but I’ll add them when they are.

Since not much of the original content has changed, I’m just going to update the original posts with the new bits. I’ll add some more descriptions about why I’m doing what I’m doing, and where I got certain things.

Hopefully, this will make the series more useful.

Hyper-V Installation Tricks - Part 3: Integrated Installation and The Beauty of the Win6 Servicing Stack

mikekol — Fri, 28 Mar 2008 03:18:00 GMT

Updated for Hyper-V RTM

Thus far we covered the steps necessary to capture a system image with Hyper-V installed, and how to install Windows and Hyper-V at the same time without dealing with system images at all.

Let's take a step back and talk about system images again. Images are a great way to deploy a customized version of Windows to many different workstations or servers without having to go through the effort of configuring each system independently of each other.

Even if you're just setting Windows Vista or Windows Server 2008 up from a DVD, you're still using an image to do the installation. If you look on the DVD in the \sources folder, you'll find a file called install.wim. WIM stands for Windows IMage, and it's an actual image of a real Windows installation that Setup applies directly to your hard drive (and then manipulates a bit, but that's a different story).

You can also make your own WIM files using the imagex.exe tool that ships with the Windows AIK, which I'll link to again.

The cool thing about WIMs (and there are actually many, but I'm just going to stick with the one that's relevant to this post) is that - using imagex.exe - you can mount a WIM as a folder on your Win6 (that's Vista and Server 2008)-based system and copy files to or from it, then save your changes.

So what does this have to do with Hyper-V installation?

Well, hang on... there's more that we need to talk about.

With Windows Vista and Windows Server 2008, some really cool work was done to make the operating systems more servicable. I'm not really in a position to go into all the details, but one of the absolute coolest side effects was the ability to service a Windows installation without actually booting it, which is called Offline Servicing.

No, really... what does this have to do with Hyper-V installation?

Hyper-V RTM ships as a hotfix, which means that you can use the Offline Servicing features of the servicing stack to integrate it with any Windows Server 2008 image that you've got. (This includes the retail media, as well as any image that you made yourself. For best results, you should only use images that have been sysprep'd, or are otherwise generalized.)

Assuming you're using WIMs, here's how to do it.

(Robert Larson has posted a great step-by-step article that even has pictures, if that’s more your thing. Check it out over here.)

Download the Hyper-V RTM hotfix (it could actually be any hotfix packaged into an MSU)
Copy the WIM file you want to integrate this fix into to a place where you have read/write access. I usually create a folder in the root of the drive called C:\image. If you’re copying files from a DVD, remember to remove the Read-Only attribute from the WIM file, either by right-clicking on it in Explorer, choosing Properties, and un-ticking the Read Only box, or issuing the command attrib c:\image\install.wim –r.
Extract the CAB file from the MSU you just downloaded, just like we talked about in Part 2. There's also a KB article that describes the process.
Open an elevated AIK Tools Command Prompt (because you've installed the AIK, right?).
Create a folder to use as a mount point for your WIM (I typically use C:\mnt).
Did you know that WIM files can contain more than one image? In fact, the INSTALL.WIM file on standard Windows Server 2008 media contains six different images! You can see all of the images in a WIM file by running imagex /info c:\image\install.wim. For starters, let’s work on image number 1.
Run:
imagex /mountrw C:\image\install.wim 1 C:\mnt
Run:
start /w pkgmgr /ip /m:c:\extract\Windows6.0-KB950050-x64.cab /o:c:\mnt;c:\mnt\windows /s:%temp%
Check the return code by running:
echo %errorlevel%

If it's anything but 0, there was a failure while applying the update.
Run:
imagex /unmount /commit c:\mnt
If you have multiple images in your WIM that you want to patch, repeat this process – starting at step 7, and changing the “1” to whatever image number you want to patch – for each image in the WIM.

And there you have it. The next time you apply that image, your Windows installation will have the Hyper-V RTM bits already present in the package store. That's different than having the role enabled, though. You'll still need to enable it (which can be automated using parts of the unattend fragments provided in Part 2), but when you do, you'll have RTM from the beginning).

Hyper-V Installation Tricks - Part 2: Unattended Installation of Windows and Hyper-V

mikekol — Wed, 26 Mar 2008 09:33:00 GMT

Updated for Hyper-V RTM

Picture it: Sicily, 1914. You've got a bunch of Servers that you need to install and configure Windows Server 2008 and Hyper-V on. You don't feel like messing around with Sysprep. What do you do?

Well, since none of these things existed in 1914, you're probably pretty safe, but that doesn't really help anyone right now, does it?

What you need, is a way to do an unattended installation of Windows and Hyper-V so you don't have to sit there the whole time and type commands when the system is ready for you. Lucky for you, we've already thought of that.

Before you begin, I strongly recommend that you download the Windows AIK for Windows Server 2008 and Windows Vista SP1. The AIK contains tools and documentation specifically for helping administrators just like you to roll-out Windows on a large scale. With the AIK, you'll get a nifty little tool that will help you build unattended installation files (formerly called sysprep.inf, now called unattend.xml). You can download it here.

Assumptions

For the purposes of this post, I'm going to assume that you already have an unattend.xml file you plan on using to answer questions at install-time. In the body of this post, I'll only be providing XML fragments for you to drop into your answer file as necessary. But, just to make sure that everyone gets the information they way, I'll attach a complete and working answer file (except for the product key, of course), which you can find at the bottom of this post. (Use that file at your own risk - it repartitions your hard drive, so don't use it unless you understand everything it does!)
You're dealing with enabling the Hyper-V role on x64 servers, and you want to apply the RTM patch.
You're going to be using a USB key with your Windows installation media to do the unattended installation. You could just as easily create a custom install DVD with the unattend file and the RTM QFE on it. It's up to you, but I'm just going to stick with the steps for a USB key.

The Steps

Download the Hyper-V RTM patch. (We're assuming you're doing this on the server, so we're working with x64 packages only.) It's over on the Microsoft Download Center, which is right over here. Download the MSU, and save it to your local machine.
Create a working directory on your local machine. I prefer to call mine C:\extract.
From an elevated command prompt, run the following command:
expand -F:* Windows6.0-KB950050-x64.msu C:\extract
Look in C:\extract and you’ll see an assortment of files. There are only two files that you need to care about. First, take a look at Windows6.0-KB950050-x64.xml in your favorite text editor.

Look at the <package /> element. We’re going to use this in a minute, so you may want to copy it to your clipboard.
The next file to find is Windows6.0-KB950050-x64.cab. This file contains the actual hotfix. Copy it to the root of your USB key.
Open up your unattend.xml file and add one of the following fragments right after the <unattend /> element, but before any of the <settings /> elements.

You’ll notice that in the fragments below, we’ve used the <package /> section that we copied out of the XML file in step 4. The only change we made was to the <source /> element’s location attribute, so we can make sure that Windows Setup will know where to find the hotfix.


<servicing>
    <package
        action="configure">
        <assemblyIdentity
            name="Microsoft-Windows-Foundation-Package"
            version="6.0.6001.18000"
            processorArchitecture="amd64"
            publicKeyToken="31bf3856ad364e35"
            language="" />
        <selection
            name="Microsoft-Hyper-V"
            state="true" />
        <selection
            name="Microsoft-Hyper-V-Management-Clients"
            state="true" />
    </package>
    <package
        action="install">
        <assemblyIdentity
            name="Package_for_KB950050"
            version="6.0.1.9"
            processorArchitecture="amd64"
            publicKeyToken="31bf3856ad364e35"
            language="neutral" />
        <source
            location="E:\Windows6.0-KB949219-x64.cab" />
    </package>
</servicing>

-or-

<servicing>
    <package
        action="configure">
        <assemblyIdentity
            name="Microsoft-Windows-ServerCore-Package"
            version="6.0.6001.18000"
            processorArchitecture="amd64"
            publicKeyToken="31bf3856ad364e35"
            language="" />
        <selection
            name="Microsoft-Hyper-V"
            state="true" />
    </package>
    <package
        action="install">
        <assemblyIdentity
            name="Package_for_KB950050"
            version="6.0.1.9"
            processorArchitecture="amd64"
            publicKeyToken="31bf3856ad364e35"
            language="neutral" />
        <source
            location="E:\Windows6.0-KB949219-x64.cab" />
    </package>
</servicing>
Save the unattend.xml file to your USB key as "autounattend.xml".
Go test it out. Pop a Windows installation DVD into one of your servers and plug in the USB Key that you copied all of your unattend files to. If you had the unattend file answer all of the questions during setup, the installation should just start without you having to do anything.
Once you're at the desktop of your new Windows installation, go check in the Programs applet in the Control Panel. If you look at installed updates, you should see KB950050- the Hyper-V RTM QFE.

Hyper-V Installation Tricks - Part 1: Sysprep and Hyper-V

mikekol — Wed, 26 Mar 2008 09:31:35 GMT

Updated for Hyper-V RTM

Before we jump right into this, I thought it would be best if we got a few things straight. For the remainder of this post, everytime I say "sysprep," I'm referring to running Sysprep with the /generalize switch. This is the best way to make sure that the Windows installation image that you capture and apply to other systems actually works when you put it on those other systems.

For more details on what Sysprep with and without the /generalize switch does, I encourage you to read the documentation, which I have conveniently provided a hyperlink to.

So, you're planning to sysprep a Windows Server 2008 box with Hyper-V installed? Good choice. I'm sure you'll be happy with the result, but there are few things that you'll have to do to make sure Hyper-V functions properly after you apply the image to a different computer.

The purpose of sysprep is to make the system as generic as possible so that any image taken of a sysprep'd system can then be applied to different hardware. Syspreping the system will destroy any super-specific information - like hardware IDs. The next time that Windows installation boots up, all of the information is regenerated.

With Hyper-V, however, you'll need to do a little bit of work after the system boots back up for the first time.

First, the hypervisor will not be running, since the BCD (Boot Configuration Data) store has been generalized. You'll need to run the following command to put the hypervisor launch directive back in the BCD store:

bcdedit /set hypervisorlaunchtype auto

Secondly, any virtual network switch that was set for external connectivity will revert to an internal-only switch. This is because the physical NIC that the external switch was bound to doesn't technically exist after a sysprep. You'll need to rebind the switch to a physical NIC if you want external connectivity again.

Thirdly, any disks that you have set to pass-thru (whether hard disks or CD/DVD ROM drives) will need to be set up again (this is also because of the hardware IDs).

If you have to do this on a lot of systems, I recommend that you take a look at our WMI API documentation and figure out how to do this programmatically, and then add commands to your unattend.xml file that run those scripts after the first boot on the new hardware.

I'll talk more about this in a future post.

Hyper-V Installation Tricks - Prologue

mikekol — Wed, 26 Mar 2008 09:28:00 GMT

Updated for Hyper-V RTM

As you may have heard, we've shipped Hyper-V. Sorry for the lack of posts - it seems like I'm always on vacation when we ship a major release like this, so my posts lag a few days behind.

Installing Hyper-V isn't exactly a difficult task, but if you have to do it on multiple machines, installing Windows, installing Hyper-V and then applying the RTM patch can be a bit time consuming. The purpose of this series of posts is to offer a few different ways to help you speed up your Hyper-V deployments.

Here are the major topics I'm planning to post about:

If you've got any other suggestions for topics, please let me know.