Unable to add host or hosts in "Needs Attention" state (SCVMM 2008 Beta)?

These are probably two of the most frequently asked questions in the Technet SCVMM forum.

  • I'm unable to add host, what did I do wrong?
  • What do I need to do when I have host in "Needs Attention" state or my "Connection Status" is "Not Responding"?

The first thing I'd ask people to do is to check the FAQ published on Connect site along with the beta bits, which covers the known issues and limitation for this beta release. One of the things we documented there is that a USB drive could cause your host be in this "Needs Attention" state. We're fixing the issue for our RTM release.

Secondly, I'd recommend you to check the troubleshooting note published for our VMM 2007 release, which covers a lot of commonly seen and known issues for both add host (or agent install) scenarios and hosts in "Needs Attention" state. The most commonly seen causes of failure are:

  • Host Hyper-V service is not working properly. The causes include:
    • Host computer's hardware is not virtualization capable (check here for what Hyper-V requires for hardware-assisted virtualization).
    • Host computer's hardware virtualization is not enabled. What we found is that most Intel chip based computer's VT is not enabled in factory default, AMD-chip-based computer's is enabled by default.
    • In either case, you might need to check the BIOS to confirm.
  • Firewall rules on the host or in the network blocks the initial DCOM communication, or HTTP/HTTPS communications between VMM server and the to-be-managed host.
    • Turning off the firewall during the initial deployment may help identify the causes of AddHosts failure.
    • Please note, once the agent is deployed, SCVMM server does not use DCOM to communicate with the hosts. Instead, we use HTTP(for WS-MAN)/HTTPS(for BITS) to communicate with the hosts. As part of the agent install, we add firewall exceptions to allow HTTP and HTTPS traffic to the host. Therefore, once the host agent is deployed, as long as your HTTP and HTTPS ports are open, VMM server should be able to connect to your hosts.
  • SCVMM user and group was removed for DMZ host or untrusted domain joined host.
    • During agent deployment, SCVMM creates a group SCVMM and a user starting with string "SCVMM". And the user "SCVMMxxxxx" is added to the local Administrators group and the Virtual Machine Manager Servers group.
    • We've seen cases where the user and group created by SCVMM are removed by group policy automatically, or removed manually by mistake. Without this user, VMM server will not be able to connect to the host.
    • Please note, in trusted domain joined host scenario, we do not create local user. We use VMM Server machine account to authenticate and communicate with the host.
  • Incorrect version of Hyper-V
    • For this SCVMM 2008 Beta release, we support Hyper-V RC0 release (KB949219).

Lastly, here are some additional testing you could do on your host to unveil issues with services that VMM is dependent of:

  • To check integrity of or repair your host WMI repository,
    • run "winmgmt /salvagerepository".
  • To check your WMI virtualization store,
    • start wbemtest by using a local admin account of the host machine and
    • connect to \\<host>\root\virtualization
    • Try query "select * from msvm_ComputerSystem" and see if it succeeds.
  • To check your host's WMI namespace security settings,
    • Go to Server Manager, click on Configuration then right-click on WMI Control and choose Properties
    • Click on Security tab, choose SCVMM and check its Security Settings.
      • Make sure that both Administrators group and Virtual Machine Manager Servers group have the full rights on the namespace.
  • To check your WnRM state,
    • run "winrm qc".
  • To check if the WinRM listener is running,
    • run "winrm enum winrm/config/listener", or
    • run "winrm get winrm/config" to get the entire WinRM config.
  • To check if your VMM agent is responding to winrm calls,
    • run "winrm invoke GetVersion wmi/root/scvmm/AgentManagement -r:https://<host> @{}".
  • To manually restart VMM server service:
    • run "net stop vmmservice", and run "net start vmmservice".
  • To manually restart VMM host agent service:
    • run "net stop vmmagent", and run "net start vmmagent".
  • To manually restart Hyper-V service:
    • run "net stop vmms", and run "net start vmms".

 

Debugging

If above resources cannot help you find the root cause, try collect debugging traces by following the instructions posted here, study the trace logs and look for exceptions from the traces to get a clue on where things might have gone wrong.

 

Hope this helps and thanks for reading,

Cheng