Blog

SQL Server FCI Setup Problems 2: Windows Server 2012 and VCOs Part 2

By: on January 14, 2013 in CNO, Failover Clustering, Setup, SQL Server 2008 R2, SQL Server 2012, VCO, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012

When I last left you in Part 1, I showed you the new functionality in Windows Server 2012 where the CNO and VCO does not have to be put in the default Computers OU automatically if you do not pre-stage things. The examples I showed were all using a Windows Server 2012 DC. This time around, I’m going to try the same thing but with a Windows Server 2008 R2-based DC with a functional level of W2K8 R2.

First, what I did was force the DC to put the computer objects into the W2012 Servers OU using the command shown in Figure 1. I also gave the cluster administration account the CCO right on that OU.

Figure 1. Creating a default OU

I then added DENNIS and TOMMY to the MHZ domain, and as expected, they automatically were placed in the proper OU as shown in Figure 2.

Figure 2. DENNIS and TOMMY after being added ot MHZ

I created a WSFC with the same name, STYX. Just as with the Windows Server 2012 DC, the CNO got created in the proper OU. You can see it in Figure 3, but if you look at Figure 4 which is the output of the WSFC creation, I did not have to go to AD to look – it told me right there it happened. To this point, everything is working as expected.

Figure 3. OU after creating the WSFC named STYX

Figure 4. Cluster creation report showing the proper OU

Up next was creating the FCI. Remember that in the previous post, I showed you with a Windows Server 2012 DC at a Windows Server 2012 functional level, I needed to give the CNO computer object CCO rights on the OU. I’m happy to report  that no such thing needed to be done with the W2K8 R2 DC. Just having the cluster administration account with those rights created the VCO for the SQL Server FCI just fine. See Figures 5 and 6.

 

Figure 5. Successfull starting of the EQUINOX FCI

Figure 6. The Equinox VCO in W2K8 R2 AD

This is all good news. While there are clearly slight differences in your OS choice for AD as to how to go about this, the bottom line is that you do not need to have a completely new infrastructure to take advantage of this feature. You should be able to leverage your existing AD infrastructure with no problem. If your AD admin has complained to you in the past about extra work he or she has had to do to create and move AD objects for clusters, this may go away if you start using Windows Server 2012 for your nodes.

I’m just getting warmed up with Setup-related weirdnesses, oddities, and problems. See you next time!


Leave a Reply

Your email address will not be published. Required fields are marked *