It should be a rather large note that the overall suggestion in this article breaks SQL OLEDB provider...

[StingyJack]

...which I bet is still seeing a fair amount of use. I read that it would break ODBC as well, but I dont use that and didnt try it.

To get around this if it happens to you, I have had success with installing the Sql Native Client for the correct OS version, and then changing the provider in the connection string from SQLOLEDB to SQLNACLIXX.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 7341fa0a-f474-6c2d-d3c0-7e2df12fbb65
• Version Independent ID: e99c489a-7518-d293-ad93-7eaca8b7191a
• Content: Transport Layer Security (TLS) best practices with the .NET Framework
• Content Source: docs/framework/network-programming/tls.md
• Product: dotnet-framework
• GitHub Login: @karelz
• Microsoft Alias: ncldev

[karelz]

What exactly breaks OLEDB? Maybe it is a bug that needs to be followed up upon.

[StingyJack]

It was not going to get support for TLS 1.2.

SQLOLEDB will not receive support for TLS 1.2. You will need to switch your driver to one of the supported drivers listed in https://support.microsoft.com/en-us/kb/3135244

From https://blogs.msdn.microsoft.com/sqlreleaseservices/tls-1-2-support-for-sql-server-2008-2008-r2-2012-and-2014/

I went looking again just now, and I've found "Yes it is possible", but this article wasnt available (or as easily findable) earlier this year when a customer provisioned a "new" Windows + SQL 2008R2 server with TLS 1.2 and FIPS enabled and I had to use the native client. Not a terrible workaround, but it required the installation of a component that wasn't present on a Validated System.