Share via

Hyper-V: Troubleshooting Event ID 14050 — VMMS

  • Article

Event ID 14050 — VMMS
Applies To: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012 

*(*This wiki page is part of a pilot program to remove topics such as this one from the TechNet and MSDN libraries and move them to the wiki.We plan to do a better job of helping customers. This blog post discusses some of the ideas: http://blogs.technet.com/b/tonyso/archive/2010/08/25/2-great-tastes.aspx.)

The Virtual Machine Management Service (Vmms.exe)  is the service that uses WMI to perform Virtual System Management related operations in Hyper-V and the Hyper-V Manager.

Event Details

Product: Windows Operating System
ID: 14050
Source: Microsoft-Windows-Hyper-V-VMMS
**Version: **6.0
Symbolic Name: MSVM_VMMS_REGISTER_SPN_ERROR
Message: Failed to register service principal name.

Explanation:

 Kerberos authentication is not possible for services without properly set Service Principal Names (SPNs). SPNs are unique identifiers for services running on servers. Each service that uses Kerberos authentication needs to have an SPN set for it so that clients can identify the service on the network. It is registered in Active Directory under a user account as an attribute called Service-Principal-Name. The SPN is assigned to the account under which the service the SPN identifies is running. Any service can look up the SPN for another service. When a service wants to authenticate to another service, it uses that service’s SPN to differentiate it from other services running on that computer.

In general, only one SPN should be set for each service. Multiple SPNs can cause clients to connect to the wrong system or the ticket may be encrypted with the wrong key.

Resolution:

Restart VMMS

Vmms.exe (by default in the %windows%\system32 directory) is the service that uses the Msvm_VirtualSystemManagementService WMI object to perform Virtual System Management related operations in Hyper-V and the Hyper-V Manager.  A number of different settings and actions on virtual machines may cause the VMMS to timeout or shutdown.

Ensure a connection to a Domain Controller, and then restart the Virtual Machine Management Service (VMMS).

 

To restart VMMS using the Service Manager:

 

1. In the Hyper-V Manager click the server on which you want to stop the service, then click Action, then click Stop Service.

2. Click Action, and then click Start Service.

To restart the VMMS service using the command prompt:

1. On the computer that has the stopped service, open a command prompt as local administrator and type the following:

net stop nvspwmi

If the service is not running, you will see the error "The Hyper-V Networking Management service is not started."

3. On the command prompt type the following command to start the nvpswmi service

net start nvspwmi

 If the service start starts you will see the message "The Hyper-V Networking Management service was start successfully."

 

To restart VMMS using PowerShell:

 

1. On the computer that has the stopped service, open a command prompt as local administrator and type the following:

C:\PS>restart-service vmms

If this error occurs only with Windows Server 2008 x86 virtual machines that were created in Virtual Server or Virtual PC, then the HAL may not be set as ACPI.

 

To check this:

 

1. On the virtual machine, open an elevated Command Prompt window.

2. Type devmgmt.msc  to open the Device Manager

3. Click the computer node. If you see “Advanced Configuration and Power Interface (ACPI) PC” you must change the HAL.

To Verify:

Check that the VMMS service is in the running state in the Service Control Manager and that the failed operation now succeeds.

Advanced Troubleshooting:

If the basic troubleshooting above, fails, this may be due to Service Hardening when dynamicportrange is changed.  This applies to Windows Server 2012 systems.  For further details, see http://support.microsoft.com/kb/2761899.

See Also:

Community Resources

 at: http://technet.microsoft.com/en-us/library/bb217455%28EXCHG.80%29.aspx Microsoft says (for Exchange):

Make sure that the server that logged this event is properly registered on the Domain Name System (DNS) server. For more information about how to troubleshoot DNS issues, see Troubleshooting DNS servers.

An SPN is registered using a remote procedure call (RPC). Review other Warning events and Error events in the Application log to find out if there are RPC failures.

As a workaround, manually configure the SPN for the service specified in the event description. For more information about how to manually configure the SPN, see Service Logons Fail Due to Incorrectly Set SPNs. \

If this error frequently occurs, contact Microsoft Product Support. For information, visit the Contact Us page of the Microsoft Help and Support Web site.

At http://social.technet.microsoft.com/Forums/en-US/winserverhyperv/thread/2574529c-0507-47ac-a850-b19cb0c9cd7c/ David Shen said:

It seems that this issue is related to SCVMM. If possible, please manually uninstall the SCVMM 2008 beta and follow the steps to change the registry on the parent partition to see whether it works.

* *

1. Open Registry Editor with “regedit”

* *

2. Find and locate the registry key:

* *

HKEY_LOCAL_MACHINE\SOFTWARE\Micorsoft\Windows NT\CurrentVersion\Virtualization

* *

Key name: StoreLocation

* *

3. change the value of StoreLocation to "msxml://C:\ProgramData\Microsoft\Windows\Hyper-V\InitialStore.xml" (without quotation mark)

* *

4. restart the parent partition.

* *

5. please check if the issue re-occur.

At http://techblog.mirabito.net.au/?p=230 Mat Mirabito says:

To understand how to resolve this issue, it’s important to understand what’s failing. In this case, we can see from the event 14050, that the SYSTEM account on my Hyper-V host tried to update the servicePrincipalAttribute of it’s own computer account within Active Directory, but failed. We believe it’s a permissions issue, so we should check the “SELF” entry in the ACL to see if it has the correct permissions...

At http://wp.drewhill.net/?p=158 Drew notes:

I believe this issue is the result that I am running this in a lab environment where my DCs are VMs on the Hyper-V server itself.  I’m seeing the error after I reboot the physical server and before I get the VMs started that are running my domain controllers.   If you happen to see this issue I would start looking at my connection to the my DCs.

If this event comes from Virtual PC, At http://www.aspdeveloper.net/tiki-index.php?page=VirtualServerEvents_14050 steveradich notes:

*"You may run into this error if your domain is not established correctly.

When I saw this the computer had a DHCP assigned address on a network adapter which wasn't used on the host. The DHCP address conflicted with the route to the domain controllers - i.e. to reach the domain controllers the source IP was the DHCP assigned address, NOT the primary NIC that should have been used. This had the wrong firewall rules and therefore couldn't talk to the domain controller correctly.

This SHOULD be a very uncommon mistake.

You can check that your route to your domain controllers is how you expect via "tracert" and ipconfig /all

Also check your DNS."*