I was recently installing SQL Server 2008 R2 Standard Edition on a two-node failover cluster (see Features Supported by the Editions of SQL Server 2008 R2 on MSDN). The cluster was working perfectly and the Validate a Cluster Configuration Wizard reported all components in green. I had prepared a slipstreamed installation which included SP1 according to the steps explained here. Once launched, the installation wizard showed me that all SQL Server Failover Cluster installation rules and other checks passed. After filling in Network Name, Instance Name, setting the Service Accounts and Server Collation, choosing a Resource Group name (actually I left the default), chose the disks, set the IP address, chose an Authentication Mode, and set the Data Directories, I was presented with the Configuration Summary and the “Install” button. The installation started and I watched the progress bar move from left to right. At around 80% completion I got the following error message:
There was an error setting private property ‘VirtualServerName’ to value ‘SrvSQLN1’ for resource ‘SQL Server (INST1)’. Error: Value does not fall within the expected range.
I checked that the chosen DNS name was in fact not reserved, which it wasn’t. Nor was the Cluster Resource Group name. A quick web search revealed that this was not the first time this happened when installing an SQL Server 2008 R2 cluster, however all the results I came across did not offer a solution. That meant that I had to go through the installation logs… The servers I was installing on were brand new which came pre-installed with a Windows 2008 R2 operating system and a number of diagnostic tools, nothing more. I noticed that an SQL Server 2008 R2 Express Edition was present on both machines and which I guess was installed as part of the toolset. (Quite foolishly) I assumed that since the SQL Server installation did not object to the presence of an Express Edition instance I could rule it out. One of the [tens of] logs analysed showed that in fact the Express Edition was present, and also logged the error mentioned above. On further inspection of the same log file a jumble of characters caught my attention:
http%3a%2f%2fgo.microsoft.com%2ffwlink%3fLinkId%3d20476%26ProdName%3dMicrosoft%2bSQL%2bServer%26EvtSrc%3dsetup.rll%26EvtID%3d50000%26ProdVer%3d10.50.2500.0%26EvtType%3d0x625969A3%400x294A9FD9
This I identified as an encoded URL, which when decoded becomes: http://go.microsoft.com/fwlink?LinkId=20476&ProdName=Microsoft+SQL+Server&EvtSrc=setup.rll&EvtID=50000&ProdVer=10.50.2500.0&EvtType=0x625969A3@0x294A9FD9 (Many thanks to Eric A Meyer’s URL Decoder/Encoder at http://meyerweb.com/eric/tools/dencoder/). The link took me to a Microsoft page saying that “there is no additional information about this issue in the Error and Event Log Messages or Knowledge Base databases at this time”. Obviously I could not and did not give up there. By chance (?) I decided to remove both the EventType parameter and value passed from the above URL which took me to another page. This time the page explained that “An attempt was made to install (or update) SQL Server Native Client on a computer where SQL Server Native Client is already installed, and where the existing installation was from an MSI file that was not named sqlncli.msi.” - that’s when realised that the Express Edition was the cause! I uninstalled the SQL Server Express Edition instance and related components from all nodes of the cluster. I did not however remove the diagnostic tool but I’m quite sure that it won’t work. Neither did I reinstall the Express Edition instance. The first node of the clustered SQL Server 2008 R2 instance was done!