Today I was trying to install a SQL Server 2008 R2 Cluster environment on Windows Server 2012 R2 servers and after doing all the necessary steps to prepare the cluster (like Creating an iSCSI Virtual Disk for Windows Cluster, configuring both node members, installing .net Framework 3.5, Adding the Windows Cluster Failover Feature, configuring the cluster, etc...) I continued by running the "Advanced Cluster Preparation" installation in SQL Server 2008 R2.

During one of the initial steps (the one checking the Rules) I find that the "Not clustered or the cluster service is up and online" step fails...

enter image description here

Upon inspection of the details I see that the "machine is clustered, but the cluster is not online..." message

enter image description here

... not sure the reason why, since when I inspect the cluster using Failover Cluster Manager everything seems all rightenter image description here

enter image description here

I can even do a fail-back on the drives and a fail-over with no problem. I also ran the Validation report and everything came back green...

Any ideas of what could I be missing?

More investigation

This is what I found when looking in the SystemConfigurationCheck_Report.htm (on the bootstrap log)... apparently it is more or less the same message. All the other checks are "green" (OK).

enter image description here

Also, on further bootstrap log investigation, I found this section (in the detail.txt for one of my executions) that appears to shed some more light...

enter image description here

What "the given key was not present in the dictionary" means... I can't say. I'm not an expert in advanced cluster troubleshooting so I am only speculating here... I have updated the contents of my bootstrap log here if anybody thinks they can find some more "clues" that I have not been able to find...

More findings (24 hours later...) So, I have not been able to find the root cause of the problem, even following suggestions in this page and this KB, nothing seems to help me with that Support Rule!

Today, out of desperation, I attempted to run the "Advanced Cluster Preparation" using the installation image for SQL Server 2017 Enterprise and that one indeed worked with no problems!

enter image description here

So the issue seems to be limited to SQL Server 2008 R2 cluster binaries (something that sometime after 2008 R2 was addressed). This is not a solution for me (as I need to make this work in 2008 R2 for various reasons) but at least sheds some more light into the problem (hopefully) and tells me there is nothing wrong with the Failover Cluster install and configure per se, but more of how SQL Server 2008 R2 interprets that I have a fully-functional cluster.

  • Is there more information in the bootstrap log?
    – Nic
    Commented Jan 11, 2018 at 19:36
  • Thanks Nic, I will investigate the bootstrap log and provide more information in the original question shortly... Commented Jan 11, 2018 at 20:38
  • do you have proper security access permission to both nodes? check if nodes can communicate from/to each other. And any reason why you still installing SQL Server 2008 R2 (legacy apps)? consider using SQL Server 2016/2017..
    – user37701
    Commented Jan 12, 2018 at 2:02
  • Thanks for looking into that DCO! The answer as to whether I have proper security access or not is "probably yes". In other words, This Virtual Network is just a playground that I created so I have domain admin rights (and that domain admin account is the one I'm using for the Advanced Cluster Preparation step). As far as communication between nodes, I can totally ping node B from node A and viceversa (I'm not sure if you suggest other types of tests but I think communication is good). Commented Jan 12, 2018 at 15:57
  • As to why I'm using SQL Server 2008 R2, the answer is just as you imagined: Legacy Apps. One interesting thing to note (that I added in my original question) is that, for the sake of having a better picture of what's going on, I attempted a clustered preparation using SQL Server 2017 Enterprise and it worked like a charm! so the problem is certainly related with legacy code on the "Advanced Cluster Preparation" on SQL Server 2008 R2. What that problem is, I still have no clue... Commented Jan 12, 2018 at 16:21

3 Answers 3


So, finally after more investigation I found the right post explaining my problem and the solution.

It turns out the article was the one that dco pointed out. The thing is this: the problem I was experiencing was not solved with the slipstreaming technique (the install with SP2) but with other thing mentioned there further down the road (Issue 2: The "Cluster Service verification" rule fails when you try to install a SQL Server 2008 R2 failover cluster instance).

Turns out I had to enable the "Failover Cluster Automation Server" Feature in my Windows 2012 R2 boxes.

Thanks everybody for your help on this matter, especially dco for pointing me to that website. Since the resolution that dco offered (slipstreaming with SP 3) was not the solution to my problem I did not accepted that one as the answer (so that future searches with other people looking to fix this same problem don't end up on a wild goose chase).


From bootstrap log I can see, the yellow part you have highlighted.

The given key was not present in the dictionary.

Now this is a clue we have to focus upon. So does this means the installation is trying to look for some key and is not able to find it and hence this message. Well this may not be as simple as it seems. This Blog says that this may be because the **password** of the account by which you are logged in to the windows server is not of 15 characters. The same has been highlighted into this MS KB Article.

There are 3 resolution mentioned I have highlighted the easiest one.


To resolve the problem, select the method that best fits your situation.

Method 1: Use a password that is at least 15 characters long When the NoLMHash policy is set in Active Directory and cannot be disabled because of security considerations, use a password that is at least 15 characters long to prevent the cluster setup wizard from using a LMHash for authentication.

Method 2: Enable the storage of LMHash in Active Directory Enable the storage of LMHash of a user password by using Group Policy in Active Directory. To do this, follow these steps: In the Default Domain Controllers Group Policy, expand Computer Configuration, expand Windows Settings, expand Security Settings, expand Local Policies, and then click Security Options. In the list of available policies, double-click Network security: Do not store LAN Manager hash value on next password change. Click Disabled, and then click OK. Make sure that the policy is replicated and is applied. Reset the password of the CSA (length may be less than 15 characters) to make sure that the LMHash is written to SAM/AD.

Method 3: Install a hotfix A hotfix is available from Microsoft to resolve this problem so that fifteen-character passwords are not required when the NoLMHash policy is set in Active Directory. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

890761 You receive an "Error 0x8007042b" error message when you add or join a node to a cluster if you use NTLM version 2 in Windows Server 2003

Last Updated: Jan 8, 2017 Please check the password length and if it is less than 15 character change it to like 16 character and then again do the installation.

  • Thanks for looking into this Shanky. I did look at that blog entry (and the associated KB Article ) while trying to troubleshoot this problem. I did try two of these three "Methods" (namely, changing the password length and disabling the "Do not store LAN Manager hash value on next password change" policy) to no avail unfortunately. Commented Jan 12, 2018 at 15:34

You may need to install at least Service Pack 2 or higher of SQL Server 2008 R2 on Windows Server 2012 R2. I would suggest you to install the latest Service Pack 3. You can get the installer here. Slipstream your installer to SP3. This guide will help you on how to slipstream.

You can also read this KB Article for OS and SQL Server Version Compatibility.

Edit (to complete my answer with the following solution based on the KB):

Minimum SQL Server version requirements for Windows Server 2012 R2 or Windows 8.1

For SQL Server 2008 R2 You must apply SQL Server 2008 R2 Service Pack 2 or a later update.

Issue: The "Cluster Service verification" rule fails when you try to install a SQL Server 2008 R2 failover cluster instance


When you try to install a SQL Server 2008 R2 failover cluster instance, the installation fails at the "Cluster Service verification" Rule.


This issue occurs if the COM-based MSClus.dll library is not enabled.

Note The SQL Server 2008 and SQL Server 2008 R2 cluster Setup programs depend on the COM-based MSClus.dll library. If this library is not enabled on the cluster node, the Setup fails.


To resolve this issue, do one of the following:

  • Enable the Failover Cluster Automation Server feature on each node by using Server Manager. In Server Manager, expand Remote Server Administration Tools, expand Feature Administration Tools, expand Failover Clustering Tools, and then click to select Failover Cluster Automation Server.

  • Run the following Windows PowerShell cmdlet on each node to enable the Failover Cluster Automation Server feature: add-windowsfeature RSAT-Clustering-AutomationServer Note You must run this cmdlet at an elevated command prompt.

  • Very interesting DCO... I totally didn't know about that KB Article. I can't test this right away, but I will certainly try this in the coming days and if slipstreaming SQL Server 2008 R2 install (with SP2) fixes the problem, I will certainly mark your answer and accept it. Commented Jan 16, 2018 at 14:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.