Sign in
 
HomeOnline20132010Other VersionsLibraryForumsGalleryEHLO Blog
TechCenter >
> 
> 
Bug? Event ID 10154 (WinRM service failed to create the following SPNs...)

Proposed Answer Bug? Event ID 10154 (WinRM service failed to create the following SPNs...)

  • Tuesday, June 09, 2009 5:58 PM
     
     
    Sign In to Vote
    0
    I posted this issue in Windows Server 2008 R2 Management, and am posting here because it seems to be related to Exchange Server 2010 as well as Windows Server 2008 R2.

    On Windows Server 2008 R2 (Build 7100) domain controllers, event ID 10154 (WinRM service failed to create the following SPNs...) recurs on OS restart and on WinRM service restart.  In itself, this is a Windows Server 2008 R2 issue because the necessary ACE (Validated write to service principal name) is not added to the domain controller object in Active Directory.  Such an ACE can be added manually using setspn.exe or ADSI Edit, and this will stop recurrence of the event.

    However, if Exchange Server 2010 (Hub Transport Role to be exact) is installed on the domain controller, this ACE will be overwritten when the HT Role is installed and thereafter when the AdminSDHolder thread runs, which is hourly by default, and the event will start recurring again.
    • Edited by sejong Tuesday, June 09, 2009 6:37 PM Added that the ACE overwrite occurs when the HT Role is installed
    •  
     

All Replies

  • Wednesday, June 10, 2009 9:11 PM
     
     
    Sign In to Vote
    0
    hi,

    can you look at here;

    http://technet.microsoft.com/en-us/library/dd348559(WS.10).aspx

    regards,

    Mumin CICEK | Exchange - MVP | www.cozumpark.com | www.mumincicek.com
     
  • Thursday, June 11, 2009 12:10 AM
     
     
    Sign In to Vote
    0
    Thanks for the the link.  I actually had found that link when I first started researching this event.  As I wrote in my original post, the problem is not creating the SPNs.  Even if you create them manually using setspn.exe or using ADSI Edit, the event will recur because the WinRM service is hard-coded to try to add them each time it starts.

    This is a two-part problem: part 1 is that NETWORK SERVICE, which WinRM runs under, doesn't have permission to write to the Active Directory server object, so it can't add the SPNs.  This should be a Server 2008 R2 fix (as opposed to an Exchange fix).

    However, even if Server 2008 R2 is fixed so as to create a ACE for NETWORK SERVICE on the AD server object, Exchange 2010 setup creates an ACE for NETWORK SERVICE with Write Property permissions for Exchange private information on the AdminSDHolder AD object, which applies this ACE, along with all of its security settings, to the server AD object at one-hour intervals. 
     
  • Thursday, June 11, 2009 2:03 AM
     
     
    Sign In to Vote
    0
    Hi,

    Seem you install Exchange 2010 on Domain controller.That is not recommended from Microsoft.if you install Exchange 2010 on Windows 2008 R2 also that is doesn't support and you have to face lot of issuses.i will suggest to intsall exchange 2010 on Windows 2008 Standred or Enterprise insted R2.


    Regards
    Chinthaka
     
  • Thursday, June 11, 2009 2:57 AM
     
     
    Sign In to Vote
    0
    I know of both of your points.  I still think the issue I raised is a bug that should be fixed.
     
  • Wednesday, November 04, 2009 12:10 PM
     
     Proposed Answer
    Sign In to Vote
    0
    I agree, I have the same problem.. E2010 on a 2008R2 DC.. that is still giving the error mentioned, while the SPN's are already registered on the domain controller... it still pop-ups in the eventlog
    WORK FOR AVANADE!
    • Proposed As Answer by DJ-VAR Thursday, May 31, 2012 8:06 PM
    •  
     
  • Wednesday, November 04, 2009 6:34 PM
     
     Proposed Answer
    Sign In to Vote
    1
    In case you didn't already know, this workaround is available: add a Validated write permission for NETWORK Service to the AdminSDHolder AD object, which can be done with the following command.

    dsacls "CN=AdminSDHolder,CN=System,DC=yourdomainname,DC=tld" /G "S-1-5-20:WS;Validated write to service principal name"

    The SDPROP process will propate this ACE to the computer object in the Domain Controller OU, and Event 10154 will stop recurring.
     
  • Wednesday, December 30, 2009 7:38 PM
     
     
    Sign In to Vote
    0

    Hello sejong,
    Having the same issue as described above.  When I ran the DSACLS command above, this was the output...

    =========
    C:\>dsacls "CN=AdminSDHolder,CN=System,DC=childdomain,DC=parentdomain,DC=com" /G "S-1-5-20:WS;Validated write to service principal name"
    No Sid Found for S-1-5-20
    No mapping between account names and security IDs was done.

    The command failed to complete successfully.
    =========

    Am I missing something?

    Thanks in advance.

     
  • Friday, January 01, 2010 1:04 AM
     
     
    Sign In to Vote
    0
    I retried this on my system, and it ran without error. However, I don't have a child domain, but I doubt that makes any difference.
     
  • Monday, January 25, 2010 2:27 PM
     
     
    Sign In to Vote
    0
    I retried this on my system, and it ran without error. However, I don't have a child domain, but I doubt that makes any difference.

    The question is, what service does S-1-5-20 map to your system?

    On another system, we could just use the service name, not the SID.

    Instead, the command should be more like:

    dsacls "CN=AdminSDHolder,CN=System,DC=yourdomainname,DC=tld" /G "DOMAIN\AccountOrGroup:WS;Validated write to service principal name"

    So what is the name of the group/object of the SID S-1-5-20 on your system?
     
  • Monday, January 25, 2010 2:29 PM
     
      Has Code
    Sign In to Vote
    0
    Spoke too soon, S-1-5-20 is a default SID for Network Service.
    NT AUTHORITY\NETWORK SERVICE S-1-5-20
    Ironically, Network Service is not even listed in the ACL of the security tab for AdminSDHolder which explains why the dsacls command failed.
     
  • Friday, March 26, 2010 3:00 PM
     
     
    Sign In to Vote
    0
    Hi I also recieve "Access is denied" when I just enter a simple winrm command like winrm quickconfig, winrm get winrm/config, .....

    I tried a lot of hints in the meantime, no one worked. Here is my thread:

    http://social.msdn.microsoft.com/Forums/en-US/netfxremoting/thread/ad02461a-878c-49a9-bc08-a0199d69b85c

    May be you can help me.

    Thanks a lot in advance.
     
  • Monday, April 19, 2010 6:17 PM
     
     
    Sign In to Vote
    0

    This worked for me!  Thanks sejong.

     
  • Thursday, November 04, 2010 7:53 PM
     
     
    Sign In to Vote
    0
     Try running the following command.  Then wait an hour or so for the SDPROP process to run, and then restart the WinRM service or restart the server.  Event 10154 should not recur.

    dsacls "CN=AdminSDHolder,CN=System,DC=yourdomainname,DC=tld" /G "S-1-5-20:WS;Validated write to service principal name"

    If your domain name was microsoft.com, the command would be

    dsacls "CN=AdminSDHolder,CN=System,DC=microsoft,DC=com" /G "S-1-5-20:WS;Validated write to service principal name"

    If you get the error No Sid Found for S-1-5-20 Then run the command as follows (using microsoft.com as an example):

    dsacls "CN=AdminSDHolder,CN=System,DC=microsoft,DC=com" /G "NT AUTHORITY\NETWORK SERVICE:WS;Validated write to service principal name"

    I ran into this problem as a result of an upgrade from 2003 to 2008 Enterprise.  Thank you SEJONG for the answer.

     
  • Saturday, November 06, 2010 3:50 AM
     
     
    Sign In to Vote
    0
    I tried this 'fix' on my SBS 2003 machine and, whilst the command completed successfully, the error recurs regardless.
     
  • Monday, November 08, 2010 4:52 PM
     
     
    Sign In to Vote
    0
    Sorry, but my only experience with Event 10154 is with Server 2008 R2.
     
  • Monday, November 08, 2010 11:47 PM
     
     
    Sign In to Vote
    0

    Fair enough, but it's probably worth noting that the problem is not restricted to Server 2008 R2 if you are a tech.

    I have noticed that the warnings don't appear as frequently now.
    In fact, the last time was 3 days ago immediately after a reboot and nothing since.
    Prior, it was occurring at regular intervals.

     

     
  • Tuesday, November 09, 2010 8:02 PM
     
     Proposed Answer
    Sign In to Vote
    2

    Maybe you fixed it.  If you haven't already done so, using ADSI Edit, navigate to dc=YourDomain,dc=com > OU=Domain Controllers.  Then right-click your domain controller's object, and click Properties.  Click the Security tab, then the Advanced button.  Click on the Name column to sort on that column.  Navigate down to NETWORK SERVICE.  NETWORK SERVICE should have two ACE's, one of which should be Valididated write to service principal name (not inherited, and applies to this object only).

    Check by restarting the WinRM service.  Event 10154 should not occur.

    • Proposed As Answer by Gaz50 Friday, November 12, 2010 12:00 AM
    •  
     
  • Tuesday, November 09, 2010 11:25 PM
     
     
    Sign In to Vote
    0

    When I used the command, it presented a screen-out of everything and it did say that NETWORK SERVICE now has that ACE but, using ADSI Edit, it doesn't and the error appears again when the WinRM service is restarted.
    In fact, NETWORK SERVICE doesn't even appear in the list. [shrug]

     

     
  • Wednesday, November 10, 2010 5:57 PM
     
     
    Sign In to Vote
    0

    I am confused by your answer.  You said "when I used the command, it presented a screen-out of everything...".  What command was that - maybe dsacls?

    If the Validated write to service principal name is not present on the you domain controllers object in ADSI Edit, try adding it manually (from ADSI Edit or from dsacls), and then restart the WinRM service.  Do you still get Event 10154?

    The ACE you added manually might get overwritten when the SDPROP process runs, but adding the ACE directly to the domain controller object (instead of to the AdminSDHolder object) is worth a try.

     
  • Wednesday, November 10, 2010 11:58 PM
     
     
    Sign In to Vote
    0

    That's right, dsacls.

    You said that there should be 2 ACEs, what's the second?

     

     
  • Thursday, November 11, 2010 2:44 AM
     
     
    Sign In to Vote
    0

    The other ACE is SPECIAL ACCESS for Exchange Personal Information - READ PROPERTY.  You probably won't have this unless your computer is also running Exchange.  Also, this ACE doesn't show in the ADSI Edit GUI, only in the output of dsacls.

    Here is the command I ran, and the output

    dsacls "CN=DC1,OU=Domain Controllers,DC=mydomain,dc=com"

    Allow NT AUTHORITY\NETWORK SERVICE    SPECIAL ACCESS for Exchange Personal Information
    READ PROPERTY

    Allow NT AUTHORITY\NETWORK SERVICE    SPECIAL ACCESS for Validated write to service principal name
    WRITE SELF

     
  • Thursday, November 11, 2010 5:56 AM
     
     
    Sign In to Vote
    0

    All I have is the one I added via ADSIEdit....

    Allow NT AUTHORITY\NETWORK SERVICE                SPECIAL ACCESS for Validated w
    rite to service principal name

    So how do I add the other or do I not need worry about it with Exchange 2003?

     

     
  • Thursday, November 11, 2010 6:35 PM
     
     
    Sign In to Vote
    0

    I would say no, you don't need the other ACE to eliminate Event 10154.  Have you tried restarting the WinRM service to see if Event 10154 recurs?  If the SDPROP process has run since you added the Validated write to service principal name ACE, you may have to re-add it manually and then restart the WinRM service. 

    If the Event 10154 recurs even with the Validated write to service principal name ACE present, I don't know how to fix it.

     
  • Friday, November 12, 2010 12:00 AM
     
     
    Sign In to Vote
    0

    Yes, I have restarted it and no, no further bothersome 10154 errors.

    Actually, after checking on the situation this morning, I have found that NETWORK SERVICE now has the permissions Read, Validated write to service principle name, Read account restrictions, Read DNS host name attributes, Read personal information and Read public information.

    I'd say that nothing more needs to be done.

    Thank you very much for clearing the errors up for me.

    I have noticed that a few of the servers that I manage are having problems in this respect too so I now know how to deal with it.