Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Applies to:
SQL Server 2025 (17.x)
This article describes the breaking changes to features in the SQL Server Database Engine introduced with SQL Server 2025 (17.x). These changes can break applications, scripts, or functionalities that are based on earlier versions of SQL Server.
Linked server connections fail after an upgrade
SQL Server 2025 (17.x) includes changes to encryption that introduce a breaking change to linked servers. These changes can break applications, scripts, or functionalities that are based on earlier versions of SQL Server.
When you upgrade from previous versions of SQL Server to SQL Server 2025 (17.x) with Microsoft OLE DB Driver 19, existing linked server configurations might fail. Different default values for the encryption parameter might cause this failure unless a valid certificate is provided.
In SQL Server 2025 (17.x):
- Linked servers to instances of SQL Server 2025 must use the
Encryptparameter in the connection string - When you migrate from previous editions of SQL Server to SQL Server 2025 with Microsoft OLE DB Driver 19, existing linked server configurations can fail
For information about how to connect securely to SQL Server 2025 (17.x) instances, see TDS 8.0.
Replication components fail after an upgrade
SQL Server 2025 (17.x) includes changes to encryption that introduce a breaking change to Transactional, Snapshot, Peer-to-peer, and Merge replication.
Replication components might fail after an upgrade to SQL Server 2025 (17.x) from all previous versions of SQL Server, if your SQL Server instance:
- Is configured as a replication publisher.
- Has a remote distributor in the replication topology.
- Isn't configured with a trusted certificate.
You might see the following behavior after the upgrade:
- Replication continues to succeed but changes to the publication fail.
- Replication Monitor in SQL Server Management Studio (SSMS) fails.
- Agent status in the SSMS UI fails.
A remote distributor uses a linked server for communication between the publisher and distributor. The secure default introduced in SQL Server 2025 (17.x) of the OLEDB 19 provider requires that TrustServerCertificate=False.
You can resolve this issue preemptively before you start the upgrade, or you can resolve the issue if replication components fail after an upgrade.
Before starting the upgrade
If you know that your SQL Server instance is going to encounter this issue after an upgrade, you can preemptively mitigate the failure by configuring the SQL Server instance to use a public commercial certificate or a certificate from an internal certificate authority.
This is the recommended option for maximum security.
Failed components after an upgrade
If your replication components fail after an upgrade, you can still configure the SQL Server instance to use a public commercial certificate or a certificate from an internal certificate authority.
Alternatively, you can choose the less secure option to override the secure default of the OLEDB 19 provider and set trust_distributor_certificate=yes so the distributor trusts the self-signed certificate.
To override the new secure default, use the sp_changedistributor_property stored procedure to set the trust_distributor_certificate option to yes:
EXECUTE sp_changedistributor_property
@property = N'trust_distributor_certificate',
@value = N'yes';
Note
Secure defaults pertain to the underlying OLEDB provider 19, which enhances security. The option to override the default is less secure than configuring your instance to use a trusted certificate. After overriding the default, you have the option to configure SQL Server to use a certificate, and then use the sp_changedistributor_property stored procedure to set the trust_distributor_certificate=no property back to the secure default.
Adding a remote replication distributor fails
SQL Server 2025 (17.x) includes changes to encryption that introduce a breaking change to Transactional, Snapshot, Peer-to-peer, and Merge replication.
When configuring a distributor for replication, the sp_adddistributor stored procedure fails when:
- The publisher is a SQL Server 2025 (17.x) instance.
- The distributor is remote.
- The distributor isn't configured with a trusted certificate.
You might see the following error when running sp_adddistributor on the publisher instance:
OLE DB provider "MSOLEDBSQL19" for linked server "repl_distributor" returned message
"Client unable to establish connection".
Msg -2146893019, Level 16, State 1, Line 21
SSL Provider: The certificate chain was issued by an authority that is not trusted.
A remote distributor uses a linked server for communication between the publisher and distributor. The secure default introduced in SQL Server 2025 (17.x) of the OLEDB 19 provider requires that TrustServerCertificate=False.
To resolve this issue, configure the distributor SQL Server instance to use a public commercial certificate or a certificate from an internal certificate authority.
Alternatively, you can choose the less secure option to override the secure default of the OLEDB 19 provider and set TrustServerCertificate=True so the distributor trusts the self-signed certificate. To override the default, use the trust_distributor_certificate parameter when calling the sp_adddistributor stored procedure:
EXECUTE sys.sp_adddistributor @trust_distributor_certificate = 'yes';
Note
Secure defaults pertain to the underlying OLEDB provider 19, which enhances security. The option to override the default is less secure than configuring your instance to use a trusted certificate. After overriding the default, you have the option to configure SQL Server to use a certificate, and then use the sp_changedistributor_property stored procedure to set the trust_distributor_certificate=no property back to the secure default.
Remote log shipping monitoring can break
SQL Server 2025 (17.x) includes changes to encryption that introduce a breaking change to log shipping. You might encounter these issues when you upgrade.
Log shipping monitoring can break if the monitor is a remote SQL Server 2025 (17.x) instance when other SQL Server instances in the log shipping topology use a previous version.
For information about how to connect securely to SQL Server 2025 (17.x) instances, see TDS 8.0.
Full-Text queries and populations fail after upgrade
SQL Server 2025 (17.x) removes all legacy word breaker and filter binaries used by Full-Text Search. These components are rebuilt with a modern toolset and offer expanded support for more languages and document types. Existing indexes after upgrade are designated with index_version = 1 as per sys.fulltext_indexes. Newly created indexes are designated version 2 and use the new components, unless otherwise specified using the FULLTEXT_INDEX_VERSION database scoped configuration.
Any Full-Text query on a version 1 index fails to find the word breaker binaries on disk immediately after upgrade:
Msg 30010, Level 16, State 2, Line 8
An error has occurred during the full-text query. Common causes include: word-breaking errors or timeout, FDHOST permissions/ACL issues, service account missing privileges, malfunctioning IFilters, communication channel issues with FDHost and sqlservr.exe, etc. If recently performed in-place upgrade to SQL2025, For help please see https://aka.ms/sqlfulltext.
Similarly, any Full-Text population issued on a version 1 index fails to find the filter binaries on disk after upgrade:
Warning: No appropriate filter was found during full-text index population for table or indexed view '[db].[dbo].[table_name]' (table or indexed view ID '901578250', database ID '5'), full-text key value '1'. Some columns of the row were not indexed.
Rebuild existing indexes with new version
The recommended way to continue using your indexes is to rebuild them with the newer version 2 components.
-- Verify value = 2
SELECT *
FROM sys.database_scoped_configurations
WHERE [name] = 'FULLTEXT_INDEX_VERSION';
-- Per catalog upgrade
ALTER FULLTEXT CATALOG [FtCatalog] REBUILD;
The only method to upgrade individual indexes without rebuilding the entire catalog is to drop and recreate them.
Keep using version 1
If it's necessary to remain on version 1 for application compatibility, first ensure you set FULLTEXT_INDEX_VERSION = 1 to avoid an unintended upgrade on rebuild.
ALTER DATABASE SCOPED CONFIGURATION
SET FULLTEXT_INDEX_VERSION = 1;
You must then copy the legacy word breaker and filter binaries from an older instance to the target instance's binn folder.