Microsoft’s Virtual Machine Manager: “Host not responding”

Microsoft’s Virtual Machine Manager, or VMM, is a slick piece of tech that smoothly enables users to control virtual machines spread out across multiple hosts, including, of course, localhost.

But what happens when VMM reports “Host not responding”, even for localhost?

This was the question I faced not too long ago. The usual troubleshooting measures I found online (make sure the firewall’s letting you through, make sure the proper services are installed and running, etc.) turned up nothing improper or unusual.

Until, purely out of lack of anything better to do, I typed the command winrm enum winrm/config/listener, and I got this:

Listener [Source="GPO"]
    Address = *
    Transport = HTTP
    Port = 80
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = null

Wait a second! ListeningOn = null?? That doesn’t look right. To be sure, I ran the same command on a server where VMM was working just fine:

Listener [Source="Compatibility"]
    Address = *
    Transport = HTTP
    Port = 80
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 10.0.0.88, 127.0.0.1, 192.168.2.119, [snip]

Well, that looks more like what it should — listening on every IP on the machine. So why was the first one not listening? The “Source” listed on the first line is the clue: Group Policy is configuring the WinRM that isn’t working, but not the one that is. So the obvious conclusion is that the GPO is misconfigured.

So let’s run gpresult /v /scope computer and see what’s going on (snipped for clarity and brevity):

            GPO: Default Domain Policy
                KeyName:     Software\Policies\Microsoft\Windows\WinRM\Service\AllowAutoConfig
                Value:       1, 0, 0, 0
                State:       Enabled
 
            GPO: Default Domain Policy
                KeyName:     Software\Policies\Microsoft\Windows\WinRM\Service\IPv4Filter
                Value:       0, 0
                State:       Enabled
 
            GPO: Default Domain Policy
                KeyName:     Software\Policies\Microsoft\Windows\WinRM\Service\IPv6Filter
                Value:       0, 0
                State:       Enabled

So we’re allowing WinRM to be configured, and then filtering it to… what? Nothing at all? Reading the actual values of policies from this command is not the easiest thing to do, but I’ll just cheat and hand you the answer: “Value: 0,0” means, basically, that it’s filtered to not listen on any IP. Well, more accurately, on IP 0.

Doing some research, it turns out you can configure WinRM to listen on all IPs by simply specifying ‘*’ in the IPv4 and IPv6 filters. Doing this (and then forcing the update with gpupdate /force) results in this change in the GPO:

            GPO: Default Domain Policy
                KeyName:     Software\Policies\Microsoft\Windows\WinRM\Service\AllowAutoConfig
                Value:       1, 0, 0, 0
                State:       Enabled
 
            GPO: Default Domain Policy
                KeyName:     Software\Policies\Microsoft\Windows\WinRM\Service\IPv4Filter
                Value:       42, 0, 0, 0
                State:       Enabled
 
            GPO: Default Domain Policy
                KeyName:     Software\Policies\Microsoft\Windows\WinRM\Service\IPv6Filter
                Value:       42, 0, 0, 0
                State:       Enabled

Hm, “Value: 42, 0, 0, 0”? That’s odd, isn’t it? Well, no one’s ever accused Microsoft of doing things in a logical, sane way! Regardless of the odd, cryptic output here, this fixed our problem, and WinRM was again listening on all IPs. This allowed VMM to once again connect to these hosts and once again control the VMs installed on them.

Now why couldn’t someone have told me this from the get-go???

This entry was posted in Tech and tagged , , , . Bookmark the permalink.