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:
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.
Product: Windows Operating System
Symbolic Name: MSVM_VMMS_REGISTER_SPN_ERROR
Message: Failed to register service principal name.
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.
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).
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."
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.
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.
Check that the VMMS service is in the running state in the Service Control Manager and that the failed operation now succeeds.
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://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.
http://social.technet.microsoft.com/Forums/en-US/winserverhyperv/thread/2574529c-0507-47ac-a850-b19cb0c9cd7c/ David Shen said:
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."