Virtual Varia

Sometimes things are just too automated–a cautionary tale

Mike Kolitz — Tue, 03 Aug 2010 23:55:03 GMT

It’s been a very long time since I’ve written anything on this blog, as the very observant of you are likely to notice. I’ve been involved in some pretty amazing projects here in Windows, and I haven’t had much time for anything other than those projects – which I hope to be able to talk about very soon.

However, my lack of blogging isn’t the focus of this post.

I’m writing this post on my newly rebuilt system, with a fresh, new copy of Windows installed to tell you why I’m writing this post on my newly rebuilt system with a fresh, new copy of Windows installed.

Those of you who have read some of my Hyper-V Setup-related articles in the past probably recall that I’m very fond of the Windows Automated Installation Kit (WAIK for short) for all things deployment. It’s filled with tools and documentation which are absolutely priceless (literally… they’re free…) if you’re doing any sort of Windows deployment, whether on physical machines or in VMs.

As I said in my very first post on this blog, I’m a former Microsoft MVP for Windows Setup and Deployment, so I’ve become addicted to automating Windows Setup. It’s what I do. For every machine I own, at home or in my office, I have an unattend file created that will put a brand new copy of Windows on it, and configure it exactly how I want; and the only thing I have to do is put in a USB stick.

And that’s where the trouble started. Some of you can see where this is going, I think.

Earlier this morning, I created a new VHD with WIM2VHD and configured it for native boot because I needed to test some things in that particular OS. After closing my programs, I clicked restart and started reading some e-mail on my laptop while my system rebooted into the new OS. I was half-way through an e-mail when, out of the corner of my eye, I noticed something odd on my monitor. I noticed Windows Setup was running. From the very start – not from the “detecting your hardware” phase.

Dumbly, I sat and started at the monitor for a minute. The caffeine from the tea I was drinking had not yet reached my brain, and although thinking was hard, I managed to force a bit of internal dialog:

“Why in the world is it showing me that screen?” A few seconds passed.
”I shouldn’t be seeing this. Is this a bug?” A few more seconds passed. Windows Setup began expanding files, and the word “USB” floated through my mind, searching for something to connect with.
”Yeah, I should probably file a bug on this. This shouldn’t happen unless I …”

My eyes widened as my brain finally compensated for a complete lack of caffeine, and began madly pumping gratuitous amounts of information.

I had left one of my bootable USB sticks plugged in. And that USB stick contained an autounattend.xml file. And that autounattend.xml file contained a section instructing Windows Setup to wipe my disk and set up new partitions. I’m not entirely sure why I did what I did next. I lunged towards my computer, ripped the USB key from the socket, and threw it across the room. Perhaps on some primal level my brain reasoned that I should put as much distance between the thing I wanted to protect and the thing that was hurting it.

Unfortunately, that didn’t help too much, though I did find a Bluetooth adapter that I’d lost a few months ago when I went to retrieve the USB stick. The Bluetooth adapter was not as comforting as you might think.

And so it came to be – I was bitten by my own drive for the perfect non-interactive Setup automation. I wanted to share this story with everyone because this really is the sort of thing that just happens sometimes (that’s what I keep telling myself, anyway). Automating common processes is great, and everyone should do it if they can. But sometimes, it comes back to bite you. Just be careful. That’s all I’m saying.

Oh, and I now have a new rule.

From this day forth, autounattend.xml files will live on a different USB stick than the bootable Setup media. Hopefully I’ll remember to unplug one of them, at least

Aero Glass? In my Virtual Machine? Now it’s even more likely than you think…

Mike Kolitz — Thu, 18 Mar 2010 18:44:06 GMT

Starting back in 2006, I wrote a post about how to enable Aero Glass support for Virtual Machines by using Remote Desktop / Terminal Services. Last August, I wrote another post describing how Windows Virtual PC for Windows 7 is able to make Aero Glass happen in a Virtual Machine (hint – also Remote Desktop). So what more could I possibly have to say on the subject?

Well, remember when Microsoft bought Calista Technologies back in 2008? Today, we’ve finally announced the results of that purchase: RemoteFX, an amazing set of technologies for enabling VDI (Virtual Desktop Infrastructure) with Hyper-V.

RemoteFX is an enhancement to the Remote Desktop Protocols that enhance the end-user experience in a VM, providing “full-fidelity video with 100% coverage for all media types and highly-synchronized audio, rich media support including Silverlight and 3D graphics, and of course, Windows Aero [support].”

Check out Max’s post for more information, or watch the videos from Microsoft’s Desktop Virtualization Hour.

Using a lot of PowerShell in your presentations?

Mike Kolitz — Thu, 11 Mar 2010 19:55:11 GMT

Do you hate switching back and forth between your PowerPoint slides and a PowerShell window every time you want to demo something?

Apparently, so did Capt. Recursion… er… I mean John Robbins of Wintellect. That’s why he created PowerShellPoint – a slideshow framework for PowerShell.

I’ve got a PowerShell-heavy presentation coming up, and I’m definitely going to use this.

Thanks for sharing, John!

New Physical to Virtual (P2V) tool from Sysinternals

Mike Kolitz — Thu, 08 Oct 2009 02:34:29 GMT

Looks like Mark Russinovich and Bryce Cogswell are up to their old tricks again, with an awesome new tool called Disk2VHD.

From the web site:

Disk2vhd is a utility that creates VHD (Virtual Hard Disk - Microsoft’s Virtual Machine disk format) versions of physical disks for use in Microsoft Virtual PC or Microsoft Hyper-V virtual machines (VMs). The difference between Disk2vhd and other physical-to-virtual tools is that you can run Disk2vhd on a system that’s online. Disk2vhd uses Windows’ Volume Snapshot capability, introduced in Windows XP, to create consistent point-in-time snapshots of the volumes you want to include in a conversion. You can even have Disk2vhd create the VHDs on local volumes, even ones being converted (though performance is better when the VHD is on a disk different than ones being converted).

Disk2VHD can run on Windows XP SP2 and higher, as well as Windows Server 2003 and higher.

Awesome work, Mark and Bryce!

Windows 7/2k8R2 hanging on the boot-up screen in a Hyper-V VM? Here’s why.

Mike Kolitz — Thu, 24 Sep 2009 18:07:04 GMT

I’ve seen quite a few posts about this problem lately - both in public, and on internal Microsoft mailing lists - so I thought it might be best to write up a quick blog about it.

This is one of those cool little problems that you can debug with almost no information, so you’ll look like a genius (or a witch, I suppose…) when you come up with the solution.

So, here’s the problem: A user tries to boot up a Win7 or Win2k8R2 VHD (or even sometimes a Win2k8 VHD) in Hyper-V, the VM just sits there at the boot up screen forever, refusing to boot to the desktop.

Now, that may not sound like a lot of information – and it’s not – but that’s almost everything you need to diagnose and fix the issue. There’s one more piece of information that you’ll need, and luckily, you’ll usually get it. Almost every time I’ve seen someone ask a question about this issue, they have included a screenshot of VMConnect showing the VM doing nothing.

You might laugh at that – I mean, it’s not often that a screenshot of “nothing happening” will give you all of the information you need to solve a problem, right? In this case, though, it does.

Here’s a sample screenshot that I took:

It’s too small to see at this size, so I’ll zoom in on the important part – the upper-left corner:

See it yet? If not, channel Dr. House and think about what you’re seeing… Those icons look kind of… unfinished – don’t they?

Good catch. Those are the icons from the beta release of Hyper-V, which means that the parent partition was never upgraded to RTM.

Here are the icons from the RTM and R2 release:

The fix?

Update the parent partition with KB950050, or with SP2. Keep in mind, though, that you’ll need to re-create all of your VM configurations (you can keep the VHDs around – just attach them to the new VM) after you apply the update, and you’ll lose any save-states or snapshots.

Fine. I’ll do the Twitter thing.

Mike Kolitz — Thu, 13 Aug 2009 04:31:05 GMT

I have to admit, I really don’t quite get Twitter.

My first experience with it probably wasn’t the best one.

It was with Twinkle on my iPhone, which – if you don’t know – will not only show you the people you’re following, but will also show you tweets from people who are around you. I live in downtown Seattle – the tweets I was seeing weren’t exactly what I would call… “interesting.” It was like a Seinfeld episode, but with younger people and more swearing - lots of teenagers with lots to say, but with nothing to talk about. :)

But, I’m willing to give this whole Twitter thing a shot, in the context of a work-related experiment. I’m not good at blogging very frequently, as you may have noticed. I usually have something to say, but not something substantial enough to warrant a whole blog post. Maybe Twitter’s “Micro-blogging” concept is the right thing for me to do. We’ll see, I guess.

So, if you’re up for experimenting with me:

(Thanks to Thoburn Design & Illustration for the free Twitter icons!)

All work and no play makes Mikey … ‘SPLODE!!!

Mike Kolitz — Thu, 13 Aug 2009 03:14:54 GMT

I’m between video games right now, so I thought that I’d take a look at what’s available in the Xbox Live Arcade. There was one game that caught my eye, simply because of the name. As you may have guessed from the title of this post, that game is ‘Splosion Man.

Ladies and gentlemen – let me be clear: If you have not yet played this game, stop doing whatever you’re doing and go play the demo. All the way through. I’ll wait.

Done yet? Ok, now buy the game and play the rest of it. Seriously.

This is one of the best games I’ve played in the last 5 years – and I’m completely serious about that. For me, this game is right up there with Portal, with the wonderfully odd plot and the amazingly quirky music.

What a fantastic game!

Aero Glass? In my Virtual Machine? It’s more likely than you think…

Mike Kolitz — Thu, 13 Aug 2009 02:37:05 GMT

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*

In the illustrations above, you can see that the architecture is somewhat similar between Windows Virtual PC and Hyper-V (with respect to video, anyway). In both cases, an application that uses the RDP ActiveX control (MSTSCAX.DLL), like VMWindow.exe or VMConnect.exe, for video remoting hooks into a process which hosts the RDP encoder. If no integration components are installed in the guest OS, video is handled by our emulated S3 video adapter, which gets passed back through to VMWindow or VMConnect.

If integration components are installed and enabled, there’s a different option.

In Hyper-V, the RDP encoder talks to the Video Virtual Device (VDEV), which communicates with the child partition via a communications bus called VMBus, allowing it to talk directly to the synthetic video adapter (SynthVid VSC) that is running in the child partition. SynthVid then sends frame buffers back across VMBus, back to the Video VDEV, where it’s picked up by the RDP encoder, finally making the video show up in VMConnect.

In Windows Virtual PC, the RDP encoder makes a connection to an RDP endpoint inside the guest OS via a communications bus called VPCBus. In this specific scenario, VPCBus is essentially acting as a network transport, allowing an RDP connection to be made from the host OS to the guest OS without the use of a network (which is why this works even if you don’t have a network adapter in your guest OS). Now, you don’t have an RDP connection to the guest all the time – when the guest boots there’s obviously no RDP endpoint to connect to. At that point, you’re using emulated video. As soon as the integration components come online and are successfully enabled, Windows Virtual PC creates a Remote Desktop connection to the guest OS, and seamlessly switches over to using that for video.

And that’s the secret sauce behind getting Glass in Windows Virtual PC and not in Hyper-V: Hyper-V transmits frame buffers which are then rendered into video by the RDP encoder, while Windows Virtual PC actually creates a Remote Desktop connection, which can use all of the pixie dust necessary for Aero remoting to work.

So why doesn’t Hyper-V do this too?

That’s a topic for another blog post.

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

Microsoft releases Hyper-V Integration Component drivers for Linux as Open Source

Mike Kolitz — Mon, 20 Jul 2009 21:07:59 GMT

:: Yawn :: No big news here. Microsoft just released the Hyper-V Integration Component drivers for Linux. As Open Source. Under the GPL v2.

Yup. Just another standard, run of the mill… wait, what?

No, seriously. It’s true. This is the first time that Microsoft has contributed code to the Linux kernel.

Check out the post on the Virtualization blog over here, or go straight to the press release here.

Please keep in mind, though, that the only Linux distributions that we *support* are SLES 10 SP2, SLES 11, RHEL 5.2 and RHEL 5.3. That doesn’t mean that these drivers only work on those platforms, just that you can only get support for them if you’re running those distributions.

(And yes – I’m working on another podcast. I’ve been very, very busy lately so I don’t have a lot of spare time to work with. Stay tuned.)

Another week, another complete lack of podcast

Mike Kolitz — Sat, 30 May 2009 01:48:14 GMT

I just wanted to post a quick note to all of you that I haven’t given up on the podcasts or anything like that.

I’ve been extraordinarily busy over the last few weeks – and the next few weeks are going to be just as busy. As such, I haven’t had time to record any new podcasts, and I’m not sure when I’ll be able to get another one out.

I think, if I have a free afternoon one of these days, I’ll record something quick and forego the editing that I normally do. It might be pretty rough, but at least I’ll get something out for you to (hopefully) enjoy.

Thanks!