1.

Solution:
1. Verify
a.
b.
c.
d.
e.

that Cluster virtual Name already exists in the domain

Go to domain
Run
Dsa.msc
Delete the virtual name
Try to make the virtual name online from Fail over cluster Manager

Scenario: Manual fail over is not working due to

Passive node N/W issue.

Error during installation of an SQL

server Failover Cluster Instance
A common issue I've run into while helping with SQL
Server Failover Cluster (FCI) installations is
the failure of the Network Name. In the following
post I'll discuss a bit of background, the common
root cause, and how to resolve it.
Background
The SQL Server Database Engine service is dependent on the Network Name resource. A failure of the Network Name will
result in the SQL Server Resource not coming online.

When the Windows Failover Cluster (WFC) is initially configured a Cluster Name object (CNO) will be created. The CNO is
visible as a computer object in your Activity Directory Users and Computer snap-in (dsa.msc). By default the CNO will be
created in the Computers container and granted specific permissions:

After a successful SQL Server FCI inst

allation you will now see a Virtual Computer Object (VCO) for the SQL Server Network Name:

*Note: After the CNO is created any additional Network Name resource in the cluster is considered a Virtual Computer
Object. VCOs are simply Computer objects in which the CNO has permissions to change the properties or reset the
password.

Problem
But what if the CNO does not possess the required permissions to create computer objects in the Computers container?

It is in the above scenario where we commonly see the following errors during SQL Server FCI installation:

The following error has occurred:

The cluster resource 'SQL Server (SQL2012)'

could not be brought online due to an error
bringing the dependency resource 'SQL Network
Name(VSQL2012)' online. Refer to the Cluster
Events in the Failover Cluster Manager for more
information.

A user encountering the same issue while installing a pre-SQL Server 2012 version may see:

The cluster resource 'SQL Server (MSSQLSERVER)' could not be brought online. Error: The resource failed to come online
due to the failure of one or more provider resources. (Exception from HRESULT: 0x80071736)

System log:

Cluster network name resource 'SQL Network Name (VSQL2012)' failed to create its associated computer object in domain
'motox.com' during: Resource online.

The text for the associated error code is: A constraint violation occurred.

Please work with your domain administrator to ensure that:

- The cluster identity 'CLUS2012$' has Create Computer Objects
permissions. By default all computer objects are created in the
same container as the cluster identity 'CLUS2012$'.

- The quota for computer objects has not been

reached.
- If there is an existing computer object, verify the
Cluster Identity 'CLUS2012$' has 'Full Control'
permission to that computer object using the Active
Directory Users and Computers tool.
Cluster log:

[RES] Network Name: [NNLIB] Creating object VSQL2012

using ADSI in OU OU=SQL,DC=motox,DC=com on
DC: \\MOTOXDC.motox.com, result: 8239
[RES] Network Name: [NNLIB] Failed to create Computer
Object VSQL2012 in the Active Directory, error 8239
Cause

The common cause of the Network Name resource failure is insufficient permissions. More specifically, the permission
"Create Computer Objects" has not been granted to the Cluster Name Object(CNO).

http://technet.microsoft.com/en-us/library/cc731002(v=ws.10).aspx

when you create a failover cluster and configure clustered services or applications, the failover cluster wizards create
the necessary Active Directory computer accounts (also called computer objects) and give them specific permissions. The
wizards create a computer account for the cluster itself (this account is also called the cluster name object or CNO) and a
computer account for most types of clustered services and applications

When the SQL Server Network Name is first brought online during the FCI installation process, the CNO identity is used to
create the VCO(as long as the VCO doesnt already exist). If the required permissions are not granted to the CNO, the
creation of the VCO will fail and so will your SQL Server FCI installation.

*Note: The Create Computer objects right only applies to Domain Functional Levels above Windows Server 2003. For
Windows Server 2003 the required privilege is Add Workstations to the Domain.

Resolution(s)
Option #1

We must grant the permissions "Read all properties" and "Create

Computer objects" to the CNO via the container. Here's an example
of granting the required permissions for demonstration purposes:
1. Open the Active Directory Users and Computers Snap-in
(dsa.msc).
2. Locate Computers container:

3. Make sure "Advanced Features" is selected:

4. Open the properties of the container and click the "Security" tab. Click "Add" and add the CNO. Make sure to select
Computers option in the Object Types window:

5. Click "Advanced", highlight the CNO, and click "Edit":

6. Make sure "Read all properties" and "Create Computer objects" are checked. Click OK until you're back to the AD Users
and Computer window:

7. Retry your previously failed installation. Note that with SQL Server 2012 there will be a retry button.

Option # 2

We can also Pre-Stage the VCO, which is useful in situations where the Domain Administrator does not allow the CNO
Read All Properties and Create computer Objects permissions:

1. Ensure that you are logged in as a user that has permissions to create computer objects in the domain.

2. Open the Active Directory Users and Computers Snap-in (dsa.msc).

3. Select View -> Advanced Features.

4. Right click the OU/Container you want the VCO to reside in and click New -> Computer

5. Provide a name for the object (This will be your SQL Server Network Name) and click OK:

6. Right click on the on the VCO you just created and select Properties. Click the security tab and then click Add:

7. Enter the CNO (Make sure to select Computers option in the Object Types window) and click OK.

8. Highlight the CNO, check the following permissions, and click OK.

Read

Allowed To Authenticate

Change Password

Receive As

Reset Password

Send As

Validate write To DNS Host Name

Validate Write To Service Principle Name

Read Account Restrictions

Write Account Restrictions

Read DNS Host Name Attributes

Read MS-TS-GatewayAccess

Read Personal Information

Read Public Information

*Note: You can replace step #8 by giving the CNO Full Control over the VCO

9. Install SQL Server and the Network Name resource should start without issue.

A SQL Server cluster resource goes to a "failed" state when you

try to bring the resource online in SQL Server

SYMPTOMS
When you try to bring a SQL Server cluster resource
online for a virtual instance of Microsoft SQL Server
2000, of SQL Server 2005, or of SQL Server 2008,
you may notice the following behavior:

The SQL Server cluster resource goes to a

"failed" state and does not come online.

You receive a combination of the following error

messages on the computer that owns the SQL
Server cluster resource.
Error message 1
An event that is similar to the following is in the system event log:

Date: 08/05/2004
Time: 1:11:19 AM
Source: ClusSvc
Category: Failover Mgr
Type: Error
Event ID: 1069
User: N/A
Computer: <Computer Name>
Description:
Cluster resource 'SQL Server (<SQL Server instance name>)' in Resource Group '<Cluster group name>'
failed.

Error message 2
An error message that is similar to the following is in the Cluster log file:

00000644.00000944::2003/11/30-18:11:30.360 SQL Server <SQLServer>: [sqsrvres] Unable to read the

'VirtualServerName' property. Error: d.
00000644.00000944::2003/11/30-18:11:30.360 SQL Server <SQLServer>: [sqsrvres] OnlineThread: Error d
bringing resource online.

Error message 3
Error messages that are similar to the following are in the SQL Server error log file:

2003-11-30
2003-11-30
2003-11-30
2003-11-30
2003-11-30
2003-11-30
2003-11-30
2003-11-30
2003-11-30

17:00:37.27
17:00:37.27
17:00:37.27
17:00:37.27
17:00:37.27
17:00:37.27
17:00:37.27
17:00:37.27
17:00:37.27

server Error: 17826, Severity: 18, State: 1

server Could not set up Net-Library 'SSNETLIB'..
spid13 Starting up database 'SPB'.
spid12 Starting up database 'BD_MTA'.
spid14 Starting up database 'BD_SPF'.
server Error: 17059, Severity: 18, State: 0
server Operating system error -1073723998: ..
server Unable to load any netlibs.
server SQL Server could not spawn FRunCM thread.

CAUSE
The resource-specific registry keys that correspond to the SQL Server cluster resource that you are trying to
bring online are missing. This problem also occurs if the values that correspond to the resource-specific
registry keys are not correct.

RESOLUTION
Important This section, method, or task contains steps that tell you how to modify the registry. However,
serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow
these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore
the registry if a problem occurs. For more information about how to back up and restore the registry, click
the following article number to view the article in the Microsoft Knowledge Base:
322756 How to back up and restore the registry in Windows

To resolve this problem, you must manually re-create the resource-specific registry keys that correspond to
the SQL Server cluster resource. To do this, follow these steps:

1.

Click Start, click Run, type Regedit, and then click OK.

2.

In Registry Editor, locate and select the following registry key:

HKEY_LOCAL_MACHINE\Cluster\Resources\<GUID>\Parameters
3.

Create the following registry values in the

Parameters
registry key:
For a default instance of SQL Server:

InstanceName
Value Name: InstanceName
Value Type: REG_SZ
Value Data: MSSQLSERVER

VirtualServerName
Value Name: VirtualServerName
Value Type: REG_SZ
Value Data: <Name of the virtual SQL server>
For a named instance of SQL Server:

InstanceName

Value Name: InstanceName

Value Type: REG_SZ
Value Data: <SQL Server instance name corresponding to the virtual server>

VirtualServerName
Value Name: VirtualServerName
Value Type: REG_SZ
Value Data: <Name of the virtual SQL server>

4.

Quit Registry Editor.

After you create the resource-specific registry keys, you can bring the SQL Server cluster resource online
successfully.
If you notice that a SQL Server Agent cluster resource cannot be brought online, you must create the same
set of resource-specific keys that correspond to the SQL Server Agent cluster resource.

Failover Cluster
Troubleshooting
Updated: October 21, 2015
Applies To: SQL Server 2014, SQL Server 2016 Preview
This topic provides information about the following issues:

Basic troubleshooting steps.

Recovering from a failover cluster failure.

Resolving the most common failover clustering problems.

Using extended stored procedures and COM objects.

Basic Troubleshooting Steps

The first diagnostic step is to run a fresh cluster validation check. For details on validation, see Failover Cluster Step-by-Step
Guide: Validating Hardware for a Failover Cluster. This can be completed without any interruption of service as it does not
affect any online cluster resources. Validation can be run at any time once the Failover Clustering feature has been
installed, including before the cluster has been deployed, during cluster creation and while the cluster is running. In fact,
additional tests are executed once the cluster is in use, which check that best practices are being followed for highlyavailable workloads. Across these dozens of tests, only a few of them will impact running cluster workloads and these are
all within the storage category, so skipping this entire category is an easy way to avoid disruptive tests. Failover Clustering
comes with a built-in safeguard to prevent accidental downtime when running the storage tests during validation. If the
cluster has any online groups when validation is initiated, and the storage tests remain selected, it will prompt the user for
confirmation whether they want to run all the tests (and cause downtime), or to skip testing the disks of any online groups
to avoid downtime. If the entire storage category was excluded from being tested, then this prompt is not displayed. This
will enable cluster validation with no downtime.

How to revalidate your cluster

1.

In the Failover Cluster snap-in, in the console tree, make sure Failover Cluster Management is selected and
then, under Management, click Validate a Configuration.

2.

Follow the instructions in the wizard to specify the servers and the tests, and run the tests. The Summary page
appears after the tests run.

3.

While still on the Summary page, click View Report to view the test results.
To view the results of the tests after you close the wizard, see %SystemRoot%\Cluster\Reports\Validation
Report date and time.html where %SystemRoot% is the folder in which the operating system is installed (for
example, C:\Windows).

4.

To view help topics that will help you interpret the results, click More about cluster validation tests.

To view help topics about cluster validation after you close the wizard, in the Failover Cluster snap-in, click Help, clickHelp
Topics, click the Contents tab, expand the contents for the failover cluster help, and click Validating a Failover Cluster
Configuration. After the validation wizard has completed, the Summary Report will display the results. All tests must
pass with either a green check mark or in some cases a yellow triangle (warning). When looking for problem areas (red Xs
or yellow question marks), in the part of the report that summarizes the test results, click an individual test to review the
details. Any red X issues will need to be resolved prior to troubleshooting SQL Server issues.
Install Updates
Installing updates is an important part of avoiding problems with your system. Useful links:

Recommended hotfixes and updates for Windows Server 2012 R2-based failover clusters

Recommended hotfixes and updates for Windows Server 2012-based failover clusters

Recommended hotfixes and updates for Windows Server 2008 R2-based failover clusters

Recommended hotfixes and updates for Windows Server 2008-based failover clusters

Recovering from Failover Cluster Failure

Usually, failover cluster failure is to the result of one of two causes:

Hardware failure in one node of a two-node cluster. This hardware failure could be caused by a failure in the SCSI
card or in the operating system.
To recover from this failure, remove the failed node from the failover cluster using the SQL Server Setup program,
address the hardware failure with the computer offline, bring the machine back up, and then add the repaired
node back to the failover cluster instance.
For more information, see Create a New SQL Server Failover Cluster (Setup) and Recover from Failover Cluster
Instance Failure.

Operating system failure. In this case, the node is offline, but is not irretrievably broken.
To recover from an operating system failure, recover the node and test failover. If the SQL Server instance does
not fail over properly, you must use the SQL Server Setup program to remove SQL Server from the failover
cluster, make necessary repairs, bring the computer back up, and then add the repaired node back to the failover
cluster instance.
Recovering from operating system failure this way can take time. If the operating system failure can be recovered
easily, avoid using this technique.
For more information, see Create a New SQL Server Failover Cluster (Setup) and How to: Recover from Failover
Cluster Failure in Scenario 2.

Resolving Common Problems

The following list describes common usage issues and explains how to resolve them.

Problem: Incorrect use of command-prompt syntax to

install SQL Server

Issue 1: It is difficult to diagnose Setup issues when using the /qn switch from the command prompt, as the /qnswitch
suppresses all Setup dialog boxes and error messages. If the /qn switch is specified, all Setup messages, including error
messages, are written to Setup log files. For more information about log files, see View and Read SQL Server Setup Log
Files.
Resolution 1: Use the /qb switch instead of the /qn switch. If you use the /qb switch, the basic UI in each step will be
displayed, including error messages.

Problem: SQL Server cannot log on to

the network after it migrates to another
node
Issue 1: SQL Server service accounts are unable to contact a domain controller.
Resolution 1: Check your event logs for signs of networking issues such as adapter failures or DNS problems. Verify that
you can ping your domain controller.
Issue 2: SQL Server service account passwords are not identical on all cluster nodes, or the node does not restart a SQL
Server service that has migrated from a failed node.
Resolution 2: Change the SQL Server service account passwords using SQL Server Configuration Manager. If you do not,
and you change the SQL Server service account passwords on one node, you must also change the passwords on all other
nodes. SQL Server Configuration Manager does this automatically.

Problem: SQL Server cannot access the

cluster disks
Issue 1: Firmware or drivers are not updated on all nodes.
Resolution 1: Verify that all nodes are using correct firmware versions and same driver versions.
Issue 2: A node cannot recover cluster disks that have migrated from a failed node on a shared cluster disk with a different
drive letter.
Resolution 2: Disk drive letters for the cluster disks must be the same on both servers. If they are not, review your original
installation of the operating system and Microsoft Cluster Service (MSCS).

Problem: Failure of a SQL Server service

causes failover
Resolution: To prevent the failure of specific services from causing the SQL Server group to fail over, configure those
services using Cluster Administrator in Windows, as follows:

Clear the Affect the Group check box on the Advanced tab of the Full Text Properties dialog box. However, if
SQL Server causes a failover, the full-text search service restarts.

Problem: SQL Server does not start

automatically
Resolution: Use Cluster Administrator in MSCS to automatically start a failover cluster. The SQL Server service should be
set to start manually; the Cluster Administrator should be configured in MSCS to start the SQL Server service. For more
information, see Managing Services.

Problem: The Network Name is offline and you

cannot connect to SQL Server using TCP/IP
Issue 1: DNS is failing with cluster resource set to require DNS.
Resolution 1: Correct the DNS problems.
Issue 2: A duplicate name is on the network.
Resolution 2: Use NBTSTAT to find the duplicate name and then correct the issue.
Issue 3: SQL Server is not connecting using Named Pipes.
Resolution 3: To connect using Named Pipes, create an alias using the SQL Server Configuration Manager to connect to
the appropriate computer. For example, if you have a cluster with two nodes (Node A and Node B), and a failover cluster
instance (Virtsql) with a default instance, you can connect to the server that has the Network Name resource offline using
the following steps:
1.

Determine on which node the group containing the instance of SQL Server is running by using the Cluster
Administrator. For this example, it is Node A.

2.

Start the SQL Server service on that computer using net start. For more information about using net start,
see Starting SQL Server Manually.

3.

Start the SQL Server SQL Server Configuration Manager on Node A. View the pipe name on which the server is
listening. It should be similar to \\.\$$\VIRTSQL\pipe\sql\query.

4.

On the client computer, start the SQL Server Configuration Manager.

5.

Create an alias SQLTEST1 to connect through Named Pipes to this pipe name. To do this, enter Node A as the
server name and edit the pipe name to be \\.\pipe\$$\VIRTSQL\sql\query.

6.

Connect to this instance using the alias SQLTEST1 as the server name.

Problem: SQL Server Setup fails on a cluster with

error 11001
Issue: An orphan registry key in [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.X\Cluster]
Resolution: Make sure the MSSQL.X registry hive is not currently in use, and then delete the cluster key.

Problem: Cluster Setup Error: "The installer has insufficient privileges to access this directory:
<drive>\Microsoft SQL Server. The installation cannot continue. Log on as an administrator or contact
your system administrator"
Issue: This error is caused by a SCSI shared drive that is not partitioned properly.
Resolution: Re-create a single partition on the shared disk using the following steps:
1.

Delete the disk resource from the cluster.

2.

Delete all partitions on the disk.

3.

Verify in the disk properties that the disk is a basic disk.

4.

Create one partition on the shared disk, format the disk, and assign a drive letter to the disk.

5.

Add the disk to the cluster using Cluster Administrator (cluadmin).

6.

Run SQL Server Setup.

Problem: Applications fail to enlist SQL Server

resources in a distributed transaction
Issue: Because the Microsoft Distributed Transaction Coordinator (MS DTC) is not completely configured in Windows,
applications may fail to enlist SQL Server resources in a distributed transaction. This problem can affect linked servers,
distributed queries, and remote stored procedures that use distributed transactions. For more information about how to
configure MS DTC, see Before Installing Failover Clustering.
Resolution: To prevent such problems, you must fully enable MS DTC services on the servers where SQL Server is installed
and MS DTC is configured.
To fully enable MS DTC, use the following steps:
1.

In Control Panel, open Administrative Tools, and then open Computer Management.

2.

In the left pane of Computer Management, expand Services and Applications, and then click Services.

3.

In the right pane of Computer Management, right-click Distributed Transaction Coordinator, and
selectProperties.

4.

In the Distributed Transaction Coordinator window, click the General tab, and then click Stop to stop the
service.

5.

In the Distributed Transaction Coordinator window, click the Logon tab, and set the logon account NT
AUTHORITY\NetworkService.

6.

Click Apply and OK to close the Distributed Transaction Coordinator window. Close the Computer
Management window. Close the Administrative Tools window.

Using Extended Stored Procedures and COM Objects

When you use extended stored procedures with a failover clustering configuration, all extended stored procedures must be
installed on a SQL Server-dependent cluster disk. Doing so ensures that when a node fails over, the extended stored
procedures can still be used.
If the extended stored procedures use COM components, the administrator must register the COM components on each
node of the cluster. The information for loading and executing COM components must be in the registry of the active node
in order for the components to be created. Otherwise, the information remains in the registry of the computer on which the
COM components were first registered.

Installation of SQLserver2008 cluster fails

on windows2008.(The group or resource is
not in the correct state to perform the
requested operation. (Exception from
HRESULT: 0x8007139F)
Installation of SQLserver2008 cluster might fail on windows2008 with error mentioned below

The cluster resource SQL Server could not be brought online.

Error: The group or resource is not in the correct state to perform the requested operation. (Exception from HRESULT: 0x8007139F)

Root Cause

This problem occurs because of a new security feature named Loopback check functionality. By default, loopback check functionality is turned
ON in Windows and the value of the DisableLoopbackCheck registry entry is set to 0 (zero).
http://support.microsoft.com/kb/957097/

With this feature being turned ON: windows do not allow NTLM authentication if we try to access server from Local server using a name which
is not its Net-Bios name (or) IPAddress.

When SQL Server Agent is started, SQL Agent resource access the SQL Server using SQL VirtualServer name and hence we do not allow
NTLM. So the SQL Server Agent would fail and the SQLServer Agent Resource creation would also fail.

SQL Server resource will fail to come Online because, IsAlive check will be done using NTLM Authentication i.e: Cluster service startup account
resolves as NT AUTHORITY\ANONYMOUS LOGON when connecting to SQL Server for IsAlive check and the connection fails.

We will not get in to this issue if startup account of SQL Server has permissions to read and write SPNs.

After the installation fails you will see the SQL Server resource is created but not the SQL Agent resource.

There are three ways to resolve this issue.

Option 1

1. After the failure, create the SPNs manually using SetSPN tool (or) Configure SQL Server service to create SPNs dynamically for the SQL
Server instances (Refer KB: 811889)

Example for creating SPNs manually:

SETSPN -A MSSQLSVC/VSName.XX.XX.EDU:1433
SETSPN -A MSSQLSVC/VSName.XX.XX.EDU

2. Bring the SQL Server Resource online.

3. Create the SQL Server Agent resource type.

{
To add the sql server agent resource type execute the below command:

cluster restype SQL Server Agent /create /DLL:sqagtres.dll .Once done we got the
update that the Resource type SQL Server Agent created.
}

4. Create SQL Server agent resource manually.

We need to make sure that the newly created SQL server Agent resource have the virtualservername and Instance name .

To add this property go to failover cluster management ==>SQL Server Agent Resource==>Properties==>properties
check for the two parameters (virtualservername and Instancename) and fill in the
details.

5. Change configuration reg_dword values of all components to 1 in below registry path

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQLX.MSSQLSERVER\ConfigurationState

Option 2

1. Do a Complete uninstall of failed installation (or) Configure SQL Server service to create SPNs dynamically for the SQL Server instances
(Refer KB: 811889) and move to Step 3.

2. Create the SPNs before we do the installation.

Example:
SETSPN -A MSSQLSVC/VSName.XX.XX.EDU:1433
SETSPN -A MSSQLSVC/VSName.XX.XX.EDU

Note:Beginning with SQL Server 2008, the SPN format is changed and new SPN format does not require a port number
Refer:http://msdn.microsoft.com/en-us/library/ms191153.aspx

3. Then install the SQL Server on cluster

Option 3 (Recommended)

1. Disable the authentication loopback check by setting the DisableLoopbackCheck value in

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa registry subkey to 1.
To set the DisableLoopbackCheck registry entry to 1, follow below steps on all nodes of cluster.

a. Click Start, click Run, type regedit, and then click OK.
b. Locate the following registry path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
c. Right-click Lsa, select New, and then click DWORD Value.
d. Type DisableLoopbackCheck, and then press ENTER.
e. Right-click DisableLoopbackCheck, and then click Modify.
f. In the Value data box, type 1, and then click OK.

2. Restart the system.

3. Do complete uninstall and re-run the setup(or) Follow the steps from step2 in option 1.

Note:

1. We will encounter above error if we are installing the named instance of SQL Server and SQL Server browser is in stopped state.

2. If you have installed SQLServer 2012 (Denali) and uninstalled it on same cluster. You might encounter above issue. Refer below link for
details.

http://mssqlwiki.com/2012/01/31/sql-server-resource-fails-to-come-online-is-alive-check-fails/

Installation of SQLServer2005/2008/2012
Fails on Windows2008 Cluster.
Installation of SQLServer2005/20082012 on Windows2008/2012 Cluster might fail with error mentioned below

Erorr1

The following error has occurred:

The cluster resource SQL Server could not be brought online due to an error bringing the dependency resource SQL Network Name ( )
online. Refer to the Cluster Events in the Failover Cluster Manager for more information.

Click Retry to retry the failed action, or click Cancel to cancel this action and continue setup.

For help, click: http://go.microsoft.com/fwlink?LinkID=20476&ProdName=Microsoft%20SQL

%20Server&EvtSrc=setup.rll&EvtID=50000&ProdVer=11.0.3128.0&EvtType=0xE8049925%25400x42B4DED7

Erorr2:

The cluster identity cLUSTER$nAME 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 SCLUSTERNAME$ has Full Control permission to that computer object
using the Active Directory Users and Computers tool.
ERR [RES] Network Name <SQL Network Name (VSServerName)>: Computer account VSServerName couldnt be re-enabled. status 5
INFO [NM] Received request from client address ASPMB9000D05N1.
INFO [NM] Received request from client address ASPMB9000D05N1.
ERR [RHS] Online for resource SQL Network Name (VSServerName) failed.
INFO [RCM] HandleMonitorReply: ONLINERESOURCE for SQL Network Name (VSServerName), gen(2) result 5018.
INFO [RCM] TransitionToState(SQL Network Name (VSServerName)) OnlinePending>ProcessingFailure.
ERR [RCM] rcm::RcmResource::HandleFailure: (SQL Network Name (VSServerName))
ERR [RES] Network Name <SQL Network Name (VSServerName)>: Unable to create computer account VSServerName on DC \\ay.xz.dc, in
default Computers container, status 5

Cause

When you create a new clustered network name, a computer object (computer account) for that clustered service or application must be
created in the Active Directory domain.

This computer object is created by the computer object of the cluster itself. This computer abject of the cluster is responsible for creating the
computer object for "SQL Virtual Server" in active directory . If the computer object of the cluster itself does not have the appropriate
permissions, it cannot create or update the computer object for "SQL Virtual Server" . So the installation of SQL Server would fail.

To resolve this issue Grant "Create Computer Objects" permission for the computer object created for the cluster (Computer Name
object(CNO)).

For additional info on this Refer: http://technet.microsoft.com/en-us/library/cc773451(WS.10).aspx

SQLServer 2008 Fails to come online on

cluster after upgrade
SQL-Server 2008 Fails to come online on cluster after upgrade.

Reason:

Server is in script upgrade mode. Only administrator can connect at this time.

Login failed for user ccccc\xxxxx. Reason: Server is in script upgrade mode. Only administrator can connect at this time.

Issue:

SQL-Server 2008 Fails to come online on cluster after upgrade.

Error from SQL-Server Error log

Reason: Server is in script upgrade mode. Only administrator can connect at this time.

Login failed for user ccccc\xxxxx. Reason: Server is in script upgrade mode. Only administrator can connect at this time.

Script level upgrade for database master failed because upgrade step sqlagent100_msdb_upgrade.sql encountered error 598, state 1,
severity 25. This is a serious error condition which might interfere with regular operation and the database will be taken offline. If the error
happened during upgrade of the master database, it will prevent the entire SQL Server instance from starting. Examine the previous Error
log entries for errors, take the appropriate corrective actions and re-start the database so that the script upgrade steps run to completion.

Resolution:

Start the SQLServer from services console (or) Command prompt and wait till the master database is completely upgraded.
Once the script upgrade is complete start the SQL-Server normally from Cluster admin (or) Failover cluster manager.

Cause: During the Script upgrade mode only administrator can connect to SQL-Server, So when the SQL-Server resource is brought online
ISAlive check fails immediately before upgrade completes and SQL-Server resource goes down. When we start SQLServer from services or
command prompt ISAlive check doesnt happen so upgrade completes. Once the upgrade is completed we can start SQL-Server normally.

SQL Server2008/SQL Server2012: Script

level upgrade for database master failed
because upgrade step
sqlagent100_msdb_upgrade.sql
encountered error 574, state 0, severity 16
SQL Server 2008 : Script level upgrade for database master failed because upgrade step sqlagent100_msdb_upgrade.sql encountered error
574, state 0, severity 16

SQL Server 2012 : Script level upgrade for database master failed because upgrade step msdb110_upgrade.sql encountered error

SQL Server 2008/2012 instance fails to start or hangs after service pack or Cumulative update installation.

Error

Script level upgrade for database master failed because upgrade step sqlagent100_msdb_upgrade.sql encountered error 574, state 0,
severity 16. This is a serious error condition which might interfere with regular operation and the database will be taken offline. If the error
happened during upgrade of the master database, it will prevent the entire SQL Server instance from starting. Examine the previous errorlog
entries for errors, take the appropriate corrective actions and re-start the database so that the script upgrade steps run to completion.

Error: 574, Severity: 16, State: 0.

CONFIG statement cannot be used inside a user transaction.

Error: 912, Severity: 21, State: 2.

Script level upgrade for database master failed because upgrade step sqlagent100_msdb_upgrade.sql encountered error 574, state 0,
severity 16. This is a serious error condition which might interfere with regular operation and the database will be taken offline. If the error
happened during upgrade of the master database, it will prevent the entire SQL Server instance from starting. Examine the previous errorlog
entries for errors, take the appropriate corrective actions and re-start the database so that the script upgrade steps run to completion.

Error: 3417, Severity: 21, State: 3.

Script level upgrade for database master failed because upgrade step msdb110_upgrade.sql encountered error 15173, state 1, severity 16

Start SQL Server from command prompt using trace flag T902 to disable script execution

1.Turn off Implicit transaction

EXEC sys.sp_configure Nuser options, N0

GO

RECONFIGURE WITH OVERRIDE

GO

2. SQL Server not able to create temp_MS_AgentSigningCertificate_database.mdf

Error:

Directory lookup for the file "P:\Data\temp_MS_AgentSigningCertificate_database.mdf" failed with the operating system error 2(The system
cannot find the file specified.).

Error: 1802, Severity: 16, State: 1.

CREATE DATABASE failed. Some file names listed could not be created. Check related errors.

spid7s Error: 912, Severity: 21, State: 2.

spid7s Script level upgrade for database master failed because upgrade step sqlagent100_msdb_upgrade.sql encountered error 598, state
1, severity 25.

CREATE FILE encountered operating system error 3(The system cannot find the path specified.) while attempting to open or create the
physical file Q:\Data\temp_MS_AgentSigningCertificate_database_log.LDF.

This error is raised when the default database location is invalid. Edit below registry to have a valid directory for default database location.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL10.<Instance Name>\Setup\SQLDataRoot

3. Check if there are Orphan users in system databases and fix them.

EXEC sp_change_users_login Report;

4. If you see error 15173, state 1, severity 16

Ex: Script level upgrade for database master failed because upgrade step msdb110_upgrade.sql encountered error 15173, state 1, severity
16

Revoke the permissions granted on ##MS_PolicyEventProcessingLogin##

you can use the below script to identify the users who have permissions granted on ##MS_PolicyEventProcessingLogin##

select a.name,b.permission_name from sys.server_principals a,sys.server_permissions b,sys.server_principals c

where a.principal_id= b.grantee_principal_id and b.grantor_principal_id=c.principal_id and c.name = ##MS_PolicyEventProcessingLogin##

Resolution

If none of the above resolves the issue then you can use Trace flag -T3601 which causes the first 512 characters of each batch
being executed to be printed to the error log. Identify the batch which is failing and troubleshoot the batch.

Unable to start SQLServer agent resource

on cluster after upgrading to 9.00.3186
or Higher
SQLServer agent resource fails to come online on cluster after upgrading to build
9.00.3186 or Higher

Error

2008-03-19 23:06:23 ? [100] Microsoft SQLServerAgent version 9.00.3186.00 (x86

unicode retail build) : Process ID 2428
2008-03-19 23:06:23 ? [101] SQL Server SNETNAME version 9.00.3186 (0 connection
limit)
2008-03-19 23:06:23 ? [102] SQL Server ODBC driver version 9.00.3042
2008-03-19 23:06:23 ? [103] NetLib being used by driver is DBNETLIB.DLL; Local
host server is
2008-03-19 23:06:23 ? [310] 4 processor(s) and 2560 MB RAM detected
2008-03-19 23:06:23 ? [339] Local computer is SNETNAME running Windows NT 5.2
(3790) Service Pack 2
2008-03-19 23:06:23 ? [432] There are 11 subsystems in the subsystems cache
2008-03-19 23:06:38 ! [364] The Messenger service has not been started NetSend
notifications will not be sent
2008-03-19 23:06:38 ? [129] SQLSERVERAGENT starting under Windows NT service
control
2008-03-19 23:06:38 + [260] Unable to start mail session (reason: No mail profile
defined)

2008-03-19 23:06:38 + [396] An idle CPU condition has not been defined OnIdle
job schedules will have no effect
2008-03-19 23:06:38 + [408] SQL Server MSSQLSERVER is clustered AutoRestart has
been disabled
2008-03-19 23:06:39 ! [298] SQLServer Error: 22022, CryptUnprotectData() returned
error -2146893813, Key not valid for use in specified state. [SQLSTATE 42000]
2008-03-19 23:06:39 ! [442] ConnConnectAndSetCryptoForXpstar failed (0).
2008-03-19 23:06:40 ? [098] SQLServerAgent terminated (normally)
Error2

2008-03-18 12:18:30 ? [100] Microsoft SQLServerAgent version 9.00.3200.00

((Unknown) unicode retail build) : Process ID 6512
2008-03-18 12:18:30 ? [101] SQL Server PISTONDIST version 9.00.3200 (0 connection
limit)
2008-03-18 12:18:30 ? [102] SQL Server ODBC driver version 9.00.3042
2008-03-18 12:18:30 ? [103] NetLib being used by driver is DBNETLIB.DLL; Local
host server is np:pistondist
2008-03-18 12:18:30 ? [310] 16 processor(s) and 32765 MB RAM detected
2008-03-18 12:18:30 ? [339] Local computer is PISTONDIST running Windows NT 5.2
(3790) Service Pack 2
2008-03-18 12:18:31 ? [432] There are 11 subsystems in the subsystems cache
2008-03-18 12:18:31 ! [364] The Messenger service has not been started NetSend
notifications will not be sent
2008-03-18 12:18:31 ? [129] SQLSERVERAGENT starting under Windows NT service
control
2008-03-18 12:18:32 + [396] An idle CPU condition has not been defined OnIdle
job schedules will have no effect
2008-03-18 12:18:32 + [408] SQL Server MSSQLSERVER is clustered AutoRestart has
been disabled
2008-03-18 12:18:32 + [162] Internal request (from SetJobNextRunDate [reason:
schedule will not run again]) to deactivate schedule 66
2008-03-18 12:18:32 ! [298] SQLServer Error: 22022, CryptUnprotectData() returned
error -2146892987, The requested operation cannot be completed. The computer must
be trusted for delegation and the current user account must be configured to allow
delegation. [SQLSTATE 42000]

2008-03-18 12:18:32 ! [442] ConnConnectAndSetCryptoForXpstar failed (0).

2008-03-18 12:18:33 ? [098] SQLServerAgent terminated (normally)

Resolution

Modify the the following Key.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.X\SQLServerAgent
Modify the value data of the serverhost key to np:Virtualservername

Ie:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL
Server\MSSQL.X\SQLServerAgent
ServerHost
Value: np:Virtualservername.

This will force the SQLServer agent to connect with SQLserver using Named Pipes so
delegation is not used.

We have a HOTFIX available for this issue and it is included in the cumulative update pack9 for SQLServer service
pack2. http://support.microsoft.com/?id=956378
Note: Before applying the Hotfix. you have to follow the steps mentioned in Resolution else hotfix would fail. Revert the steps after applying
the fix.

A failure was detected for a previous

installation, patch, or repair during
configuration for features
[SQL_PowerShell_Engine_CNS,SQL_Power
Shell_Tools_ANS]. In order to apply this
patch package (KB968369), you must
resolve any issues with the previous
operation that failed.
Installation of SQL Service Pack 1 (or) Cumulative Pack for SQL Server 2008 it fails with the below error message

A failure was detected for a previous installation, patch, or repair during configuration for features
[SQL_PowerShell_Engine_CNS,SQL_PowerShell_Tools_ANS,XXXX,XXXXX]. In order to apply this patch package (KB968369 XYZ), you must
resolve any issues with the previous operation that failed.

Look at the Sub-keys for below registry keys and check if Value 2 is set for any components.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\100\ConfigurationState

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSAS10.XY1\ConfigurationState

Replace MSAS10.XY1 with your instance

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL10_50.KJ\ConfigurationState

Replace MSSQL10_50.KJ with your instance

Run the Repair for existing setup. Values for all the sub keys will change to 1 after the successful repair.

Re-start the Service pack installation.

SQL-Server resource fails to come online IS

Alive check fails
SQL-Server resource fails to come online with
below Error:
[sqsrvres] checkODBCConnectError: sqlstate = 08001; native
error = 35; message = [Microsoft][SQL Server Native
Client 11.0]A network-related or instance-specific error has
occurred while establishing a connection to SQL Server. Server
is not found or not accessible.
Check if instance name is correct and if SQL Server is
configured to allow remote connections. For more information
see SQL Server Books Online.

Resolution:

Look at the version of

(c:\windows\system32\sqsrvres.dll) and
install the same version of SQL Server
native client.
Cause:

When Higher version of SQL-Server is

installed on a cluster in which lower version
of SQL Server is already installed, the lower
version SQL Server Resource DLL
(c:\windows\system32\sqsrvres.dll) is
upgraded to higher version and Higher
resource DLL will be loaded by the resource
monitor process to monitor Lower version as
well.
For example: The Denali SQL Server
Resource uses SNAC 11.0 to connect to the
SQL instance and because SNAC 11.0 can be
used to connect to Shiloh, Yukon and Katmai
as well this side by side configuration will
work. However if Denali is uninstalled, the
Denali SQL Server resource DLL is not
downgraded to Katmai, Yukon or Shiloh
version and hence care should be taken to
not uninstall SNAC 11.0 otherwise Yukon or
Shiloh instance cannot be brought online.
Similarly When we install Yukon and Shiloh together, Yukon
SQL Server Resource uses SNAC to connect to the SQL
instance and because SNAC can be used to connect to
Shiloh as well this side by side configuration will work.
However if Yukon is uninstalled, the Yukon SQL Server
resource DLL is not downgraded to Shiloh version and

hence care should be taken to not uninstall SNAC otherwise

Shiloh instance cannot be brought online.