Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
If Configuration Manager logs show Failed to connect to the SQL Server together with The token supplied to the function is invalid or Cannot generate SSPI context, start by checking the site server’s Windows-authenticated connection to the SQL instance. Those messages point toward an authentication-path problem—often involving DNS, Kerberos/SPNs, or certificate settings—not automatically a damaged WMI repository or site database. Verify SQL availability, target name, port, account, and authentication in that order before changing configuration.
What “SMS Site Cannot Access SQL Server” means
“SMS” is legacy terminology that remains in Configuration Manager (ConfigMgr) component and log names. The site server’s SMS Executive components need access to the site database for site operations. A failure there can also make the console appear unusable, but the console symptom alone does not identify the failing layer.
- SMS Executive cannot connect to SQL Server: investigate the site-server-to-database path, including SQL availability, TCP connectivity, Windows authentication, permissions, and TLS.
- The console cannot connect to the SMS Provider: investigate provider availability, WMI, provider location, and console permissions—especially if SMS Executive can still reach SQL.
- SSMS connects but ConfigMgr fails: this is not proof that ConfigMgr’s path works. SSMS may use a different account, server name, driver, protocol, certificate behavior, or authentication method.
ConfigMgr uses Windows authentication for its site-database connection. TCP 1433 is the usual default for SQL Server, not a universal requirement; custom ports are valid when configured consistently. For a named SQL instance, use a predictable static port where required rather than relying on dynamic-port discovery. See Microsoft’s site database planning guidance for the applicable requirements.
Interpret the exact messages
Failed to connect to the SQL Server is a high-level symptom. It does not distinguish between a stopped SQL service, a wrong server or instance, a blocked port, failed name resolution, an authentication problem, missing permissions, or a TLS issue.
#1 Best Overall
The token supplied to the function is invalid is a more specific authentication-layer clue. When it appears alongside Cannot generate SSPI context, prioritize Windows-integrated authentication and Kerberos/SSPI checks rather than starting with database repair.
Microsoft identifies missing, duplicate, or incorrectly assigned SQL Server Service Principal Names (SPNs), DNS/name-resolution problems, service-account issues, and related Kerberos configuration as common causes of Cannot generate SSPI context. The message makes this a leading diagnostic path, but it does not by itself prove the root cause. Follow Microsoft’s SSPI troubleshooting guidance.
First, establish what changed
Write down when the failure began and what changed immediately beforehand. Check for changes to the SQL service account or its password, SQL instance or port, server aliases, certificates, forced encryption, firewall or domain policy, ConfigMgr updates, and SQL or Windows updates. Also note whether the site database was moved or another database was added to the SQL instance.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11In one reported SQL Server 2017 incident, the failure followed the addition of a VAMT database to the same SQL instance. The report also says that clearing the SQL Server PKI Client Certificate setting and restarting SQL restored access. That is a case-specific workaround, not evidence that the additional database caused the problem or that disabling a certificate is generally safe. The timing may reflect another configuration change or the effect of restarting SQL. See the incident report.
1. Record the actual SQL target
Before making changes, identify the values ConfigMgr is meant to use:
- SQL Server computer name and fully qualified domain name (FQDN)
- Instance name, if it is a named instance
- Configured TCP port
- ConfigMgr site code and site database name
- SQL Server service account
- Whether SQL is local or remote to the site server
- Any SQL client alias or DNS CNAME in the connection path
- Whether SQL Server forces encryption
Use the intended production name and port in your tests. Substituting an IP address or guessed instance name can change Kerberos SPN formation and hide, rather than repair, the original issue.
2. Check SQL service and database state
On the SQL Server, check the relevant service. For a default instance, run:
Recommended Free Tools
Get-Service -Name 'MSSQLSERVER','SQLSERVERAGENT','SQLBrowser' -ErrorAction SilentlyContinueFor a named instance, replace INSTANCE_NAME with the actual instance name:
Get-Service -Name 'MSSQL$INSTANCE_NAME','SQLAgent$INSTANCE_NAME','SQLBrowser' -ErrorAction SilentlyContinueConfirm that the SQL Server service is running. SQL Browser matters for some named-instance discovery paths; a successful direct connection to a known static port does not depend on guessing through discovery.
In SSMS, or another authorized SQL query session, verify that the ConfigMgr database exists and is online:
SELECT name, state_desc, user_access_desc, compatibility_level
FROM sys.databases
WHERE name = N'<ConfigMgrSiteDatabase>';If the database is not online, use the SQL error log and SQL Server diagnostics to determine why before attempting ConfigMgr-side changes. Do not alter compatibility level just because the value is unexpected. SQL Server 2017 is associated with compatibility level 140 in ConfigMgr planning material, but supported levels depend on the installed ConfigMgr version and upgrade history. Check the applicable Microsoft guidance before changing it.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →3. Verify DNS and TCP reachability from the site server
Run name-resolution checks from the site server, using the actual SQL names:
Resolve-DnsName <sql-server-fqdn>
Resolve-DnsName <sql-server-short-name>Both names should resolve consistently to the intended server. If they do not, investigate DNS records, suffixes, aliases, and stale or inconsistent records. Avoid treating a successful ping as proof that SQL is reachable: ICMP response does not test the SQL TCP port.
Test the configured SQL port directly. For a default instance using the standard port:
Test-NetConnection <sql-server-fqdn> -Port 1433For a named instance or custom configuration, use its actual static port:
Test-NetConnection <sql-server-fqdn> -Port <static-port>TcpTestSucceeded: False: verify the server name, SQL TCP/IP protocol, listening port, Windows Firewall, network firewalls, routing, and any security appliance between the hosts.TcpTestSucceeded: True: the TCP path is reachable, but authentication, certificate validation, database selection, or permissions may still fail.
On the SQL Server, inspect SQL Server Configuration Manager → SQL Server Network Configuration → Protocols for <instance> → TCP/IP → IP Addresses to confirm the port and listening configuration. For a named instance, use a static port when predictable connectivity is required, and ensure the firewall permits that port. Dynamic ports can also complicate SPN registration.
Rank #3
4. Test the relevant Windows identity and permissions
A successful connection made under a personal administrator account does not validate the identity ConfigMgr uses. Subject to your organization’s security policy, test with the relevant site-server computer account or configured site-system connection account. Check that accounts are enabled, not locked or expired, and have not been denied required access. Also check whether a SQL service-account password or logon change was made without updating the service configuration.
Inspect whether the relevant Windows principal still has its expected SQL login and database user. These queries are checks, not instructions to grant broad permissions:
SELECT sp.name, sp.type_desc, sp.is_disabled
FROM sys.server_principals AS sp
WHERE sp.name IN
(
N'<DOMAIN><SiteServerComputerAccount>$',
N'<DOMAIN><ConfigMgrConnectionAccount>'
);USE [<ConfigMgrSiteDatabase>];
SELECT dp.name, dp.type_desc
FROM sys.database_principals AS dp
WHERE dp.name IN
(
N'<DOMAIN><SiteServerComputerAccount>$',
N'<DOMAIN><ConfigMgrConnectionAccount>'
);Confirm the expected principals and permissions for your installed ConfigMgr version and topology. Do not grant sysadmin as a shortcut. Do not recreate or remove logins without version-specific guidance and a recovery plan. Older SMS-era examples—including login names such as SMS_SiteSystemtoSQLConnection_<sitecode>—are historical context, not a universal repair recipe for current ConfigMgr. See the archived legacy permission example only in that context.
Free tools Windows power users keep installed
One-click scans. No signup required.
5. If SSPI fails, check DNS, SPNs, and Kerberos
When the exact error is Cannot generate SSPI context, first confirm the server name resolves correctly. Then inspect the SQL Server SPNs and verify that they belong to the account running the SQL Server service. The required owner depends on the service identity: a domain service account normally owns the SQL SPNs; a service running as Local System may use the computer account.
Use Microsoft Kerberos Configuration Manager where permitted, or query SPNs with setspn:
setspn -Q MSSQLSvc/<sql-server-fqdn>:<port>
setspn -Q MSSQLSvc/<sql-server-short-name>:<port>
setspn -L <SQL-service-account>Look for an SPN that is missing, registered on the wrong account, or duplicated. Also consider SQL aliases, domain trust, and account rights needed for automatic SPN registration. Do not add SPNs speculatively; a duplicate or misassigned SPN can make authentication worse. If changes are needed, have an administrator correct them against the actual SQL service identity and Microsoft’s guidance.
After a verified correction, rerun the Kerberos check, restart services if required by the change, and retest from the site server. To inspect the authentication scheme for a remote SQL connection, run this in that connection:
SELECT net_transport, auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;A remote Windows-authenticated connection may use Kerberos or, in some topologies, NTLM. The result helps characterize the connection; it is not a reason to weaken authentication as a permanent fix.
Rank #4
- Mastering Active Directory: Design, deploy, and protect Active Directory Domain Services for Windows Server 2022, 3rd Edition
- ABIS BOOK
- Packt Publishing
6. Check certificate and encryption configuration
If the failure began after a certificate or encryption change—or if unencrypted connections work while encrypted ones fail—inspect the SQL Server certificate assignment and trust path. Check that the certificate is valid and unexpired, its subject name or SAN matches the name clients use, the SQL Server service account can access its private key, and the site server trusts the issuing root and intermediate certificates. Review forced-encryption settings and SQL Server, Windows System, and Schannel events for evidence.
The reported incident’s PKI Client Certificate workaround is a reason to investigate this branch, not to disable certificate validation by default. Microsoft documents that clients validating a SQL Server certificate must trust its chain; certificate-validation settings affect connection security. “Trust Server Certificate” can bypass validation in some client configurations, but it should not be treated as a permanent fix without an explicit security review and a plan to correct the certificate or trust problem. See Microsoft’s SQL Native Client configuration documentation.
7. Use the logs to correlate the failure
Collect logs covering the time of failure rather than relying on the console message alone. Useful evidence includes:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- ConfigMgr logs such as
SmsExec.log,Hman.log,SiteComp.log, andSitectrl.log - SQL Server error log
- Windows Application and System event logs
- Schannel and Kerberos/authentication-related events
- SQL Server Configuration Manager protocol and certificate settings
Log names and locations vary by ConfigMgr version and installation path. Use the log directory for the installed site rather than assuming a particular drive or folder.
Quick decision guide
| Finding | Next step |
|---|---|
| SQL service is stopped or the database is not online | Resolve the SQL startup, storage, recovery, or database-state issue and review SQL error logs before changing ConfigMgr. |
| TCP test to the intended port fails | Correct the target, TCP/IP listener, static port, firewall, or routing. Do not start by changing SPNs. |
| TCP works but Windows login fails | Check account status, domain trust, SQL login and database user, and the permissions expected by ConfigMgr. |
Cannot generate SSPI context appears |
Prioritize DNS, aliases, SPNs, SQL service-account identity and rights, and domain trust. |
| Only encrypted connections fail | Inspect forced encryption, certificate validity and name, private-key access, and client trust chain. |
| SSMS works but ConfigMgr does not | Compare account, target name, instance, port, driver, encryption, authentication scheme, alias, and database—not just whether a manual connection succeeds. |
| SMS Executive connects but the console cannot reach the provider | Investigate SMS Provider availability, WMI, provider location, and console permissions instead of assuming a SQL failure. |
Why a WMI reset is usually the wrong first step
A WMI repository reset does not address a SQL Server SSPI or TCP connection failure. It can create additional ConfigMgr problems or complicate recovery. Treat WMI as a separate diagnostic branch only when evidence points to the SMS Provider or WMI—not because the console is unavailable while SMS Executive reports a SQL authentication error.
Restart and verify safely
After correcting a specific, evidenced problem, restart only the affected services according to the change—for example, SQL Server if its service account, certificate, or relevant SQL configuration changed, and affected ConfigMgr services as appropriate. Then confirm that the site server can connect using the intended Windows identity and target, review fresh ConfigMgr and SQL logs, and verify that site operations resume. Avoid a broad restart or database restore as a substitute for identifying the failure.
If the SQL connection is healthy but the site remains impaired, investigate the relevant ConfigMgr component separately. Use a supported ConfigMgr maintenance or recovery path only when the evidence indicates site-configuration damage. Restore from a verified site backup only when database or site corruption is demonstrated; an authentication error alone is not evidence of corruption. SQL Server 2017 compatibility should also be checked against the exact installed ConfigMgr branch and servicing state rather than assumed from the SQL version alone.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsQuick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
