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.

1. 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).
   
2. 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.
   
3. 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.

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. 

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 :

Ever wonder what a Microsoft ship party looks like?

If you take a stroll through Microsoft’s Redmond campus on Google Street View, you’ll get to see one.  On the day that Google decided to drive through campus, we were celebrating the RTM of Hyper-V.  It was a beautiful summer day, and we were out on the sports fields enjoying it.

In fact, you can even see me (highlighted in a yellow halo of awesomeness):

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.

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.

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.

1. Sysprep and Hyper-V
2. Unattended Installation of Windows and Hyper-V
3. Integrated Installation and The Beauty of the Win6 Servicing Stack