This article shows you how to troubleshoot a failed installation of SQL Server and how to implement a workaround to allow SQL Server 2017’s PolyBase feature to be installed when version 9 of the Java Runtime Environment (JRE) is present. An installation of all features in SQL Server 2017 has three external dependencies. Python, R, and the JRE are third party or open source software needed in a full installation. Changes to external software after the release of SQL Server 2017 can introduce breaking changes. Oracle, the company that owns Java, changed how Windows registry keys are named. This caused a breaking change for SQL Server 2017. Version 8 of the JRE is compatible with the SQL Server 2017 installer. Version 9 of the JRE is not. If version 9 of the JRE is the only version of the JRE on a Windows machine, it is not possible to install the PolyBase feature. The JRE version bug also is found in the SQL Server 2016 installer. The same workaround works for both SQL Server 2016 and 2017.
SQL Server 2017’s PolyBase feature requires the Oracle JRE version 7 update 51 or higher. Version 8 of the JRE works just fine. Version 9 is clearly higher than version 7, but the SQL Server 2017 installer cannot detect that version 9 of the JRE is present when it is. This causes the following error message to appear:
When you really want to troubleshoot a failed SQL Server installation, clicking the Failed hyperlinks in SQL Server installer dialog boxes is not enough. You need to go to the installer’s log file named Detail.txt. By default, you find SQL Server 2017 installer log files in C:\Program Files\Microsoft SQL Server\140\Setup Bootstrap\Log where 140 refers to SQL Server 2017. For SQL Server 2016, you will find the log file in C:\Program Files\Microsoft SQL Server\130\Setup Bootstrap\Log where 130 refers to SQL Server 2016.
Close examination of the Detail.txt file reveals the following when the JRE major version number is 9:
(01) 2017-12-06 23:23:49 SQLPolyBase: Could not find registry setting HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\CurrentVersion.
(01) 2017-12-06 23:23:49 SQLPolyBase: Minimum version expected: 1.7.51. Java not found.
The installer is telling us that the problem is not actually with the Java runtime itself, but instead where the installer is looking in the registry. To understand the root cause of the problem, let’s compare the registry keys for JRE version 8 with the registry keys for JRE version 9.
Notice that the JRE version 8 registry key ends with Java Runtime Environment.
Notice that the JRE version 8 registry key ends with JRE. That is why the SQL Server 2016 and 2017 installers cannot find the JRE version 9.
There are really only three options for installing PolyBase with SQL Server 2016 or 2017.
- Install a compatible JRE with a major version number less than 9.
- Wait for Microsoft to issue a patch.
- Update your machine’s registry to let the SQL Server installer find what it is looking for.
I choose to update the registry to allow SQL Server 2017 to be installed when the installed JRE is version 9. To do this, you need to export the registry key for the JRE, edit it, and import the modified keys into the registry.
To export the registry key, use regedit and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JRE. Right-click and select Export. Save the registry key to a file which in this example is named jreRegKey.reg. Edit the file with a text editor such as Notepad.
Be careful when editing the registry file. You can do a global replacement if and only if you match case. You want to replace all occurrences of JRE with Java Runtime Environment. You must not alter the lowercase jre references.
Save your changes and import the modified reg file by double-clicking it. With the new registry keys imported, the SQL Server 2017 installer is able to find the JRE version 9 and successfully complete the installation process as evidenced by the following query:
The query was obtained from the Get started with PolyBase page on Microsoft’s website.
As you can see, SQL Server installer log files provide greater insight allowing you to do root cause analysis of failed installations. Placing dummy entries in the registry to work around a breaking change may be too extreme for some, but it is possible to quickly overcome the PolyBase installation problem by making a simple registry update as described in this article.