I recently replaced one of my Hyper-V hosts with Windows Server 2008 R2, and noticed that I was getting the following event logged every two minutes: –
Log Name: Microsoft-Windows-Hyper-V-VMMS-Admin
Source: Microsoft-Windows-Hyper-V-VMMS
Date: 20/09/2009 5:52:42 PM
Event ID: 14050
Task Category: None
Level: Error
Keywords: �
User: SYSTEM
Computer: HyperV01.mydomain.internal
Description:
Failed to register service principal name.
I was nearly certain that this was due to the fact that I hadn’t removed the computer from the domain before rebuilding it, and therefore it had acquired the old computer account when it was re-joined. This error indicates that there was an error updating the “servicePrincipalName” attribute of the computer account for my Hyper-V server.
I jumped in to my Active Directory to check out the permissions of the computer account first, and the first thing I noticed was that there was an unresolvable SID in my ACL. This wasn’t causing the issue, but it was a good indication that the permissions were probably in need of attention.
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: –
…And bingo! The “SELF” entry is missing the “Validated write to service principal name” permissions, so therefore it can’t write the attribute. “SELF” in this case, corresponds to the SYSTEM account of the host that owns the computer account.
So I went ahead and granted this permission to the computer account, and confirmed that the servicePrincipalName attribute updated on next attempt and that the events were no longer being logged.
Quick question
How the hell do you get the the box as shown in the last picture?
Hi Luke,
If you can’t see the security tab in your console, you probably need to turn on Advanced Features.
Just go up to the View menu, and check Advanced Features.
Thanks for the reply,
I found it after right-clicking the computer after activating Advanced Features.
Thanks again,
Luke
Hellow!
I have a same problem, but i not use a domain control.
my server is stand-alone with Windows 2008 R2 STD
where they found this option to configure this security
Thanks
how do you get to the screenshot ? cant find it anyhwere…
Hi Chris,
I’m assuming you don’t have the Security tab?
In Active Directory Users and Computers, click on View, then tick Advanced Features.
This will enable additional tabs in your view, including Security.
Hi,
thanks for the quick reply. no, i cannot find the system account. I assume I have to open active directory users and computers, check the advanced features on my PDS/AD. But in there i cannot find the system account anywhere.
where do i find it ?
Hi,
what are the steps to do to get to your screenshot ?
Hi Chris,
The image is stored at ImageShack – The direct URL to the image is http://img36.imageshack.us/img36/9822/spninvalid.gif
If you can’t load it, perhaps you have imageshack.us blocked somewhere?
no, i mean how do you get to the screenshot in windows 2008. what do you click to get there ?
Chris, you make mention of the SYSTEM account, however when looking at the ACL’s of the objects in AD, what you are looking for is the SELF account rather than the SYSTEM account.
I believe this question has already been answered above, but to re-iterate, you need to ensure that Advanced Features is turned on in Active Directory Users and Computers, which will allow you to see the Security tab of objects.
You want to look at the Security tab of the HyperV server’s computer account.
i am too stupid to find this. i opened AD users and computers on the DC (hyperv guest) and checked advanced features. the i opened properties of the DC and the Host I can see the validated write on SELF checked for both.
Is that the correct spot ? could you provide the excat way to get to the point where you need to set the check mark ? eg open ADUC, go to computerx or user accoun y, click properties, click security, et voila.
something like this… from the comments it seems that this is still unclear for many readers.
best pete
Hi Peter,
You are spot on with the actions you performed, so it sounds like you may have a different issue if SELF already has validated write permissions.
I’m struggling with this too, with a Hyper-V just installed on an Server 2008 Standard R2 SP1 system, a member server on a 2003 R2 domain. ADUC shows the above already allowed for SELF. Oddly, I don’t get the errors when restarting HV services, just when rebooting. Four identical 14050’s within 30 seconds of each other.
I not have the Active Directory, but Domain Controller is Samba.
I have the error: “Failed to register service principal name”, but haven’t SELF because haven’t Active Direcotry.
Is possible resolve the problem?
Please!
Worked for me. Thanks!
I am having a similar issue. First I tried to restart VMMS via Technet blog post. That didn’t solve my problem. I then found your article and my particular setting was already selected. Is there any other options I can try?
My Windows 2008 R2 server is running in a SBS 2003 domain. Thanks in advance!
I’m having this problem too, but also I know there are issues on my DC. I can’t create GPOs either for example. I believe something went amiss when I transfered my FSMO roles back on to that server, then a disk failed on a different server which messed up replication and finally the servers are reporting different schemas even though I updated to try and get everything on 2008r2. There are a lot of things wrong with my servers and I’m hoping this will give other people some more ideas of things to check when they have this problem with HyperV
I have the same problem. I checked with ADUC the computer account of my Hyper-V Server. The check box Validated write to service principal name for the SELF ACL entry was allready checked. Then I uncked I press Apply and then rechecked and press again Apply. I Reboot my Hyper-V Machine and no more 14050 errors appeard in the event log.
OK, what if I am not running Hyper-V under AD. I am using 2008 R2 as my development OS so I can use Hyper-V for development images.
Any suggestions?
Thank You Spiros that’s it:
“The check box Validated write to service principal name for the SELF ACL entry was allready checked. Then I uncked I press Apply and then rechecked and press again Apply. I Reboot my Hyper-V Machine and no more 14050 errors appeard in the event log.”
Good luck
Repeat:
Thank You Spiros that’s it:
“The check box Validated write to service principal name for the SELF ACL entry was allready checked. Then I uncked I press Apply and then rechecked and press again Apply. I Reboot my Hyper-V Machine and no more 14050 errors appeard in the event log.”
Good luck
Thanks for your post.
I have the same issue.
Once the “Validated write to service principal name” enable in the AD event is stopping. But after a few moment (when check) above setting is again unchecked in the AD security settings (Events are again appearing) in. Is this normal behavior or is there any other setting to configure this permanently?
Thanks for the blog post.
I also had to untick > apply > tick again.
My Hyper-V host is a Windows Server 2012 (non R2) and my domain server 2008 R2. Had the same issue and “untick > apply > tick > reboot Hyper-V host” did not work. Guess I have to dig deeper.
Thanks a lot!!!
Its great but what if we restart the services or just register it ? its greatly discussed it here with solution as well.
http://www.ipaddresshost.com/event-id-14050-failed-register-service-principal-name-source-hyper-v-vmms/
Just one thing to say: THANKS!!!!!!!!!!
(this is the only post with the right solution, i’ve just wasted hours googleing and trying to fix the 14050 issues)
Hi All,
Great article, try sort this issue with my host for long time, this happen with me when set connection, VPN Site-to-Site, in differed location, after this changes work perfect, even tried Microsoft blogs, and nothing, well done,
Thanks again, lot!!!
Great!!! worked like a charm