The Scenario
While on a recent project, one of my colleagues and I came across an issue when trying to install a new SCCM Current Branch site using Server 2012 R2 and SQL 2016.
The setup wizard would start just fine, and all prerequisites passed. However when we got to the point where we needed to specify a SQL Server, SCCM kept telling us that the SQL server instance could not be found.
We validated that our SPN was set correctly, and that SQL was available. We validated that the user running setup had the permissions required to install SCCM.
When we looked in the ConfigMgrSetup.log file, and noticed we were getting an “SSLSecurityError” when trying to connect to SQL Server during the setup wizard.
Resolving the Issue
A quick search on the error above pointed us to the possibility that our issue was likely related to TLS 1.0 being disabled on the Site Servers.
Due to known security issues with older versions SSL/TLS, many organizations are locking down client/server communications to only allow TLS 1.2.
Until recently, TLS 1.2 support in SCCM was hit and miss, until Sept 2017, when MS Published an article on how to configure SCCM to function in an environment where TLS 1.0/1.1 is disabled, and TLS 1.2 is enabled.
You can find the article in question here: https://support.microsoft.com/en-us/help/4040243/how-to-enable-tls-1-2-for-configuration-manager
Using the article as a guide, we discovered that TLS 1.2 was enabled on our servers, while TLS 1.0 and 1.1 were disabled.
TLS is used on several components throughout windows, and the actions required depend on what version of Windows Server, .NET Framework, SQL Server, and WSUS you are running.
We installed all the updated components and changed registry settings specified in the KB Article, but after rebooting the servers we still had the same issue. We verified that the Server was fully patched, just to ensure that we hadn’t missed something.
Next, we temporarily re-enabled TLS 1.0, rebooted, started the setup process again, and verified the error was not present. Once we had verified this, we reconfigured the server for TLS 1.2 support.
In this environment, Domain GPOs were forcing TLS 1.2 so we needed to find a way to ensure that the setup would complete if the setting was changed during the process.
In looking at the SMSSetup.log, we noticed that it was calling out a specific SQL ODBC Driver (the default one that shipped with Windows Server 2012 R2). This driver did not have an available update listed in the article.
We unsuccessfully attempted to find a mechanism to force ConfigMgr Setup to use one of the other available drivers that had been updated for TLS 1.2 support.
VOILA!
Once we realized that we could not get SCCM to use a different ODBC driver, we decided to try and re-point the drivers via the registry. We exported the keys for both the “default” driver and one of the updated SQL ODBC Drivers (located in HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI), and re-imported so that the default ODBC entry was actually pointing to an updated driver.
We started setup again, and SCCM could now see the SQL Server. Once setup was completed, we swapped the registry settings back to prevent other issues in the future and verified that SCCM was working properly.
In short, it seems that SCCM doesn’t fully support TLS 1.2 during the initial setup process. Depending on your environment, you can either temporarily enable TLS 1.0, or redirect ODBC to a supported driver via the registry as a workaround until setup is completed.
