Error: Create Availability Group Listener failed


Today I tried to create an AlwaysOn Availability Group. Everything went fine until I configured the Availability Group Listener.

It failed with the error message:

Create failed for Availability Group Listener <ListenerName>.
Microsoft SQL Server, Error 19471.


The Windows Application Event Log is a little bit more helpful on that:

Cluster network name resource <ClusterName> failed to create its
associated computer object in domain. [...]
verify that the Cluster Identity <ClusterName> has 'Full Control' permission
to that computer object using the Active Directory Users and Computers tool.


There we go.


If you have the rights in your domain to do so, just help yourself out of this, otherwise you have to contact your Domain Administrator to help you.

On your Domain Controller:

  • Open “Active Directory Users and Computers”
  • In menu “View” check “Advanced Features” to be able to find the OU where your Cluster object is located in.
  • On the root of your domain right click and choose “Find…”
  • In drop down meny “Find” select “Computers”
  • In the text box for “Computer name” type your Cluster name and click button [ Find Now ]
  • View the “Properties” of your Cluster object that was found.
  • On tab “Object” you will find the location (OU) where your Cluster object is located in.
  • Close all popups.
  • Navigate to the location you just figured out, perform a right click and choose “Properties”.
  • In tab “Security” click the button [ Add… ]
  • Click the button [ Object Types… ] , mark the checkbox next to “Computers” and leave the popup with a click on [ OK ].
  • In the textbox enter the name of your Cluster, check the name and leave the popup with a click on button [ OK ].
  • In the field for the permissions mark the check box for “Full control” and click Apply.
  • Leave the Dialog open.


Go to SQL Server Management Studio and repeat the attempt to create the Availability Group Listener.

Go back to the Domain Controller (or ask your Domain Admin to do so) and remove the “Full control” permission for the Cluster.

Article from:

Error: SQL AlwaysON Listener The WSFC cluster could not bring the Network Name resource with DNS name ‘LNSxxxx’ online.

Problem: When creating a Listener for an AlwaysOn Availability group, I received the below error:

Msg 19471, Level 16, State 0, Line 1

The WSFC cluster could not bring the Network Name resource with DNS name ‘LNSxxx’ online. The DNS name may have been taken or have a conflict with existing name services, or the WSFC cluster service may not be running or may be inaccessible. Use a different DNS name to resolve name conflicts, or check the WSFC cluster log for more information.

Msg 19476, Level 16, State 4, Line 1

The attempt to create the network name and IP address for the listener failed. The WSFC service may not be running or may be inaccessible in its current state, or the values provided for the network name and IP address may be incorrect. Check the state of the WSFC cluster and validate the network name and IP address with the network administrator.

The AlwaysOn Availability group had created cleanly, with the exception of the listener.

The cluster error log showed:

Cluster network name resource ‘AG****’ failed to create its associated computer object in domain ‘’ for the following reason: Unable to create computer account.

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

Please work with your domain administrator to ensure that: – The cluster identity ‘*****$’ 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 ‘****$’ has ‘Full Control’ permission to that computer object using the Active Directory Users and Computers tool.


The error message from the cluster was the most useful. In my case, computer objects were forwarded to a holding OU and were not located in the Computers OU. I gave the computer account full permissions to the OU, and re-ran the TSQL to create the listenet.

Nb – Full permissions is not a best practice –  documentation suggests that the computer account requiires create computer & delete computer permissions.

Article from:

Error: When Creating a New Resource or Role in Windows Server 2012 R2 Failover Cluster, the Network Name Fails to Come Online or Failed to Create Associated Computer Object in Domain

There is an issue I have seen repeatedly in the field since Windows Server 2012 and Windows Server 2012 R2 released. It typically surfaces when attempting to add roles to Windows Failover Cluster. Since my customers are large SQL shops, this issue typically surfaces when the server team hands off the Windows Server 2012 R2 Cluster nodes to the SQL team and the SQL team attempts to install SQL Server Failover Cluster and gets this:

Microsoft SQL Server 2012 Service Pack 1 Setup

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

SQL Server Setup Error

If you check out the event logs, you’ll see the following:

Event ID: 1194
Source: Microsoft-Windows-FailoverClustering
Cluster network name resource ‘SQL Network Name (SQLSHARE3VS)’ failed to create its associated computer object in domain ‘’ for the following reason: Resource online.

The associated error code is: -1073741790

Please work with your domain administrator to ensure that:

– The cluster identity ‘2012SQL3FailoverCluster$’ 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 ‘2012SQL3FailoverCluster$’ has ‘Full Control’ permission to that computer object using the Active Directory Users and Computers tool.

At this point, the SQL team (or even before this point) punts it back to the server team. The server team scratches their head, mumbles something about this working in Windows Server 2008 R2, and typically opens a case with Microsoft.

So what changed?

In Windows Server 2012 R2, we added a new feature that was high in demand. We now have the ability to specify an OU during Create Cluster Wizard. That way the Cluster Name Object (CNO) can be created in some OU other than the default Computers container.  Additionally, if you move the computer objects for the servers to a different OU, when you create the Cluster, even if you do not specify an OU during creation, the CNO will be created in the same OU where the server computer objects reside instead of the default Computers container. 

Let’s take a step back for a minute

What is the Cluster Name Object (CNO)? When you create a failover cluster by using the Create Cluster Wizard, you must specify a name for the cluster. If you have sufficient permissions when you create the cluster, the cluster creation process automatically creates a computer object in AD that matches the cluster name. This object is called the cluster name object or CNO. It is also what we use to administer the Cluster as a single unit. These can also be prestaged.

Great. So what’s the Virtual Computer Object (VCO)? The VCO is also a computer object that is automatically created when you configure any Cluster roles that have an associated client access point. A client access point is nothing more than an IP address and network name. Again, the network name is associated with a computer object in AD. For example, if you setup a file server and call the role FileServer1, you will have a computer object in AD directory called FileServer1. The CNO is responsible for creating these. When the CNO is automatically created, we assign it the appropriate permissions in order to be able to do so. If we’re prestaging or manually creating these, then we rely on the AD admin to follow the TechNet documentation and assign the appropriate permissions.

Most roles require a client access point. So most roles are going to have a corresponding computer object in Active Directory.

Let’s take a look at what this looks like in AD.  My two servers that will be my two Cluster nodes are named Node1 and Node1. I probably should have used more descriptive computer names for my Cluster nodes, but whatever. I use the KISS principle in my lab environments…but even I must admit, that’s a little too simplistic. 🙂 After building them, per typical policy, I moved them from the default Computers container to the SQL OU as their end function will be SQL servers.

After installing the Failover Cluster feature on both nodes and running validation, I create my Cluster. At this point in the Create Cluster Wizard, I can actually specify an OU if I wanted to, but I’m just going to do what I see in the field and specify the Cluster name.

When I click Next and Finish, at this point, we form the Cluster and the CNO is created in Active Directory. So if I pop back over to my SQL OU, I see that my CNO followed the computer accounts for my two nodes and also resides in the SQL OU.

Notice the CNO is the same name I specified for the Cluster. Any roles I setup for this Cluster will have VCO objects created in this same location.

To summarize:

  • We create a computer object in Active Directory whenever we setup the Cluster. This is the CNO.
  • We create a computer object in Active Directory whenever we create a role that requires a client access point (most roles). This is the VCO.
  • VCOs follow the CNO. Whichever OU the CNO is in is where the VCOs will be created.

Crystal clear right? I hope so. This has been a confusing point for many of the classes I have taught and many of my customers, especially those that do not touch AD.

So what’s the problem?

By default whichever OU you move the CNO to does not have the appropriate permissions for the CNO to create the VCO and you’ll see the errors described at the beginning of this blog or you’ll simply fail to see the resource come online. On closer investigation, you’ll see the network name failed as shown below:

If you go look in Active Directory, you’ll notice that the computer object or VCO was never created for my MSDTC resource pictured above. There should be a VCO by the name of SQL1MSDTC, but no such object exists in AD. It was never created because the CNO did not have the appropriate permissions to create it.

But wait, I thought you said the CNO was automatically granted the permissions to create the VCOs?

Correct, that is the case. On the CNO itself, we give it the right permissions automatically. However, we change nothing at the OU level. In order for the CNO to create the VCOs in a custom OU, we either need to prestage the VCOs (see: for instructions on how to do so) or we need to grant the CNO permissions to Create Computer objects at the OU level.

To do this, we do the following (these are straight from the TechNet document linked above):

  1. In Active Directory Users and Computers, on the View menu, make sure that Advanced Features is selected.
  2. Right-click the OU where you created the CNO in Step 1: Prestage the CNO in AD DS, and then click Properties.
  3. On the Security tab, click Advanced.
  4. In the Advanced Security Settings dialog box, click Add.
  5. Next to Principal, click Select a principal.
  6. In the Select User, Computer, Service Account, or Groups dialog box, click Object Types, select the Computers check box, and then click OK.
  7. Under Enter the object names to select, enter the name of the CNO, click Check Names, and then click OK. In response to the warning message that says that you are about to add a disabled object, click OK.
  8. In the Permission Entry dialog box, make sure that the Type list is set to Allow, and the Applies to list is set to This object and all descendant objects.
  9. Under Permissions, select the Create Computer objects check box.

After I do this, the next time I start my SQL1MSDTC role, everything comes online as expected.

If we peak at AD again, you can see the SQL1MSDTC VCO computer object is now created:


You might be wondering why we’re having to do this on Windows Server 2012 R2 when we didn’t with Windows Server 2008 and 2008 R2. The CNOs have always needed this right. However, 2008 and 2008R2 clusters created its objects in the default Computers container, even if the CNO was moved to a different OU, when you formed the Cluster, etc., it still defaulted to the default Computers container where every object has rights to create computer objects by default.

2012 and 2012R2 clusters create the objects in the same OU as where the nodes. For example, the SQL OU depicted above.  Since it is not the default Computers container, then we have to add the rights separately. Neither has changed in the fact that the rights had to be there, it’s just everyone normally has rights to create in the default Computers container as a default, but do not have those permissions in custom OUs.

Now, obviously you don’t want to add each and every individual CNO for all the Clusters you create to the OU one at a time. The easiest method to solve this is to create a security group that has the Create Computer Objects permission at the OU level. When building a new Cluster, add the Cluster name (CNO) to the group. For example, I created a FailoverCluster security group and went through the same process to grant it Create Computer Objects permission on my SQL OU:

Article from:

Proper rights to create Failover Cluster

Rights needed for user account to create a Cluster Name Object (CNO) on Windows Server 2008 R2 Failover Cluster

A CNO is automatically created during cluster setup. When the administrator creates a failover cluster and configures clustered services or applications, the Create Cluster Wizard creates all the Active Directory computer accounts the failover cluster requires and gives each account specific permissions. The wizard also creates a computer account for the failover cluster itself; this account is called the cluster name object.

Question: What permissions do accounts used by failover clusters in Windows Server 2008 need?

Answer: The account used to create the cluster must have administrator rights on the computers that are becoming part of the new cluster and the Create Computer Objects permission on the container where computer accounts are created in the domain. This is because the wizard that creates failover clusters creates the computer account for the new cluster and gives that account the necessary permissions, such as creating computer objects in the domain’s computer account container (which lets the cluster create additional computer accounts for any clustered services or applications).

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.





As discussed in previous blogs and articles, there is no longer a Cluster Service account in Failover Clustering. However, there are still some rights needed in Active Directory. The rights of the logged on user and the Cluster Name Object are part of these rights. This blog is only going to cover the rights of the logged on user.

Cluster Validation is a subset of tests that are run to verify the Failover Cluster is going to both be supported or if there are configuration issues that need to be corrected. For the purposes of this blog, I want to discuss the single test of “Validate Active Directory Configuration” under System Configuration. What this is going to do is validate the logged on user can create accounts in Active Directory. When creating a Failover Cluster, it is going to use the current logged on user to create the Cluster Name Object (CNO). Therefore, it must have the rights to do it. If it does not, you will see the below in the Validation Report.

Validate Active Directory Configuration

Validate that all the nodes have the same domain, domain role, and organizational unit.

The user running validate, does not have permissions to create computer objects in the “x” domain.

To successfully create a cluster either, the installer must have the privileges needed to create computer objects in the default container for computers, or a computer object must be pre-created by a domain administrator.

The user creating the cluster requires the ‘Create Computer Object’ permission on the container where computer objects are created in the domain. If the default container has been modified, then this privilege will need to be granted to the user for the new container.

If a pre-existing computer object is used, please ensure that the computer object is in a Disabled state and that the user creating the cluster has ‘Full Control’ permission to that computer object using the Active Directory Users and Computers tool prior to creating the cluster.


If you were to not run Validation and try to create a Failover Cluster, you would receive this error if the account does not have the proper permissions.


As we discussed, we are using the logged on user to create the computer object. So we must look at the rights that the logged on user has. As per our documentation on the rights needed, we say this.

Steps for configuring the account for the person who installs the cluster

Membership in the Domain Admins group, or equivalent, is the minimum required to complete this procedure. In addition, your account must be in the local Administrators group on all of the servers that will be nodes in the failover cluster.

Now, there are numerous organizations that do not have Domain Administrators create Failover Clusters. So the question becomes, exactly what is the “equivalent” rights that are needed for this user. Below are the rights that are needed in the OU.

o Create Computer Objects

o Read All Properties

With the above rights, Cluster Validation will pass and the Cluster object can be created.

Article from:

How to Install a Clustered SQL Server 2012 Instance

Part 1

In this series, I will demonstrate how to install a SQL Server 2012 clustered instance in a cluster of two nodes. In general, the installation will be done in two parts:

  1. New instance installation in one of the nodes.
  2. Add the other node to the existing clustered instance.

For a cluster with more than two nodes, we would need to perform the first step in one of the nodes, and repeat the second step on all other nodes. What is a clustered instance? Basically, a clustered instance is a SQL Server instance installed over a Windows Failover Cluster (WFC) service. The main purpose of a WFC solution is protect our systems from hardware failures. In a scenario of a cluster with two nodes, we are talking about two servers, with similar hardware configuration, connected by a Failover Cluster service. Having one SQL Server instance installed over this solution, we can call this instance as a clustered instance. That clustered instance must be active in only one of the available nodes, and this means that the other nodes will be in IDLE mode, with no active functions. Another important point is that the WFC accepts shared storage, which means that we need a SAN to store thedatabase files (logs and data). However, the SQL Server binaries generated by the installation should be in a local disk. Other than shared storage, we also have an option to store our database files into a SMB Fileshare, which is cheaper, but not as good as a solution using SAN. From SQL Server 2012 we have an option to store the TempDB isolated in a local disk, which brings lots of benefits. This way, the WFC is a high availability solution and not a load balancing or a disaster recovery solution. We can reach this by having an AlwaysOn configuration, available from SQL Server 2012. Assumption I’m assuming that at this point we already have a built cluster solution with two or more nodes. Normally, the DBA receives the environment ready to install the clustered instance. The WFC build is usually made by the System Administrators. However, I’m planning on doing another article explaining how to configure a WFC solution. Stay tuned! Prerequisites Before we start the installation, we need to assure that we have the following items ready to be used:

  • A virtual hostname. In our example we will use “SQL04”.
  • A virtual IP, a.k.a vIP. We will use:
  • Available shared storage. The best practice is have, at least, one for Data files (mdf and ldf), one for Log files (ldf) and one for Tempdb files. On this guide I will use one disk for everything, to simplify, but this is a bad approach!
  • Service Accounts: One for SQL Server Engine and another for SQL Server Agent (this is the best practice). We will use the following accounts: SSLAB\SVCSQLSRVENG and SSLAB\SVCSQLAGT.
    • Notice that the service accounts are domain accounts. We have no other choice, to build a cluster we need to be part of a domain!

Our Environment On this step-by-step guide, we will use the following environment – based in virtual machines:

  • Windows Server 2012 R2 nodes:
    • W2012SRV03 –
    • W2012SRV04 –
  • The both nodes are part of the following cluster:
    • W2012CLT02 –
  • Storage:
    • As this is a lab, I’m using a Synology Diskstation as my SAN. Just for information, the IP is:
  • For SQL Server:
    • vHostname – SQL04
    • vIP –
    • Version: Microsoft SQL Server 2012 (SP1) – 11.0.3128.0 (X64)  –  Enterprise Edition

    Screen Shot 2013-12-12 at 12.03.53

Installation Permissions for the used login To install the SQL Server I’m using the domain login called “SSLAB\dba”, which is part of the Administrators group on W2012SRV03 and W2012SRV04. The login “SSLAB\dba” is a simple user into the domain, without special permissions.

Part 2

In continuation of our series on how to install a SQL Server 2012 clustered instance, let´s begin the actual installation, starting from the first node.
The objective of this second blog post in my series of three is to demonstrate how to install the first node of a clustered SQL Server 2012 instance and how to basically manage it from the Failover Cluster Manager tool, on Windows Server 2012 R2.

Just to refresh our memory, this is our infrastructure:

Screen Shot 2013-12-12 at 12.03.53

For more details about the prerequisites and a general explanation, check out Part 1 of this series.

The installation:  Starting from the very first node
So let’s start the installation. If you remember, I mentioned that we have two steps to complete the installation on both nodes. For now we will start doing the new instance installation in one of the nodes. This node will be W2012SRV03.

  1. With the SQL Server installation binaries available, click “Setup”:Screen Shot 2013-12-09 at 12.38.54
  2. The SQL Server Installation Center will open. Click “Installation” in the left menu, then select “New SQL Server Failover Cluster Installation”:Screen Shot 2013-12-09 at 12.39.28
  3. A check will run in order to find possible constraints when installing the SQL Server Setup support files. At the end of the check, click “OK”:Screen Shot 2013-12-09 at 16.22.39
  4. Now the installation will check for available updates, I recommend that you include those updates into the installation. Click “Next”:Screen Shot 2013-12-09 at 16.23.21
  5. At this step, the setup support files will be extracted and installed, click  “Install”:Screen Shot 2013-12-09 at 16.25.48
  6. Finally, we have all the setup files installed. Another check will run in order to validate if problems might occur when SQL Server files is installed.Screen Shot 2013-12-09 at 16.26.54

    Best Practice:
    It’s recommended to have a clustered MS DTC resource, as well as a dedicated MS DTC resource dedicated to each SQL Server group.
    Here is a link to a good resource about this theme:

  7. At this step, just insert the product key and click “Next”:Screen Shot 2013-12-09 at 16.29.32
  8. Select “I accept the license terms” and click “Next”:Screen Shot 2013-12-09 at 16.30.08
  9. To install a SQL Server clustered instance, choose the first option “SQL Server Feature Installation”. Click “Next”.Screen Shot 2013-12-09 at 16.31.27
  10. Here we have few options to install on “Instance Features” and “Shared Features” sections.
    For “Instance Features” pick the “Database Engine Services” item.
    For “Shared Features” pick “Management Studio (complete)”.Another important point here is the directory that the shared tools will be installed. A good practice is have a dedicated local disk to install SQL Server related files. In the image I’m using the drive C, the same that I have my OS. This is my lab, so I advise that this is not a good practice for a productive system. Click “Next”.Screen Shot 2013-12-09 at 16.38.20
  11. At this step another check will run, this time to identify problems that might  block the setup, based on our choices of the last step. Just wait for its completion and click “Next”.Screen Shot 2013-12-09 at 16.39.02
  12. This is an important step: Here we will define the instance network name (one of our prerequisites), whether we will use a default or name instance, the Instance ID and the instance root directory.A few things to consider here:
    – On “Detected SQL Server instances and Features on this computer” section, we already have one instance installed. So I had to use a named instance and change the Instance ID to do not conflict with the existing one.
    – Based on the information above, to connect to our instance we will need to use: SQL04\\DB.
    – Another important point is the “Instance root directory”: It’s recommended to use a dedicated local disk to install the SQL Server binaries. Avoid using the system drive, a.k.a. “drive C”.Fill and verify all the points an click “Next”:Screen Shot 2013-12-09 at 16.46.40
  13. This step confirms if the disk space requirements are being met. Click “Next”:Screen Shot 2013-12-09 at 16.47.02
  14. Now this is related to the Cluster Resource Group name to be used. The installation suggests a name, but you can change it.
    This window also shows the reserved and already used Resource Group names. Change the Resource Group name if you are not satisfied with the suggestion and click “Next”:Screen Shot 2013-12-09 at 16.47.37
  15. Now the disks! Another piece of the prerequisites has been shown. At this step, we will have the information of all available storage to be used on our new clustered instance.
    As mentioned before, I have only on available disk for this guide, so let’s use this. Just select the desirable disks and click “Next”:Screen Shot 2013-12-09 at 16.50.23
  16. Do you remember the requisite of an IP? It’s time to use it! Just pick the network that you will use, unmark the DHCP column and fill the address column with the value of the IP. And… “Next”:Screen Shot 2013-12-09 at 16.56.12
  17. Here is our last requisite: Service Accounts. Fill the information about the SQL Server Engine and Agent service account (login and password).
    Note: For a clustered instance, the “Startup Type” for the services should be as “Manual”. The Cluster Service will manage this for us.
    Click “Next”.Screen Shot 2013-12-09 at 17.03.20
  18. At the same step, we have another tab where we can define the collation to be used in our database engine. By default it has “Latin1_General_CI_AS”.
    For more information about collations, click here. This can be a very important choice! If you have an special collation requirement, don’t forget to select the right one during the installation, otherwise you will have a hard work ahead to change this.Screen Shot 2013-12-09 at 17.05.59
  19. Now we need to choose the authentication mode of our instance.The options are either “Windows Authentication”, which will take benefit from domain and local server logins, or “Mixed Mode”, which accepts Domain/Windows logins as well as logins created and managed by SQL Server.If you pick “Mixed Mode” a login called “sa”, member of the “Sysadmin” role will be enabled. For this reason we need to specify the password for this login.In the box bellow, we need to add all domain/Windows users that have access to the instance and will be part of the “Sysadmin” fixed server role. You need to use the three buttons to add/remove logins from this list:Screen Shot 2013-12-09 at 17.10.25
  20. Now it’s time to define the disk strategy.This step worth an entire article — I’m using only one disk for demonstration purposes, but the recommendation is to use one isolated disk for each one of the points.
    The general rule here is: The most spread, the better!We could use a layout like the following:

    Screen Shot 2013-12-16 at 17.02.52

    The only thing that we cannot specify directly is a place to store the non-clustered indexes. This separation of the non-clustered and clustered index is a case aside.

    Points to take attention here:

    • Isolate the TempDB in a fast disk. Remember: From SQL Server 2012 we can store the TempDB in a local disk on clustered installations!
    • Place your data files in one disk and log files in another one.
    • Request the disks with an appropriate RAID level.
    • Pay attention to the partition offset and block size before the installation, even if you are using a Windows 2008+ OS.

    After consider all those points, set carefully the disks for each point and click on “Next”.

    Screen Shot 2013-12-09 at 17.10.25

  21. Here you have an option to send error reports or not. Click “Next”:Screen Shot 2013-12-09 at 17.11.40
  22. Another check will run to verify if the failover cluster installation will be blocked. After the check, click “Next”:Screen Shot 2013-12-09 at 17.12.21
  23. Here we will be able to review all chosen options. Review and click “Install”:Screen Shot 2013-12-09 at 17.12.32
  24. The installation will begin — wait for completion.Screen Shot 2013-12-09 at 17.13.21
  25. In the end you will have a confirmation about the success or not of each feature installation.
    You are done here! Click  “Close”:Screen Shot 2013-12-09 at 17.20.21

On this second part, we passed for all the steps to install the first node of a clustered instance. Of course some points will be slightly different from your environment, but here are pretty much all the steps to follow. After the completion of this installation you will need to add the other nodes to this clustered installation and you will be able to see the SQL Server “Role” created into the WFC Manager.

Dealing with Failover Cluster Manager

As we already have one node of our clustered instance installed, we will need to manage its resources using the Failover Cluster Manager tool.

  • Click on the “Windows Key”+R.
  • Write “cluadmin.msc” and click on “Ok”.
  • The Windows Failover Cluster will be opened.

Screen Shot 2013-12-17 at 12.39.52

On the image you can see two “Roles”, representing two clustered SQL Server instances. The labeled as “SQL Server (DB)” is the one that we installed (Do you remember the choice made on the step 14?).
Selecting this Role will show all the resources that are part of this clustered installation, such as IPs, Disks, etc.

At this point, we have the clustered instance installed into one node only, so we cannot do a failover yet.

To stop the SQL Server, which will stop also the SQL Server Agent, right-click over the SQL Server Engine service and do the following:

Screen Shot 2013-12-17 at 12.49.06

In other hands, to start do the following:

Screen Shot 2013-12-17 at 12.51.49
Note: When you start the SQL Server, the agent service needs to be started also. One way to reduce the number of steps is first start the Agent, this way, the SQL Server Engine will start automatically. The reason is that the SQL Server Agent is dependent of the SQL Server Engine, this way WFC will try to start the Engine service prior to start the Agent.
Another very important item are the dependencies of our SQL Server.
To check that:

  • Right-clicking the SQL Server Engine service.
  • Click on Properties.
  • Select the “Dependencies” tab.

Screen Shot 2013-12-17 at 13.11.50

This way you can see all the resources that the SQL Server Engine is dependent. Looking for our picture, if either the “Cluster Disk 1” or “SQL Server network name (SQL04)” fails, the SQL Server Engine will shutdown/failover!!
All the clustered resources can be dependent of another resource. For example, the “SQL Server network name (SQL04)” is dependent of the IP. This way, if the IP fails, the resource “SQL Server network name (SQL04)” will be offline and this will fire a SQL Server failover/shutdown.

What to take from here?

Check the dependencies and conditions on this tab, this can be useful to increase you availability rate!
As a practical example:
All the disks are important, but if the backup disk fails, we can continue with the service online, and fix the problem in background. But, if the SQL Server is dependent of this disk, we will have a failover/shutdown.

So, pay attention to this!

What’s next?

After completing the second step, we already have our instance working on a clustered environment, but we have only one available node. We will complete this series with more two parts:

  • Adding another nodes to our WFCI.
  • Configuring a dedicated MS DTC resource for our SQL Server Role.

Part 3

In continuation of our series on how to install a SQL Server 2012 clustered instance, let’s discuss how to add a node into an existing SQL Server clustered instance. The following steps are performed either to add one more node to some already installed clustered instance, or to continue the installation of a brand new clustered instance — It all boils down to the same thing. To perform this phase, you will need to have at least one node installed. In this case, we installed a new SQL Server failover instance in thePart 2 of this series.

So connect to the next node, in this case W2012SRV04, and perform the following steps:

1. Make sure that you have the same SQL Server 2012 media used to install in the other node available and execute the “Setup” binary.

Screen Shot 2013-12-09 at 12.38.542. The “SQL Server Installation Center” will be opened.

Screen Shot 2013-12-09 at 12.39.28

3. Still on “SQL Server Installation Center”, click “Installation” and select “Add node to a SQL Server failover cluster”.

Screen Shot 2013-12-09 at 22.38.41

4. A check will run in order to verify the setup support rules. Click “OK”.

Screen Shot 2013-12-18 at 14.46.07

5. Now the setup will check and install the latest updates. Keep the “Include SQL Server product updates” checked and click “Next”.

Screen Shot 2013-12-09 at 22.39.51

6. Another check will run in order to identify problems within the installation process. Click “Next”.

Screen Shot 2013-12-09 at 22.42.01

7. Insert the product key and click “Next”.

Screen Shot 2013-12-09 at 22.42.17

8. Accept the terms and click “Next”.Screen Shot 2013-12-09 at 22.42.28

9.  On this step you need to pick the instance where this installation will be related. Notice that you have a list of installed instances, as well as the nodes that the instances are already installed.
In our case, the Instance Name “DB” is installed in only one node, and we need to choose this instance in the list box in the top to proceed to the node addition.

Screen Shot 2013-12-09 at 22.44.13

10. Now. confirm the IP settings as you did in the first node installation. Click “Next”.

Screen Shot 2013-12-09 at 22.45.02

11. Fill the passwords for the Engine and Agent service account, and click  “Next”.

Screen Shot 2013-12-09 at 22.45.36

12. Like in the other (first) node, you have the option to send error reports to Microsoft. Click on “Next”.

Screen Shot 2013-12-09 at 22.46.14

13. Now the setup will verify if the installation process can be blocked. In the end, click “Next”.

Screen Shot 2013-12-09 at 22.46.26

14. Review the options and click on “Install”.

Screen Shot 2013-12-09 at 22.46.47

15 Now you can watch the installation progress. Click “Next” when it is done.

Screen Shot 2013-12-09 at 22.47.00

16. Now the node addition is complete! Just verify if all of the features have succeeded. Click “Close” and you are done!

Screen Shot 2013-12-09 at 22.56.08

At the end of this installation, you will have one more node available to run out our instance. This means that we can now perform a failover from W2012SRV03 to W2012SRV04, so we have now a high availability (HA) solution. In case of a hardware failure on the active node, we will have a failover action.

For some reason, such as a test or for maintenance purposes, you can do a failover manually. To perform this, open the Failover Cluster Manager tool (the same used on step 2), right-click over the role name (in our case “SQL Server (DB)” and then select the “Move” option. Two options will be shown — the first “Best Possible Node” and the second one “Select Node…” Both are valid, but the second gives you the chance to choose the node to move the Role, which is useful when you have more than two nodes.

Screen Shot 2013-12-18 at 16.38.27

Part 4

We have reached the last article of this series. To close this series out, we will talk about Distributed Transaction Coordinator, or simply DTC. I’ll try to do some simple explanation. After that, I’ll demonstrate how to prepare the DTC for a clustered instance.

What is DTC (MS DTC)?
The MS DTC is a OS level service, which comes automatically installed and running under the Network Service account. Its role is to ensure that a distributed transaction is consistent, even with failures.
Those transactions might be initiated when a transaction is dealing with data on multiple computers via network or when the transaction is dealing with multiple processes in a single computer.

All the participants of a distributed transaction works in sync with the other participants (computers) involved in a transaction, looking for the right moment to commit or abort its work. For this reason, we need to make sure that the computers can reach each other.

Do I need to configure MS DTC on my environment?
The answer for this question is the standard for almost everything involved with SQL Server; It depends. You need to understand whether or not you will perform distributed transactions. If you have more than one instance in the same computer (without aditional componentes installed), you won’t need the DTC. On the other hand, if you have a two nodes cluster with two clustered instances communicating with each other, you will need the DTC – the instances could be in different nodes. Another possible scenario is when you have the database engine and SSIS installed, in this case you will need to configure the DTC.

For more information, check this link:

How to create a clustered MS DTC?

Since Windows 2008, we are allowed to have more than one instance of MS DTC in a server/cluster. So, for clustered SQL Server installations is a best practice to have a Role exclusively for the DTC and a dedicated DTC for each SQL Server Role.

As documented per Microsoft, the SQL Server follow this path to choose the MS DTC instance to use:

  • Use MS DTC installed to the local group, else
    • Use the mapped instance of MS DTC, else
      • Use the cluster’s default instance of MS DTC, else
        • Use the local machine’s installed instance of MS DTC

To configure a DTC in cluster, we will need a disk and a hostname.

To configure a Role exclusively for the DTC, follow the steps:

  1. Right-click on Roles and pick the “Configure Role” option.
    Screen Shot 2014-01-02 at 14.18.43
  2. A new window will open. Click “next”.Screen Shot 2014-01-02 at 14.18.52
  3. Choose the option “Distributed Transaction Coordinator (DTC)” from the list. Click  “Next”.Screen Shot 2014-01-02 at 14.19.11
  4. Fill the hostname in the “Name” field and the IP in the “Network” section. Click “Next”.Screen Shot 2014-01-02 at 14.20.33
  5. Pick up the disk to be used. Click “Next”.Screen Shot 2014-01-02 at 15.14.42
  6. Review the configurations and click “Next”.Screen Shot 2014-01-02 at 15.14.57
  7. The installation will run and in the last step you will see a report. Click “Finish”.Screen Shot 2014-01-02 at 15.15.11
  8. Now you will be able to see a new Role created in the cluster, with all the indicated resources.

Screen Shot 2014-01-02 at 15.16.51

To add a DTC resource into the SQL Server Role, follow the steps:

  1. Right-click the Role, go to “Add Resource”->”More Resources” -> “Distributed Transaction Coordinator”.Screen Shot 2014-01-02 at 15.30.50
  2. The resource will be created in the selected Role, now we need to configure it. Right-click the “New Distributed Transaction Coordinator” and click on “Properties”.Screen Shot 2014-01-02 at 15.31.20
  3. As referred early on this article, the DTC needs a hostname and a disk to work. On dependencies you can pick up those items as shown, and click “ok”.Screen Shot 2014-01-02 at 15.32.44
  4. Now, let’s bring it online.Screen Shot 2014-01-02 at 15.32.55

How to configure the network for distributed transactions?

Note: On clustered environments,you just need to perform the following steps one time.

  1. On “Server Manager” go to “Tools”->”Component Services” or run the command “dcomcnfg”.Screen Shot 2014-01-02 at 15.33.55
  2. Expand the tree, right-click the desired DTC and choose “Properties”.Screen Shot 2014-01-03 at 11.46.28
  3. Go to the “Security” tab and check “Network DTC Acess” as well as “Allow Inbound” and “Allow Outbound”, as shown bellow. Click Ok.Screen Shot 2014-01-03 at 11.49.02
  • Let’s briefly describe the some of the options on this window:
    • Network DTC Access“: Enable/Disable the network access.
    • Allow inbound“:  Permit a distributed transaction originated from another computer to run on the current computer.
    • Allow outbound“:  Permit a distributed transaction initiated in the current computer to run on a remote computer.
    • Enable XA transactions” and “Enable SNA LU 6.2 Transactions“: Enables/Disable those particular specifications for distributed transactions.

Troubleshooting DTC

There’s a tool called DTC Ping which can help us to verify if the DTC is working correctly on all the computers that should be involved in a transaction.

You can download this tool here:

I recommend the reading of this article, to learn hos to use this tool, as well as troubleshoot the possible errors: Troubleshooting MSDTC issues with the DTCPing tool.

Another great tool is the DTC Tester. You can simulate a distributed transaction on SQL Server:

Screen Shot 2014-01-03 at 14.15.25

To download and get more info about this tool, check this link: .


Article from:

How to rename the SQL Server Network Name of a failover cluster


Sometimes there may be a need to rename the SQL Server Network Name for a failover cluster and in this tip we will walk through the steps needed to successfully rename the SQL Server Network Name for a failover cluster.


The SQL Server Network Name is used to identify a failover cluster on the network. This was known as the virtual SQL Server name in earlier versions of SQL Server failover clusters. When you connect to SQL Server using this name, this will connect to the current online node.

Rename the SQL Server Network Name

Step 1 – Get the current SQL Server Network Name

The first step is to get the current SQL Server network name of the failover cluster. You can check the name multiple ways. You can run the below T-SQL command to get the SQL Server network name.

Check SQL Server network name

Or you can launch the Failover Cluster Manager to check the virtual server name as shown below.

Launch failover cluster manager

In both options, we can see the current SQL Server Network Name is MSSQLCLUSTER.

Step 2 – Change the SQL Server Network Name

From with the Failover Cluster Manager, right click on the Server Name and choose Properties as shown in the below screenshot.

Choose properties in FCM

The SQL Server Network Name property window will appear as shown in the below screenshot. Here you can see the “DNS Name” as MSSQLCLUSTER. This is where you need to change the SQL Server Network Name.

Property Window of network name

I changed my SQL Server Network Name from MSSQLCLUSTER to SQLCLUSTER as shown in the below screenshot. Once you change the name, click the Apply button.

change sql server network name

Once you click the “Apply” button, it will ask you to confirm this change as shown below.  You will get the message “This change requires clients to update the name used to connect to this clustered role. You will also need to manually restart any service or application that depends on this resource. Are you sure that you want to make this change?”. Click Yes to accept the change.

Confirmation window

After clicking Yes, this setting will be saved and the process bar will look like the below screenshot.

Saving Properties

Step 3 – Verify the SQL Server Network Name Change

We have renamed our SQL Server Network Name for this failover cluster. You can verify this change by running the following T-SQL command.

Verify the change

Or you can verify the name change in the Failover Cluster Manager as shown below.

Verify the change

Step 4 – Test Old SQL Server Network Name

If you try to connect to SQL Server using the previous name, you will get the following error.

connection error

Step 5 – Cycle Resources and Services

Although you will be able to make a connection using the new SQL Server Network Name, Microsoft recommends taking the SQL Server network resources offline and bringing them back online after the modification. To do so right click on the SQL Server Network Name and click on the “Take Offline” option.

Take Offline

Once the resources are offline, the interface will look like the below screenshot.

Take Offline

Now right click on the Server Name again and click “Bring Online”. Once you bring the SQL Server Network Name resource online, SQL Server will not come online automatically because the SQL Server services are set to Manual mode in a failover cluster environment, so you will need to manually bring these services online.

bring online

Step 6 – Validate changes by testing failover

First check the owner node for SQL Server. We can run the following T-SQL command and see that SQL-NODE1 is the current owner node.

failover testing

Now open the Failover Cluster Manager and initiate a failover. You can right click on the SQL Server instance and choose the “Move” > “Best Possible Node” option. As our cluster is a two-node cluster, it will failover to the second node.

failover testing

Once the failover is successful, again connect to the SQL Server instance by using the new SQL Server Network Name and run the below T-SQL command. We can see that SQL Server is online on SQL-NODE2 from the below screenshot.

validate failover testing

You can also check the active node in the Failover Cluster Manager as shown below.

validate failover testing
Article from:

Setting up High Availability Failover Cluster for SQL Server 2012 using Windows Server 2012 R2

In this lab we will install HIGHLY AVAILABLE SQL Server Failover Cluster on a iSCSI SAN service that we will configure on Windows Server 2012 R2 operating system.

We will use 3 machines for this lab as described below.

  • DC01 ( acting as a Domain Controller for the domainDALARIS.LOCAL, running Microsoft Windows Server 2012 R2 Standard. This server also acts as an iSCSI Target Server that we will be configuring later.
  • SQL01 ( This is the Node1 of the SQL Server cluster.
  • SQL02 ( This is the Node2 of the SQL Server cluster.

Step by step implementation

  • Server Settings / Preparation
  • Prepare iSCSI Storage
  • Connect SQL01 and SQL02 to iSCSI Storage
  • Crate the Failover Cluster
  • Install SQL on SQL01
  • Connect SQL02 to the Failover Cluster
  • Test High Availability For SQL Server.

0/ Server Settings / Preparation

TCP/IP Settings for DC01

Server Information

I have changed the host name of the server to DC01. Type hostname to verify that is the case. Additionally this server has been promoted to a Domain Controller with the five FSMO roles on it. Type the following command to verify that this is the case:

netdom query fsmo

TCP/IP Settings for SQL01

The hostname and domain information for SQL01.

TCP/IP settings on SQL02

Hostname and Domain information for SQL02

1/ Prepare iSCSI Storage on DC01

While we could use another server for iSCSI Target services, I used the Domain Controller for this purpose to save on resources. In production environment, this should be on a separate server.

On DC01, install iSCSI Target Server (Under File and Storage Services / File and iSCSI Services).

Choose Role-based or feature-based installation.

Choose the server to be DC01.DALARIS.LOCAL.

Choose role iSCSI Target Server.

Do not select any features.

Click Install.

Once installation of iSCSI Target Server is completed, click Close.

Now create three iSCSI Virtual Disks (C:\iSCSIVirtualDisks\Diskn.vhd) and have the 2 machines and connecting to each virtual disk. Use target1 as target name for all three disks. Disk1 is 5GB, Disk2 is 10GB and Disk3 is 10GB. to do all of that, follow the steps below.

In Server Manager, click File and Storage Services.

Click iSCSI and then click on “To create an iSCSI virtual disk, start the new iSCSI Virtual Disk Wizard

Leave the Volume as C:\, the iSCSI virtual disks will be saved at C:\iSCSIVirtualDisk\*. Click Next.

Type the disk name as Disk1. Click Next.

Choose Fixed size 5GB and allow it to clear the virtual disk on allocation. ClickNext.

Choose New iSCSI target and click Next. This will create a new target.

Enter the name of the target as Target1 and click Next.

We need to add the initiators that are allowed to access the target. Click Add

Enter the IP address of the first node and click OK.

Click Add… again to add the second node.

Enter the IP address of the second node and click OK.

Click Next.

For the purpose of this lab, I leave CHAP and reverse CHAP disabled.

Click Create. This will create the first virtual disk and store it on the C: drive of the domain controller under C:\iSCSIVirtualDisks\

Click Close when done.

Note that now we have one virtual disk created. This is just a VHDX file called Disk1.VHDX.

We will need to create two more disks. Right-click on an empty area under the first disk created, choose New iSCSI Virtual Disk

Leave the default volume and location. Click Next.

Name the disk Disk2 and click Next.

Enter 10G and click Next.

Choose existing target and click Next.

Click Create.

Click Close.

Note that now we have two disks created.

Repeat the same steps above to create the third disk called disk3. After creating disk3, we will have totally 3 disks.

Under C:\iSCSIVirtualDisks, there are three VHDX files created with the respective sizes as well.

2/ Connect to iSCSI Storage

On the two machines SQL01 and SQL02, use iSCSI Initiator to connect to the target. I am going to demonstrate this process on SQL01. You will need to repeat the same process on SQL02.

Click Start, type iscsi to search and then click on iSCSI Initiator.

Click Yes to start the Microsoft iSCSI service.

In the Target box, type (this is the IP address of the iSCSI Target server, which is DC01). Click Quick Connect. It should be connected.

When it is connected, note the IQN and click Done.

Note that the status is now Connected. Click OK to dismiss the dialog box.

On SQL01, use Disk Management (diskmgmt.msc) to bring all three disks online.

Right-click on each of the Offline disk and click Online.

Note that the disks are now online but are not initialized.


Right-click on Disk1 and Initialize it (using MBR). Then create a simple volume. Use the name of ClusterDisk1 as a volume name.

Choose all three disks to initialize.

As you can see, now all disks are Online, Initialized but not partitioned yet.

Right-click on each disk and create a volume for it. Name the volumes to beClusterDisk1, ClusterDisk2, and ClusterDisk3 respectively.

PART 3: Create Failover Cluster

On both SQL01 and SQL02, install the Failover Clustering Feature. In Server Manager, click Add roles and features.

Choose Role-based or Feature-based installation and click Next.

Select the server and click Next.

Do not select any roles and click Next.

Choose Failover Clustering feature to be installed.

Click Add Features.

Click Install.

Click Close when done.

Now, please perform the same steps above to install the Failover Clusteringfeature on SQL02. When done, we will start configuring the failover cluster using the Failover Cluster Manager. Let’s start configuring it on SQL01.

On SQL01, open Failover Clustering Manager.

Click Create a Cluster.

Now enter the servers SQL01 and SQL02 into the selected servers, click Add each time. Click Next.

Choose “No. I do not require support from Microsoft.” Click Next.

Choose a Cluster name. In this case, I used SQLCluster.

Enter IP address for the cluster. I will use a spare IP address of (This is the cluster IP we will use). Note that on the DNS server, there should be an A record pointing sqlcluster.dalaris.local to

Checkmark on “Add all eligible storage to the cluster” and click Next.

Click Finish to create the cluster.

In the Failover Cluster Manager, choose SQLCluster.dalaris.local / Storage /Disks. We see that all three disks are Offline.

Just wait for a few minutes for them to come Online.

Note that all three disks must be online.

Now we need to validate the cluster. Right-click on the Cluster name and chooseValidate Cluster.

Click Next.

Click Next, choose run all tests.


Click Next.

Click Next.

Click View Report and Make sure there is no FAILURE. Close the report.

Click Finish.

Now highlight Cluster Disk 3 and make it a Shared Cluster Volume. ClusterDisk3 will be used as Disk Witness Quorum.

Now Cluster Disk 3 is shown as Cluster Shared volume.

PART 4: Install SQL on SQL01

On SQL01, insert the SQL Server 2012 DVD and run setup.exe

Choose New SQL Server failover Cluster Installation.

Show details, OK.

Enter the Product Key. Click Next.

Accept the license terms, click Next.

Checkmark on Include SQL Server updates if you want. Click Next.

Click Show details then click Next again. We will take care of these warnings later.

Choose SQL Server Feature Installation, click Next.

Choose SQL Server Replication, Full-text and semantic Extraction, Data Quality Service, Mangement Tools Basic and Complete then click Next

Click Show Details then click Next.

SQL Server Network Name: make up a name for the SQL Server Failover Cluster, such as SQLCLU. Click Next.

Click Next at the Summary screen.

Click Next.

Choose Cluster Disk 2 to store cluster info.

In IP addres, enter an unused IP for cluster ( then click Next.

In Active Directory, I have a user called sqlsvc. This user is used for SQL Server Services. Enter the user name (Dalaris\sqlsvc) and password for the services SQL Server Agent and SQL Server Database Engine.

Choose Mixed Mode; also click Add Current User to make the userAdministrator to be the SQL Server Administrator. Click Next.

On Error Reporting, click Next.

Click Show Details, click Next.

Click Install.

Wait for installation to finish, Click Close.

Launch Failover Cluster Manager and click Roles. You will see SQL Serverrunning.

Choose Storage, Disks. You will see Disk2 is used for SQL Server.

PART 5: Link SQL02 to the Failover Cluster

On SQL02, insert the Microsoft SQL Server 2012 DVD and run setup.exe.

Click Installation: Choose Add node to a SQL Server failover cluster.

Click OK.

Enter product key and click Next.

Accept the license terms and click Next.

You should include the SQL Server product updates. For the purpose of this lab, I will skip this. Click Next.

Make sure that all tests pass. We will fix the warning later. Click Next.

Choose the SQL Server Instance name as MSSQLServer, name of this node is SQL02. Note that nodes show SQL01 already listed there. Click Next.

Observe the IP Address of cluster: This IP address was made up by us previously. Click Next.

Enter the password for Database Engine and SQL Server Agent (for the accountsqlsvc). Click Next.

Click Next again at the Error Reporting screen.

Click Show Details to make sure all tests pass and Click Next.

Click Install.

Click Close when the installation completes.

Disable the Windows Firewall on both servers.

PART 6: Verify High Availability

On either SQL01 or SQL02, open Failover Clustering Manager. Choose Roles, observe that SQL Server MSSQLServer is running. Its owner is currently SQL01.

Choose Nodes, SQL01 and observe in the Roles tab, we see that this node is running as SQL Server (MSSQLServer).

Choose Nodes, SQL02 and observe that this node is blank.

Let’s pretend that we want to manually move MSSQLServer to SQL02.

Click Roles, right-click on MSSQLServer and click Move. Choose Select

Choose the node SQL02. Click OK.

Wait for the movement… The status will show as pending.

After the move is successful, the owner will be SQL02.

Under Nodes, SQL01, it is shown as blank.

Under Nodes, SQL02, observe that SQL Server (MSSQLServer) is running.

Let’s perform an automatic failover. For a moment, just pretend that SQL02 has NIC card failure. Let’s disable NIC on SQL02 to simulate that.

Go to SQL01, choose Nodes, we see that SQL02 is down.

Choose Roles, wait shortly and check that service is automatically moved toSQL01.

Check that SQL Server (MSSQLServer) is running normally on SQL01.


Congratulations. You have finished the lab of installing SQL server 2012 Failover Cluster.

Article from:

No iSCSI option found in File and Storage Services on Windows 2012 Server

On the node you must:

1) Enable the ISCSI Target


Using Server Manager (UI)

iSCSI Target can be enabled using Add roles and features in the Server Manager:

1. Choose the Role-based or feature-based installation option


2. Select the server you want to enable iSCSI Target


3. Select the iSCSI Target Role:


To enable iSCSI Target feature, you should select the “iSCSI Target Server” feature.

4. Confirm the installation



How to Configure a Clustered Storage Space in Windows Server 2012

This blog outlines the sequence of steps to configure a Clustered Storage Space in Windows Server 2012 using the Failover Cluster Manager or Windows PowerShell®. You can learn more about Storage Spaces here:


  •          A minimum of three physical drives, with at least 4 gigabytes (GB) capacity each, are required to create a storage pool in a Failover Cluster.
  •          The clustered storage pool MUST be comprised of Serial Attached SCSI (SAS) connected physical disks. Layering any form of storage subsystem, whether an internal RAID card or an external RAID box, regardless of being directly connected or connected via a storage fabric, is not supported.
  •         All physical disks used to create a clustered pool must pass the Failover Cluster validation tests. To run cluster validation tests:
    • Open the Failover Cluster Manager interface (cluadmin.msc) and select the Validate Cluster option.

  •          Clustered storage spaces must use fixed provisioning.
  •          Simple and mirror storage spaces are supported for use in Failover Cluster. Parity Spaces are not supported.
  •          The physical disks used for a clustered pool must be dedicated to the pool. Boot disks should not be added to a clustered pool nor should a physical disk be shared among multiple clustered pools.
  •          Storage spaces formatted with ReFS cannot be added to the Cluster Shared Volume (CSV).

Steps to configure using the Failover Cluster Manager

1.       Add the File Services Role and the File Services Role Administration Tools  to all nodes in the Failover Cluster

2.       Open the Failover Cluster Manager interface (cluadmin.msc)

3.       In the left-hand pane, expand Storage. Right-click on Pools and select New Storage Pool. This will start the New Storage Pool Wizard

4.       Specify a Name for the Storage Pool and choose the Storage Subsystem that is available to the cluster and click Next

5.       Select the Physical Disks (a minimum of three with minimum capacity 4GB each and bus type SAS) for the storage pool and confirm the creation of the pool. The pool will be added to the cluster and brought Online, once created.

6.       The next step is to create a Virtual Disk (storage space) that will be associated with a storage pool. In the Failover Cluster Manager, select the storage pool that will be supporting the Virtual Disk. Right-click and choose New Virtual Disk

7.       This initiates the New Virtual Disk Wizard. Select the server and storage pool for the virtual disk and click Next.  Note that the cluster node hosting the storage pool will be listed.

8.       Provide a name and description for the virtual disk and click Next

9.       Specify the desired Storage Layout (Simple or Mirror; Parity is not supported in a Failover Cluster) and click Next

Note: I/O operations to a CSV mirror space are redirected at the block level through the CSV coordinator node. This may result in different performance characteristics for I/O to the storage, compared to a simple space.

10.   Specify the size of the virtual disk and click Next. After you confirm your selection, the virtual disk is created. The New Volume Wizard is launched if you do not uncheck this option on the confirmation page.

11.   The correct Disk and the Server to provision the disk to should be selected for you. Verify this selection and click Next.

12.   Specify the size of the volume and click Next

13.   Optionally assign a drive letter to the volume and click Next

14.   Select the file system settings and click Next and confirm the volume settings. The new volume will be created on the virtual disk and will be added to the Failover Cluster.

Note: The NTFS File System should be selected if the volume is to be added to Cluster Shared Volumes.

15.   Your clustered storage space can now be used to host clustered workloads. You can also see the properties of the clustered storage space and the clustered pool that contains it, from the Failover Cluster Manager.

Steps to configure using Windows PowerShell®


Open a Windows PowerShell® console and run the following steps:

1.       Create a new pool

a.  Select physical disks to add to the pool

$phydisk = Get-PhysicalDisk –CanPool $true | Where BusType -eq “SAS”

b.  Obtain the storage subsystem for the pool

$stsubsys = Get-StorageSubsystem

c.       Create the new storage pool

$pool = New-StoragePool -FriendlyName TestPool -StorageSubsystemFriendlyName $stsubsys.FriendlyName -PhysicalDisks $phydisk -ProvisioningTypeDefault Fixed

d.      Optionally add an additional disk as a HotSpare
$hotSpareDisk = Get-PhysicalDisk –CanPool $true |Out-GridView -PassThru

Add-PhysicalDisk -StoragePoolFriendlyName TestPool -PhysicalDisks $hotSpareDisk -Usage HotSpare


2.        Now create a Storage Space in the pool created in the previous step

a.  $newSpace = New-VirtualDisk –StoragePoolFriendlyName TestPool –FriendlyName space1 -Size (1GB)  -ResiliencySettingName Mirror


3.       Initialize, partition and format the Storage Space created

a.  $spaceDisk = $newSpace | Get-Disk

b.  Initialize-Disk -Number $spaceDisk.Number -PartitionStyle GPT

c.  $partition = New-Partition -DiskNumber $spaceDisk.Number -DriveLetter $driveletter -size $spaceDisk.LargestFreeExtent

d.  Format-Volume -Partition $partition -FileSystem NTFS


4.       Add the Storage Space created to the Cluster

a.  $space = Get-VirtualDisk -FriendlyName space1

b.   Add-ClusterDisk $space



  • Clustered Spaces can also be created using the Server Manager:

  • You can find a full end to end Windows PowerShell® sample on setting up a file server cluster with Storage Spaces here.

Troubleshooting tips:

If you come across any of the following errors while attempting to add a storage pool to the cluster please review the Prerequisites section at the beginning of this blog to determine which requirement was not met:

Failed to add storage pool to cluster – {XXXXXXX-XXXX-XXXX-XXXX-XXXXXXX}

No storage pool suitable for cluster was found.


Article from: