SQLNCLI is gone. MSOLEDBSQL enforces strict TLS. Your linked servers will break.

If you upgrade to SQL Server 2025 and your linked servers stop working, you are not alone. This is the single most common post-upgrade failure I am seeing right now, and it hits almost every environment that has linked servers configured from an older version. SQLNCLI is gone. The replacement driver has different defaults. Your connections will fail unless you explicitly tell them how to encrypt.

What Changed

SQL Server 2025 uses Microsoft OLE DB Driver 19 (MSOLEDBSQL) as the default provider for linked servers. Previous versions used SQLNCLI (SQL Native Client), which Microsoft deprecated in 2022 and has now been entirely removed.

This matters because OLE DB Driver 19 introduces a breaking change: the Encrypt parameter is no longer optional. If you do not set it explicitly, the driver defaults to Encrypt=Mandatory and requires a valid CA-signed certificate. Self-signed certificates are rejected. TrustServerCertificate defaults to False.

Every linked server that was created with SQLNCLI, every linked server that relied on default encryption settings, and every linked server connecting to an instance with a self-signed cert — they will all fail after the 2025 upgrade.

Break It, Fix It

I have two local instances: SQL Server 2025 and SQL Server 2022. From the 2025 instance, I created a linked server to the 2022 instance using MSOLEDBSQL but without specifying an Encrypt parameter:

-- On the 2025 instance, pointing at the 2022 instance
EXEC master.dbo.sp_addlinkedserver 
    @server     = N'TEST_LINK_2022', 
    @srvproduct = N'', 
    @provider   = N'MSOLEDBSQL', 
    @datasrc    = N'SQLFINGERSMINI';
GO

SELECT * FROM OPENQUERY(TEST_LINK_2022, 'SELECT @@VERSION');
GO

The linked server creates without error, but my OPENQUERY call to test fails with this:

OLE DB provider "MSOLEDBSQL19" for linked server "TEST_LINK_2022" returned message 
"Client unable to establish connection. For solutions related to encryption errors, 
see https://go.microsoft.com/fwlink/?linkid=2226722"
Msg -2146893019, Level 16, State 1, Line 10
SSL Provider: The certificate chain was issued by an authority that is not trusted.

Again, the linked server was created successfully. No warning, no error. It just failed when I tried to use it. That is what makes this dangerous during an upgrade -- nothing is going to tell you your linked servers are broken until traffic hits them.

Now drop it and recreate it with an explicit Encrypt and TrustServerCertificate:

EXEC master.dbo.sp_dropserver @server = N'TEST_LINK_2022', @droplogins = 'droplogins';
GO

EXEC master.dbo.sp_addlinkedserver 
    @server     = N'TEST_LINK_2022', 
    @srvproduct = N'', 
    @provider   = N'MSOLEDBSQL', 
    @datasrc    = N'SQLFINGERSMINI',
    @provstr    = N'Encrypt=Yes;TrustServerCertificate=Yes';
GO

SELECT * FROM OPENQUERY(TEST_LINK_2022, 'SELECT @@VERSION');
GO

This time it works. The connection is encrypted, and the driver accepts the self-signed certificate on the 2022 instance.

The @provstr I used — Encrypt=Yes;TrustServerCertificate=Yes — encrypts the connection but accepts self-signed certificates. That is the fix for most environments. If you have proper CA-signed certificates deployed, use Encrypt=Strict for full TDS 8.0 / TLS 1.3 validation — that is where Microsoft wants everyone to land. If everything is broken and you need linked servers talking again immediately, Encrypt=Optional removes the encryption requirement entirely — no certificate validation, no mandatory TLS, same as SQLNCLI used to be. Use it for a fast fix, then take the time to remedy things properly.

Before You Upgrade

Run this on every instance you plan to upgrade. It shows every linked server, its provider, and its current encryption settings:

SELECT 
    s.name            AS linked_server,
    s.provider        AS ole_db_provider,
    s.data_source     AS data_source,
    s.provider_string AS provider_string,
    l.uses_self_credential,
    l.remote_name
FROM sys.servers s
LEFT JOIN sys.linked_logins l 
    ON s.server_id = l.server_id
WHERE s.is_linked = 1
ORDER BY s.name;
GO

Any row where ole_db_provider is SQLNCLI or SQLNCLI11 will break — that provider no longer exists in 2025. Any row where provider_string is NULL or missing an explicit Encrypt setting will break — the driver defaults to mandatory encryption with full certificate validation. Fix them before the upgrade.

OR, you can use trace flag 17600 as a temporary workaround. Enabling global trace flag 17600 on your SQL Server 2025 instance changes the new default behavior, reverting it to the less-strict security standards of the OLE DB version 18 provider. This will allow unencrypted connections and any connections using self-signed certificates (where TrustServerCertificate=True is implied) to function without immediate reconfiguration.

It will buy you some time, but it is not a permanent fix.

Bottom Line

Microsoft followed through on a deprecation this time. SQLNCLI is gone, and the replacement enforces certificate validation by default. Every linked server created with default settings on 2022 or earlier needs to be recreated with an explicit Encrypt parameter. This fix takes very little time, but it is definitely needed.

If you are planning a SQL Server 2025 upgrade and want a second set of eyes on your linked servers or other configurations before you pull the trigger — let's talk. This is what I do.

More to Read:

Microsoft: Breaking Changes to Database Engine Features in SQL Server 2025
Microsoft: Linked Servers - Encryption Defaults and OLE DB 19
Aaron Bertrand: SQL Server 2025 Upgrade Lessons Learned
Brent Ozar: Known Issues So Far in SQL Server 2025