SQL Server 2025 Encryption Changes and the @@SERVERNAME Linked Server Problem

SQL Server 2025 Encryption Changes and the @@SERVERNAME Linked Server Problem

Last updated: 2026-08-21

Table of Contents

Why Microsoft Changed the OLE DB Driver

SQL Server 2025 (17.x) removes the SQL Server Native Client (SQLNCLI) OLE DB provider. The Microsoft OLE DB Driver 19 for SQL Server (MSOLEDBSQL19) is the default OLE DB provider for linked servers. This driver adds support for TDS 8.0 and TLS 1.3.

In OLE DB Driver 18 and earlier versions, the Encrypt setting had a default value of No. A linked server connection with no explicit Encrypt setting ran without encryption. Microsoft changed this default to close that security gap.

In OLE DB Driver 19, the Encrypt setting has a default value of Mandatory. A linked server connection must have encryption, unless the connection string sets Encrypt to No or Optional. This new default value is the primary cause of linked server failures after an upgrade to SQL Server 2025.

For more information, see MSOLEDBSQL Major Version Differences, Microsoft Learn.

The Certificate Requirement

A connection with Encrypt set to Yes, True, or Mandatory must have a certificate from a trusted certificate authority. The certificate must match the fully qualified domain name (FQDN) of the target server. OLE DB Driver 19 does not accept a self-signed certificate for this mode.

OLE DB Driver 19 also adds a Strict mode for the Encrypt setting. Strict mode forces the use of TDS 8.0 and a valid CA-signed certificate. TrustServerCertificate has no effect in Strict mode.

The TrustServerCertificate setting is still available, and Microsoft does not recommend it for a production system. This setting turns off certificate validation. A connection with TrustServerCertificate set to Yes accepts a self-signed certificate, at a lower security level.

Note: OLE DB Driver 18 ignored TrustServerCertificate when the client set Encrypt to No, even if the server forced encryption. OLE DB Driver 19 evaluates TrustServerCertificate in every encrypted session. A connection string that relied on the previous behavior of TrustServerCertificate can fail, or connect at a lower security level than before.

Why data access and provider string matter for @@SERVERNAME

A distributed query against the local server, through a four-part name or OPENQUERY, must have a linked server entry for that server. Microsoft Learn documents this requirement for the data access option of sp_serveroption. This option works only for a sys.servers entry added through sp_addlinkedserver.

A fresh SQL Server instance has no such entry for its own name. An administrator must add one, with sp_addlinkedserver, before sp_serveroption can turn on data access for it. Without this step, a four-part name query against the local server fails, with an error about a server not configured for data access. For example, this query has the form [ServerName].[Database].[Schema].[Table].

The provider string option of sp_serveroption sets the OLE DB connection string for that linked server entry. On SQL Server 2025, this string must have an explicit Encrypt setting. Without an explicit Encrypt setting, the loopback connection defaults to Encrypt=Mandatory. This connection then fails, unless the instance trusts its own certificate, or the provider string sets TrustServerCertificate to Yes.

This document presumes @@SERVERNAME is set properly, and that a linked server entry with that name already exists, added through sp_addlinkedserver.

Procedure: Connect to @@SERVERNAME as a Linked Server

Do this procedure on the target SQL Server 2025 instance. Use an account with the sysadmin role, or with the permission named ALTER ANY LINKED SERVER.

  1. Turn on distributed query access for the @@SERVERNAME linked server. Run sp_serveroption, with the data access option set to true.
  2. Set the connection security options for the @@SERVERNAME linked server. Run sp_serveroption, with the provider string option.
  3. Do a test of the linked server. Run sp_testlinkedserver, with the server name as the argument.

These commands set TrustServerCertificate to Yes as a temporary measure. Install a full CA-signed certificate as the primary target.

EXEC master.dbo.sp_serveroption @server=@@SERVERNAME, @optname=N'data access',     @optvalue=N'true';
EXEC master.dbo.sp_serveroption @server=@@SERVERNAME, @optname=N'provider string', @optvalue=N'Encrypt=Yes;TrustServerCertificate=Yes;MultiSubnetFailover=Yes;';

EXEC master.dbo.sp_testlinkedserver @servername = @@SERVERNAME;

Note: TrustServerCertificate=Yes accepts a self-signed certificate. This setting is a lower-security fallback, compared to a certificate from a trusted certificate authority.

Install a certificate from a trusted certificate authority, for the primary, more secure configuration.

Microsoft recommends a certificate-based fix. TrustServerCertificate is the less secure alternative. The two paths are:

  • Recommended path: a certificate from a commercial certificate authority, or from an internal certificate authority that every client already trusts. This path does not change the Encrypt or TrustServerCertificate values.
  • Fallback path: an explicit Encrypt value (Optional, or Mandatory with TrustServerCertificate=Yes) in the provider string. This path is faster, but it works at a lower security level.

Trace flag 17600 is a third, instance-wide option, separate from the two paths above. Microsoft documents this trace flag as a temporary measure. This trace flag restores the OLE DB Driver 18 default behavior for the whole instance. This is a lower security level than the SQL Server 2025 default. Trace flag 17600 is not a substitute for a per-connection Encrypt setting or a trusted certificate.

Sources

Comments

Post a Comment

Popular posts from this blog

Windows Server Failover Clustering/SQL Server Firewall Access Rules

This document defines the firewall rules required for a Multi-Subnet Windows Server Failover Cluster (WSFC) environment. It covers WSFC core communication, the WSFC dependency on Active Directory (AD), and SQL Server Availability Group (AG) communication. Use these rules when you request network access for a Multi-Subnet Cluster. This version corrects several rows to agree with current Microsoft documentation. See Verification Notes at the end of this document for the list of changes and sources. Table of Contents Best Practice: IP Specificity Critical Action: Review Ephemeral Port Ranges Section 1: Core WSFC and Active Directory Ports Section 2: SQL Server Database Engine and Availability Group Ports Section 3: SQL Server BI Stack Ports (Conditional) Section 4: Multi-Subnet / Cloud Deployment Ports (Conditional) Section 5: Official References Verification Notes Windows Server 2025 / SQL Server 2025 Notes Best Practice: IP Specificity Specify exact IP ad...
Read more

Windows Server Recommendations For AWS

Windows Server Recommendations for AWS.md Windows Server Recommendations for AWS Overview This document gives a high-level recommendation for building a Windows Server EC2 host in AWS. It also covers support for Windows Server Failover Clustering (WSFC). Table of Contents Table of Contents Overview EC2 Host Recommendations EC2 Network Recommendations EC2 Security Recommendations Security Group 1: Internal Region Traffic Security Group 2: Inbound Windows and SQL Server Access Security Group 3: Outbound Access Security Group 4: Cross-Region WSFC and AG Traffic EC2 O/S Recommendations Operating System Image Network Configuration Drive Configuration Patching and Drivers Backups EC2 Host Recommendations This section gives recommendations for an EC2 host in AWS. It covers instance type and storage. Use the r6idn or i3en instance type for a SQL Server host in AWS. Both instance types come with NVMe SSD storage. Use the NVMe SSD storage for te...
Read more

Windows Server Failover Clustering Hotfixes for SQL Server AlwaysOn

Windows Server Failover Clustering/SQL Server Firewall Access Rules Last updated: 2026-08-21 17:01:33 This document defines the firewall rules necessary for a Multi-Subnet Windows Server Failover Cluster (WSFC) environment. It covers WSFC core communication, the WSFC dependency on Active Directory (AD), and SQL Server Availability Group (AG) communication. Use these rules when you request network access for a Multi-Subnet Cluster. This version corrects several rows to agree with current Microsoft documentation. See Verification Notes at the end of this document for the list of changes and sources. Table of Contents Windows Server Failover Clustering/SQL Server Firewall Access Rules Table of Contents Best Practice: IP Specificity Critical Action: Review Ephemeral Port Ranges Section 1: Core WSFC and Active Directory Ports Section 2: SQL Server Database Engine and Availability Group Ports Section 3: SQL Server BI Stack Ports (Conditional) Section 4: Multi-...
Read more