Jun 212008
 

So here I am configuring my dev machine in Redmond from my laptop in my home office in Santa Cruz.  I’m all VPN’d and security card authenticated up the wazoo, installing this and configuring that on the dev machine via Remote Desktop.  (Praise be to RD!)

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.