Symptom
A linked server query that worked before patching now fails every time:
Msg 7416, Level 16
Access to the remote server is denied because no login-mapping exists.
It's not intermittent; it fails consistently after the update.
Cause
Microsoft lists this as a known issue in the September and October 2026 update KBs:
- It affects linked servers using the MSDASQL provider (OLE DB Provider for ODBC Drivers) that specify a provider string (
@provstr). - "A stricter connection validation check in the Database Engine can reject connections for certain linked server configurations that use the MSDASQL provider, even if earlier builds allowed those connections."
The KBs point to a separate Microsoft troubleshooting article, Linked server queries that use MSDASQL fail with error 7416, for workarounds. Read that article for your build; the steps below are the checks to run alongside it.
1. Find affected linked servers
SELECT s.name, s.provider, s.data_source, s.provider_string,
l.uses_self_credential, l.remote_name,
CASE WHEN l.local_principal_id = 0 THEN '(all logins)' ELSE SUSER_NAME(l.local_principal_id) END AS local_login
FROM sys.servers s
LEFT JOIN sys.linked_logins l ON l.server_id = s.server_id
WHERE s.is_linked = 1 AND s.provider = 'MSDASQL';
The ones at risk have a non-empty provider_string.
2. Check the login mapping
Error 7416 talks about login mapping. Older builds tolerated linked servers that relied on credentials inside the provider string (for example UID=...;PWD=... in @provstr) with no proper mapping in sys.linked_logins. Make the mapping explicit:
EXEC master.dbo.sp_addlinkedsrvlogin
@rmtsrvname = N'PG_REPORTING',
@useself = N'False',
@locallogin = NULL, -- or a specific login
@rmtuser = N'report_reader',
@rmtpassword= N'<from your secret store>';
Then remove credentials from the provider string so they aren't stored in two places.
3. Check the provider string for a user ID
The October 2026 update for SQL Server 2022 (KB5128493) lists a fix: MSDASQL-linked server connections fail if the provider string does not include a user ID. That suggests the check looks at the provider string's contents. If your build doesn't include that fix, consider including the user ID in the provider string as well as the mapping. Test which combination works on your build.
4. Test
SELECT TOP (1) * FROM OPENQUERY(PG_REPORTING, 'SELECT 1 AS ok');
EXEC sp_testlinkedserver N'PG_REPORTING';
5. If you can't fix it before a deadline
- Remove the update from that server (uninstall the KB) as a short-term measure, and plan to re-apply once the configuration is fixed. You lose the security fixes while it's off, so keep this short.
- Or replace the linked server for that workload: an SSIS/ADF copy, or a direct ODBC connection from the application.
Linked servers to non-SQL Server databases through MSDASQL are often the most fragile part of an estate. This is a good moment to list them and decide which still need to exist. See also linked server gaps when moving to Azure SQL.
Checklist
- MSDASQL linked servers with provider strings listed
- Explicit login mappings created; credentials removed from provider strings
- Builds checked for the "provider string without user ID" fix
- Each linked server tested with OPENQUERY and sp_testlinkedserver
- Uninstall used only as a short, tracked exception