The downside to that uniformity is that the VM can’t access any kind of hardware on your real PC that is beyond what VirtualPC already knows about.  Sure, you can install device drivers in the VM, but those device drivers won’t be able to find their hardware because it doesn’t exist in the virtual machine.

For example, how do you plug a USB flash drive into your virtual machine?  Or how do you use your SmartCard reader to perform a secure login from your virtual machine?  You can’t.  At least, not using the VirtualPC terminal.

I stumbled into this sand trap when I was setting up a new VM and needed to pull source files from version control onto the VM.  The version control server (TFS) is on the private corporate network, but I’m not.  I normally access corpnet via a Virtual Private Network (VPN), which requires use of a SecureCard (encryption keys stored on your corporate photo ID badge) to log in.

One solution would be to pull the sources to my local hard disk across the VPN, then share those files using a network share so that the VM can see them. That would work if the VM only needed read-only access to the files, but since I would also be making changes to the source files inside the VM and from my local machine at the same time (multiple irons in the fire), sharing one copy of the source code wouldn’t work.

I could copy the source tree from the local drive into the VM’s local drive, but that just makes it harder to check in changes made to the files in the VM.

The ideal would be to configure the VM to connect to corpnet via VPN and pull the sources directly from version control.  Changes made to the sources in the VM could be checked in and managed independently of the source files on my local machine. But the VPN client requires access to the SmartCard reader to complete the VPN login, and the VM doesn’t have access to the SmartCard reader hardware.

Or does it?  Turns out, there is a way to do it.  Instead of using the VirtualPC terminal, use Remote Desktop to connect to the virtual machine.

Remote Desktop’s terminal window supports transporting certain kinds of device information from your local machine to the remote machine.  This allows you to print from an app on the remote machine and have it print on your local printer, for example, or access files on a USB drive plugged into the local machine.  The Remote Desktop client also supports sharing SmartCard reader access across the Remote Desktop connection.

Here’s how to set it up:

First you need to configure your VM to accept Remote Desktop connections.  Fire up the VM in the VirtualPC terminal, click on Start in the Windows task bar, right-click on My Computer, click on Advanced System Settings, and select the Remote tab.  Under Remote Desktop, select one of the two Allow settings depending on your needs, then click on Select Users and use the next dialog to add user accounts that can access that machine remotely.  Accounts with administrator privileges automatically have remote access once Remote Desktop access is allowed.

Make sure your virtual machine is set up for network access.  If the VM isn’t on the network, you can’t connect to it with Remote Desktop.  If you can open a browser in your VM and browse web sites, you’re good to go.

Make sure your virtual machine has a computer name.  You’ll be connecting to it by name (IP address also works, but less friendly), so make sure you know what its name is.  You can find (and change) the computer name on the My Computer properties page.  Make sure it is different from your local computer name.

Minimize the VirtualPC terminal window on your local desktop.  Launch Remote Desktop and type in the virtual machine’s computer name.  Click on Options to configure Remote Desktop.

Local device sharing is turned off by default in Remote Desktop. Click on the Local Resources tab, then on the More button near the bottom of the dialog:

This will bring up the Local Devices and Resources selection dialog where you can select which local drives and devices to make available to the remote machine:

Check the Smart Cards checkbox to enable sharing your local SmartCard reader with the remote machine, then close the dialogs and click Connect on the original Remote Desktop dialog.

You should be prompted to log into the remote machine (log in with a user name and password on the virtual machine, not the local machine) and voila – you’re looking at your virtual machine through Remote Desktop’s eyes!

From here I can fire up my VPN client, connect the VM to corpnet using the SmartCard reader, and access the TFS server to manage source files in the VM directly.

Remote Desktop can share local printers, local disk drives and drive letter mapped network shares, serial ports, and SecureCard readers to the remote machine. It can also share some types of Plug N Play media devices such as digital cameras (to access image files on the camera via USB perhaps).  USB devices that don’t behave as a file device or as a printer probably won’t be shareable across the Remote Desktop connection. A USB webcam, for example, cannot be shared across a Remote Desktop connection.

Remote Desktop is by far my preferred client for working with VirtualPC VMs.  RD’s mouse, keyboard, and clipboard integration between the remote and local desktop is more seamless than the VirtualPC terminal and RD just feels snappier overall.

Share/Bookmark

I get Hyper-V set up on the dev machine so I can create and destroy virtual machine configurations with impunity while developing and testing on beta stuff.  I create a new VM in Hyper-V, allocate some RAM and HD to it, and tell it to boot off the network so I can install a stock Vista configuration from corpnet (corpnet does have some pretty cool services now and then).  It boots up, and I can see in the little thumbnail that something is alive in there.

I need to open that VM in a console so I can drive it.  Connect to Virtual Machine…  bzzt!  Nope.  Unknown error.  Try again a different way.  Bzzt!  Nope.

Hmm.  Time to read the beta release notes.  Sure enough, there’s a one-liner in the readme:  Hyper-V does not support connecting to a virtual machine within the context of a Terminal Services (aka Remote Desktop) session.  Nuts.  Understandable, but not much help to me.

How to work around this?  Hyper-V was built with server management in mind, so perhaps the management piece could be installed on my Vista laptop and remotely connect to the virtual machine on the dev machine?  Bingo!  I busily install the Hyper-V tools on my Vista machine, fire up the app, and tell it to connect to the dev machine.

Bzzt!  “Not authorized.”

Uh-oh.  That’s not good, because for me anyway it’s never a short path to resolve authorization issues.

A quick web search later, I discover with delight that John Howard has already covered this remote management of Hyper-V in exquisite detail, for several different machine and network configurations:  client and server in a workgroup network, client and core server, client and server in a domain network, and a domain client connecting to a workgroup server.  Fabulous info, with detailed steps on how to solve this situation.

Naturally, none of those scenarios match my situation.  I have a workgroup client trying to connect to a domain-bound remote Hyper-V server.

I know exactly what the problem is.  Hyper-V uses the current user on the client machine as the login credentials on the server machine. (This may be because my login on the laptop has administrator rights, but I’m not willing to give that up to run this vm thing)  The problem is that my non-domain laptop login id will never be accepted by the domain-bound remote machine.

Or will it?

Most of John’s 4 scenarios are the same steps but with minor variations in where to apply what.  John’s scenario #5, domain client to workgroup server, contains a key step that provided an Aha! moment for me in solving my scenario.  John shows how to use the Win32 cmdkey utility to define a user id and password to use when making service API calls to a particular remote machine.  That’s what I needed to get my domain-bound remote dev machine to accept Hyper-V management API calls from my non-domain local machine.

Here are the steps I used to get this working:

1. Create a user account on the domain-bound Hyper-V server.  This user account should be a local user to that server, not a domain user.  It does not need administrator rights, and it does not need to match your login id on your local machine.  For illustration purposes, let’s call it “hyperdan” on “devmachine”.Note that John’s example creates a new user group so that rights can be assigned to the group (and all its members) rather than for each user one at a time.  Since this is my dev machine and I don’t anticipate ever needing to give anyone else Hyper-V admin rights on this machine, I skipped the group creation step.
2. Enable Firewall WMI rules on server.  Same as John’s step 2 in his Part 5 post.
3. Allow authenticated DCOM access on server.  Same as John’s step 3, using the “hyperdan” id created above.
4. Allow authenticated users access to remote WMI namespace on server. Same as John’s step 4, except that I used the user id directly instead of giving the rights to a user group that the user id is a member of.
5. Configure AZMan on server. Same as John’s step 5, except I used the user id directly instead of the user group.
6. Reboot Server.  Don’t skip this step.
7. Create a firewall exception for MMC on client.  Same as John’s step 6.
8. Allow annonymous callbacks on client. Same as John’s step 7.
9. Set credentials for the remote server (on client). Same as John’s step 8, using “devmachine\hyperdan” as the remote machine and user id.
10. Run Hyper-V Manager on client. Same as John’s step 9.

If all you want to do is connect to a particular VM on the server, use vmconnect.exe in the Hyper-V program directory on the local machine.  Enter devmachine for the machine name.  Click on the Virtual Machine dropdown and wait a second or two for it to populate.  Select the VM you want and away you go!

Connecting directly to the VM using Hyper-V’s vmconnect is great for doing machine-level stuff like installing operating systems or anything else that requires a reboot.  Unlike Remote Desktop, which loses the connection when the machine reboots, the VMConnect console stays connected, showing you the BIOS POST and boot sequences.  How can it do that?  Because VMConnect is outside the virtual machine that’s being rebooted.  You’re connected to the hypervisor, which is always on and always watching as long as the physical machine is not powered down.

However, VMConnect is not as smooth as Remote Desktop / Terminal Services, presumeably because VMConnect does not have the benefit of intercepting high-level APIs like RD and TS.  VMConnect has only the BIOS and screen memory to track state changes in the VM.  Cursor movement and screen updates are jumpier/chunkier and integration with the local machine’s mouse cursor is not as seamless as Remote Desktop.  For example, VMConnect captures the mouse modally, requiring you to hit a keystroke to give the mouse back to the local (host) desktop. That’s fine for periodic maintenance and administration sorties, but for everyday operations that would drive me nuts.

But that’s ok, because a network-connected VM is like a normal machine in every way – including Remote Desktop connectivity.  Once I get the VM into a usable network-accessible state, I shut down the VM connection and fire up a regular Remote Desktop connection to the VM.  Here are the steps:

1. Install the OS on the VM
2. Reboot the VM on the new OS
3. Join the VM to the corpnet domain with a new, unique machine name
4. Disable sleep on idle in the power management options
5. Enable Remote Desktop connections
6. Add your domain user id to the list of users allowed to RD into the VM
7. Close the VMConnection
8. Fire up a Remote Desktop connection to the VM

Tada!

Many thanks to John Howard for laying out the many pieces needed to get this silly thing to work.

Share/Bookmark