When working with legacy SSIS packages in Visual Studio 2019, it’s common to rely on OLE DB connections using SQL Server Native Client 11 (SQLNCLI11). This driver, though deprecated, is still widely used and can be configured to work securely with Azure SQL and TLS 1.2, even over VPN connections.

This article explains how to verify if your existing SQL Native Client is already TLS 1.2 compatible, and why it may still be the most reliable option when newer drivers like MSOLEDBSQL or ODBC 18 introduce installation or compatibility issues.

Context

In my project, most SSIS packages were built using OLE DB via SQLNCLI11, and I needed to ensure:

  • Compatibility with Azure SQL
  • Encryption over TLS 1.2
  • Smooth development in Visual Studio 2019 on Windows Server 2016

What Is SQL Native Client QFE?

QFE (Quick Fix Engineering) is a patched version of the standard SQL Native Client driver. It includes:

  • Support for TLS 1.2
  • Security fixes and minor improvements
  • Compatibility with modern SQL Server and Azure SQL endpoints

Microsoft doesn’t label it differently in the driver name, but the version number reveals everything.

How to Check Your SQL Native Client Version

To confirm if your current driver supports TLS 1.2, run the following command from Command Prompt:

You should see output like this:

If the version is 11.4.7001.0 or higher — you’re good. TLS 1.2 is fully supported.

Connection String for Azure SQL

If you’re connecting to Azure SQL or through a VPN to a TLS-secured endpoint, your connection string should look like:

  • Encrypt=yes ensures data is transmitted securely
  • TrustServerCertificate=no validates SSL certificates properly (recommended)

What If You Have an Older Version?

If the version is below 11.4.7001.0, download and install the latest QFE build of SQL Native Client:

https://www.microsoft.com/en-us/download/details.aspx?id=50402

This will upgrade your driver to a TLS 1.2-compatible version.

Why Not Just Use MSOLEDBSQL or ODBC 18?

While MSOLEDBSQL and ODBC 18 are the official modern replacements, installing their 32-bit versions on 64-bit Windows systems often fails silently or is explicitly unsupported.

Microsoft has tightened restrictions in newer versions, meaning you may not be able to install both 32-bit and 64-bit versions side-by-side, a requirement for SSIS development in Visual Studio 2019, which only supports 32-bit drivers at design time.

According to Microsoft documentation and installation behavior since ODBC 18.2 and MSOLEDBSQL 18.6, side-by-side support has been phased out.

On most systems, installing the 32-bit version after the 64-bit version will throw a “not supported on this operating system” error or be blocked by shared component conflicts.

References:

This makes SQLNCLI11, though deprecated, a far more reliable choice in environments where compatibility and ease of setup still matter.

Conclusion

If you’re maintaining SSIS packages using SQL Native Client 11 on Windows Server 2016 or later:

  • Use the QFE-patched version (11.4.7001.0 or higher)
  • Confirm TLS 1.2 support via Registry or PowerShell
  • Use proper encryption flags in your connection string

This lets you keep using your existing packages securely, including connecting to Azure SQL over VPN, without rewriting for newer drivers.

And given the current limitations of newer driver installations in mixed architecture environments, SQLNCLI11 remains a practical and effective solution.

Leave A Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.