New Network Name Resource Fails to come Online

I recently encountered an issue involving the failure of a new Network Name resource to come online. Doing some investigation I found a number of instances where this has been encountered, with different resolutions provided.  Since no root cause was defined, fellow Directory Services Engineer Robert Williams and I set out to determine the cause. 

You’ll know you’ve encountered this issue if you create a new Network Name resource and it fails to online with the following errors:

In the System Event log you will see a Failover Cluster event 1194:

Log Name:      System

Source:        Microsoft-Windows-FailoverClustering

Date:          3/27/2013 1:19:07 PM

Event ID:      1194

Task Category: Network Name Resource

Level:         Error


User:          SYSTEM

Computer:     ComputerName


Cluster network name resource ‘ComputerName’ failed to create its associated computer object in domain ‘DomainName’ for the following reason: Unable to obtain access to Computer Object in DS.


The text for the associated error code is: Access is denied.


Please work with your domain administrator to ensure that:

  • The cluster identity ‘CNO’ can create computer objects. By default all computer objects are created in the ‘Computers’ container; consult the domain administrator if this location has been changed.
  • The quota for computer objects has not been reached.
  • If there is an existing computer object, verify the Cluster Identity ‘CNO’ has ‘Full Control’ permission to that computer object using the Active Directory Users and Computers tool.


In the Cluster log you will see the following entries:


00000ea4.000012b0::2013/03/25-16:55:04.113 ERR   [RES] Network Name < NetworkName>: Failed to obtain access to computer account < AccountName>, status 80070005

00000ea4.000012b0::2013/03/25-16:55:04.128 ERR   [RHS] Online for resource <NetworkName> failed.



Note:   To generate a Cluster log, run the following command from an administrators command prompt. The Cluster.log file will be generated in the c:\windows\cluster\reports directory.  The entry will be in the Cluster log on the Node where the online attempt failed.


Cluster log /gen

We determined that the root cause of the issue is due to the removal of NT AUTHORITY\Authenticated Users from the local Users group.  Note below that it is present by default:






The best solution is to add back NT AUTHORITY\Authenticated to the local Users Group. This will require a reboot for the change to take effect.  If your security team is unwilling to do this, you can disable the following two Security policies and refresh the policy by running gpupdate /force:


Network access: Do not allow anonymous enumeration of SAM accounts

Network access: Do not allow anonymous enumeration of SAM accounts and shares




You will have to determine which of these two options best fits the security requirements for your environment.   It may be a good option to create a separate Organizational Unit (OU) for your Cluster servers.  This will allow you to affect the preferred change to the limited subset of servers. 


Steven Andress

Senior Support Escalation Engineer

Microsoft Customer Support & Services