Back in 2006, I posted an article about how to get Glass running in a VM. 
The trick was to use Remote Desktop on a Glass-enabled machine to TS into a VM which is running the same OS.  If the build of the OS on your workstation is different than the one in the VM, Glass won’t work.

With the release of the Windows Virtual PC for Windows 7 Release Candidate, this subject has come up again in a post from the RedmondPie.com folks.  They noticed that if you enable the Integration Services in a Windows 7 VM, you’ll get Aero Glass!

This may be news, but it’s actually the same ol’ story.  The reason that enabling Integration Services gives you Aero Glass is because it uses Remote Desktop technology to show you the video from the Virtual Machine.  That also helps to explain why installing Vista (or a build of 7 that is different than the one on the host) doesn’t give you Glass.

Now, you might be asking yourself why – if this is true – do you not get Glass in Hyper-V while using VMConnect?  After all, VMConnect uses Remote Desktop technology to show you the VM Video, too. 

To explain this, I asked Ben Armstrong what was going on, just to make sure that I understood it correctly (for the record, I didn’t).  Ben thought deeply for a second, and knew that the best way to explain this to me was to draw pretty pictures on my whiteboard.  I’ve tried to reproduce them below¹:

Windows Virtual PC	Hyper-V

¹Please note that these images are not necessarily technically accurate – their only purpose is to help demonstrate concepts relevant to the conversation.

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.

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.

In the RC0 release of Hyper-V, you may recall, you had to use the same QFE to Windows Server 2008 host and guest machines to get the Integration Component versions matching.

In RTM, you simply need to choose the Insert Integration Services Setup Disk option from the Action menu in VMConnect, just like you do for Windows XP, Windows Server 2003, and Windows Vista.

However, after you get the ICs working and you connect up to Windows Update, the Hyper-V QFE for Windows Server 2008 (KB950050) is still listed.  That little logical paradox causes you to check which QFEs are actually installed on your system, and you find that KB950050 isn't in that list.

What sort of crazy voodoo magic is this?

Well, according to Occam's Razor, the simplest answer is typically the correct one.

The simplest answer in this case is that Windows isn't lying - KB950050 isn't installed.  For RTM (actually, this happened in RC1), we added another QFE to the mix so that the standard way of installing the ICs (the VMGuest.ISO, which is what gets inserted into the VM's DVD-ROM drive when you click Insert Integration Services Setup Disk) worked for Windows Server 2008.

Since the RTM update actually contains an updated VMGuest.ISO file, it would be impossible for us to put the RTM update in the ISO (it's a classic "chicken-and-egg" problem). 

So, we added another QFE that just contains the Integration Components and nothing else to make life easier for all of you.  You can still apply KB950050 if you want to.  In fact, you can just apply KB950050 if that's your thing.  Or, if you want to be totally up to date, you can apply both of them.

Ok, now I'm really going to the ship party.  Honest.