Share via

SCVMM & Failover Cluster Manager Failure on “Connect to Virtual Machine”

  • Article

The great thing about System Center Virtual Machine Manager (SCVMM) is it’s ability to centrally manage all of your physical hosts, but better yet, your guest virtual machines.  A single console serves all your needs.  If your like me, I often am jumping between the SCVMM console and the Failover Cluster Manager MMC console because there are some needs that one or the other don’t meet perfectly.  After running a Hyper-V Cluster Shared Volume & Failover Clusters for our engineering lab for the past year or so, I recently ran into an unusual situation where my personal work desktop now was unable to connect to any of the guest Operating Systems.  After some research, I found the root cause and I just thought I would share in case others run into the same issue.

Right-click on Virtual Machines, Select Connect to Virtual Machine… and Failed

It is rather easy to reproduce this problem in your environment.  It is important to know that, to reproduce this problem, you would need to install on your personal computer the SCVMM Administration Console from the VMM DVD, or if using Failover Cluster Manager console from the Remote Administration Tools for Windows 7.

image

When you attempt to connect to any of your virtual machines, via the console, When you do this, you open the virtual machine viewer immediately and the connection is shutdown as shown below:

image Error:

imageUseful error. Not so much.  Why do you show me this error?  Well, I just want to make sure the symptoms are clear.  If you utilize the Failover Cluster Manager console, you get a bit more descriptive error to give you some information to think about when troubleshooting.

image

Windows Security & Credential Delegation – Not a VMM/Failover Cluster Console Error

The root cause of this issue isn’t related, ironically, to anything to do with SCVMM or Failover Cluster Console failures.  Instead, this is a Windows security policy setting that is set in Windows 7/Vista.  The odd thing for me is that, for whatever reason, this setting must have been changed recently or an update started enforcement of the policy that it hadn’t done in the past year as I’ve never had this issue previously.

By default, my initial setting for Allow Delegating Default Credentials was set to Not Configured.  It had been set this way for as long as I can remember, or should I say, I don’t recall ever modifying this setting personally.  If our domain group policy was changed it was done unbeknownst to me.  My default setting for this was -

imageAs you can see, it wasn’t configured at all.  This is the root cause of the issue as the Windows security sub-system is not configured to allow any application running under my user credentials (e.g. token) doesn’t have the permission by policy to use those credentials when accessing a computer on the network.  Thus, when attempting to access the Virtual Machine Server you receive access denied. This is due to the above configuration not getting set and if you follow these steps you will be able to correctly access your guest VMs successfully:

  1. Run GPEDIT.MSC on the host
  2. Expand Local Computer Policy > Computer Configuration > Administrative Templates > System > Allow Delegating Default Credentials
  3. Double-click Allow Delegating Default Credentials
  4. Enable the policy
  5. Check “Concatenate OS defaults with input above” (OK, whatever :)
  6. Enter * in the Value textbox
  7. Click OK twice and close Local Group Policy Editor

Result:

imageThe final step, which is required, is to do a GPUPDATE via an elevated command prompt.  To do this, right-click on Command Prompt, select Run as Administrator and enter the following in the console:

gpudate /force

Re-test and you should now be able to successfully connect to your guest virtual machines and order is restored.

Summary

In today’s post, I focused on an issue that screamed for me to get to the bottom of how it “occurred” since for the past year this was never an issue.  However, I don’t have domain administrator rights nor do I know anyone running the Microsoft corporate domains thus I rather not sieze the opportunity to determine root cause and instead focused on the solution.  I came across several forum posts that beat around the issue a bit but this one led me to my answer.  To this, I give all credit herewith in.  You rock.

For me, I’m still puzzled how it worked the past year but I’m now happy again… and maybe you are too!

Thanks,

-Chris