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.

  6 Responses to “Hyper-V Remote Management: Workgroup Vista Client to Domain-Bound Server”

  1. [...] Technology Toolkit wrote an interesting post today onHere’s a quick excerptHyper-V Remote Management: Workgroup Vista Client to Domain-Bound Server June 21, 2008 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 stu [...]

  2. [...] 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. [...]

  3. Hi!

    Very nice – this is my scenario but with slightly differences – my Hyper-V server is also a domain controller (no local groups :) and is managed by SCVMM (HVRemote script doesn’t work). Any suggestions?? :)

  4. Hi Quch,

    You’re way beyond my level of HyperV experience. I’ve never laid eyes on SCVMM, and you say “HVRemote script doesn’t work”. As far as I can tell, the steps outlined by John Howard and echoed here with variations don’t require any scripting.

    The main hazard in my scenario is getting a machine that is a member of a domain to allow access from a machine or user that is not part of the domain. The trick for that is to create a normal local user account on the target server and set up your remote connection to authenticate using that local user account instead of a domain user account.

    -Danny

  5. Okey Danny – thanks anyway :)

  6. Actually,

    I had the same problem as Quch: the Hyper-V root partition also happened to be the domain controller. You can’t create “local users” in a domain controller because there’s no such thing as a local users database.

    What worked for me though is the following: make sure the username and/or password of the domain user you want to be authenticated as is not the same as on your non-domain local machine. If you use a different password, for example, try to browse to the computer (start->run->”\\servername”) and it will show you a password dialog in which you can then type in the corrent username (including the correct domain name!) with which you want to connect.

    Check the box “save password” and it’ll save your credentials in your managed passwords. Next time, the Hyper-V manager will use those credentials to connect, and it’ll work. At least it worked with me.

    Now I used to know where you could manage these “saved passwords” in 2000 and XP, but I can’t seem to find the same dialog in Vista.

    Dave

Sorry, the comment form is closed at this time.