SMS_SITE_COMPONENT_MANAGER fails due to SQL Kerberos SPN conflict

Question

SMS_SITE_COMPONENT_MANAGER fails due to SQL Kerberos SPN conflict

choukri Bouchaib AdminSCCM, IT_Specialist 0

Environment:

SCCM CB 2603 Site Server
Remote SQL Instance (Port 1433)

Issue:

SMS_SITE_COMPONENT_MANAGER stays in Running state but fails to create SMS_EXECUTIVE due to Kerberos authentication failure with SQL Server.

Validations Completed:

Windows ADK, IIS (AppPools started), WSUS, ODBC drivers, and network ports (1433/80/8530) are 100% operational.
Database permissions (sysadmin, db_owner) are confirmed.
setspn -S reveals a duplicate SPN registered on a user account instead of the SQL service/machine account.

Questions:

Once the duplicate SPN is removed from Active Directory, will restarting SMS_SITE_COMPONENT_MANAGER automatically create SMS_EXECUTIVE, or is a site reset (setup.exe /reset) required?
Are there specific Kerberos caches to clear on the site server besides klist purge?

0 comments

2 answers

Your answer

Answer 1

hI error when I open the Console Configuration Manager

he Configuration Manager console cannot connect to the Configuration Manager site database. Verify the following:

  •	This computer has network connectivity to the SMS Provider computer.

  •	Your user account has Remote Activation permission on the Configuration Manager site server and the SMS Provider computer.

  •	The Configuration Manager console version is supported by the site server.

  •	You are assigned to at least one role-based administration security role.

  •	You have the following WMI permissions to the Root\SMS and Root\SMS\site_<site code> namespaces: Execute Methods, Provider Write, Enable Account, and Remote Enable.

Answer 2

Restart SMS_SITE_COMPONENT_MANAGER after correcting and verifying the SQL SPNs; it is responsible for installing and starting SMS_EXECUTIVE, so a site reset is not the first recovery action.^1^

Recommended recovery sequence

Remove the misplaced SPN and register it on the account running SQL Server. For a static TCP 1433 instance, check both the short name and FQDN:
```
   setspn -Q MSSQLSvc/sqlserver:1433
   setspn -Q MSSQLSvc/sqlserver.contoso.com:1433
   setspn -L CONTOSO\SqlServiceAccount
```
Remove each incorrect registration from the user account, then add it to the actual SQL Server service account:
```
   setspn -D MSSQLSvc/sqlserver:1433 CONTOSO\WrongAccount
   setspn -D MSSQLSvc/sqlserver.contoso.com:1433 CONTOSO\WrongAccount

   setspn -S MSSQLSvc/sqlserver:1433 CONTOSO\SqlServiceAccount
   setspn -S MSSQLSvc/sqlserver.contoso.com:1433 CONTOSO\SqlServiceAccount
```
Use -S, rather than -A, when adding SPNs because it checks for duplicates. A misplaced SPN can prevent Kerberos authentication, and each SQL SPN must map uniquely to the account that starts the SQL Server service.^2^
Verify that no duplicate or missing SQL SPN remains. Re-run the setspn -Q commands. Alternatively, run Kerberos Configuration Manager against the SQL Server and confirm the relevant entries report Good. The tool can detect misplaced, missing, and duplicate SPNs; after a correction, Microsoft recommends running it again to verify the result.^3^
Clear tickets used by both the interactive administrator and Local System on the site server. Run from an elevated command prompt:
```
   ipconfig /flushdns
   klist purge
   klist purge -li 0x3e7
```
Plain klist purge clears tickets only for the current logon session. 0x3e7 identifies the Local System logon session, which is relevant to services running under that security context. Microsoft’s Kerberos troubleshooting sequence includes both ticket purges and the DNS cache flush.^4^ No additional Configuration Manager-specific Kerberos cache is documented. A reboot is normally unnecessary at this stage. Be aware that purging tickets can temporarily interrupt access until new tickets are obtained.^5^
Restart Site Component Manager.
```
   Restart-Service SMS_SITE_COMPONENT_MANAGER
```
Site Component Manager should retry installation/startup of SMS_EXECUTIVE. Monitor:
- sitecomp.log for the component installation attempt and SQL-related errors.
- Windows Services for SMS_EXECUTIVE.
- smsexec.log after the service appears and starts.
Confirm the new SQL connection uses Kerberos. From a new remote Windows-authenticated SQL connection, run:
```
   SELECT
       net_transport,
       auth_scheme,
       client_net_address
   FROM sys.dm_exec_connections
   WHERE session_id = @@SPID;
```
The expected auth_scheme is KERBEROS; merely establishing a successful connection does not prove Kerberos was selected.^6^

When to use a site reset

Use a site reset only if all of these are true:

The corrected SPNs are unique and assigned to the SQL service account.
A newly established remote connection reports KERBEROS.
Restarting SMS_SITE_COMPONENT_MANAGER still does not recreate or start SMS_EXECUTIVE.
sitecomp.log continues to show component installation failure rather than an unresolved SQL authentication error.

A site reset is the broader repair action: it reapplies default Configuration Manager permissions, reinstalls site components and roles, removes and recreates the SMS Executive component, and restarts Site Component Manager so it can install SMS_EXECUTIVE and SMS_SQL_MONITOR.^7^

Run it on the primary site server using the installed version of Setup:

Open <ConfigMgr installation path>\BIN\X64\setup.exe.
Select Perform site maintenance or reset this site.
Select Reset site with no configuration changes.
Confirm the reset.

The account must be a local administrator on the primary site server and have permissions equivalent to the Configuration Manager Full Administrator role. In a hierarchy with a CAS, it must also be a local administrator on the CAS.^7^

References