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

I worked from my home in Santa Cruz (California), working with my team in Redmond (Washington). I flew up to Redmond about twice a month for meetings and general face time. San Jose to Seattle is about a two hour flight, so if you don’t mind a very long day it can be done as a one day trip to save the cost of a hotel and being away from home.

I made the most of my time in Redmond. Whatever time slots weren’t booked for meetings with my team or related to our projects I filled with lunches or coffee chats with new faces and old to try to stay abreast with what the rest of the company was up to – and how it related to Windows Live. I hunted down distinguished members of the League of Former Borlanders – lunches with Eddie Churchill, breakfast with Steve Teixeira, even managed to get some coffee time with Anders Hejlsberg every once in a while. The person I saw most often – almost quarterly - was Chuck Jazdzewski, my longtime friend and mentor from the Delphi era.  (Borland Delphi that is, not the Greek era)

More often than not, these catch-up chats would wander from discussing what was being done by this or that project team into what really ought to be done, to what would be really cool to do, if you could strip away the accumulated cruft and distill the essence of the “thing”. These conversations would also often end with a sigh and a shrug as silent acknowledgement of the near futility of trying to swim against the tide in a company as large as Microsoft. It doesn’t really matter what the idea is, good or bad it still takes an enormous amount of effort, coordination, and convergence of forces to get something started in a big company.  (Ever played Diplomacy?  That’s Microsoft project management in spades.  The weird part is, it works!)

A few months after I had extracted myself from the Microsoft vortex and taken up residence in the Cooliris tornado I got a call from Chuck. ”Remember that thing we talked about in our last few chats? I think it’s going to happen.  Forces are in play.” 

Hmm.  Interesting.

A few months later, another call.  “It’s happening. We have slots, we have budget. And I want you on it.”

Oh!

The storm has come full circle. I will soon be jumping back into the Microsoft maelstrom, this time in the Visual Studio / Developer Division (devdiv) team. I will again be telecommuting from Santa Cruz. I’ll be part of a new incubation team composed of Chuck and a few other legendary devdiv veterans (I’m not sure I can say who yet) working on stuff to make accessing Windows Live services easier for developers. In some ways this is a lot like my previous role in the Windows Live team, only on the dev tools side of the coin instead of the services side.

That’s about it for details.  I can honestly answer all further questions with “I don’t know” or “I can’t say.”

Cooliris has been a fun, dynamic gig in so many ways.  I’m proud to have contributed to the Piclens platform abstraction architecture and Windows implementation, built the Piclens font system, text layout and text rendering engine, multiline text editor, and a variety of intangible bits in the tapestry of code. I continue to be a big fan of Piclens and look forward to this team going on to do great things with the Piclens idea. I’ve learned a lot about how the venture capital world works, acquired a new language (Objective C), and made a lot of great friends along the way. One thing is for certain: the software industry is far too small a community for “goodbyes” – there’s only “until we meet again.”

I’m bummed to be leaving Cooliris, but it really all comes down to this:  When you’re walking along minding your own business and a bush bursts into flame and says “I have a task for you”….   Don’t argue!

Share/Bookmark