Observability
CertificateManagementService fails to reconnect to SQL after Application Pool recycle after upgrading to SolarWinds Platform 2025.2.x
This article provides information about an issue where the CertificateManagementService (CMS) fails to reconnect to the SQL Server database after an IIS Application Pool recycle on the SolarWinds Platform. The issue occurs in environments using SQL Server Always On Availability Groups (AG).
First published date
Last published date
Overview
In certain environments, particularly those using SQL Server Always On Availability Groups (AG), the SolarWinds CertificateManagementService (CMS) may fail to reconnect to the database after the SolarWinds Orion Application Pool is recycled.
This typically occurs during the scheduled WebsiteMaintenance.exe task, which triggers an IIS Application Pool recycle as part of daily database maintenance. While other services reconnect to SQL successfully, CMS may log repeated connection errors and remain disconnected.
The issue can also be reproduced by manually recycling the SolarWinds Orion Application Pool.
Example CMS log entries:
ERROR Grpc.AspNetCore.Server.ServerCallHandler - (null) Error when executing service method 'GetTrustedCertificates'.
Microsoft.Data.SqlClient.SqlException (0x80131904): A network-related or instance-specific error occurred while establishing a connection to SQL Server.
The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections.
(provider: TCP Provider, error: 0 - The wait operation timed out.)
---> System.ComponentModel.Win32Exception (258): The wait operation timed out.Product section
Cause
- The CMS service runs on .NET 8 and uses the Microsoft.Data.SqlClient provider, while most other SolarWinds services run on .NET Framework 4.8 with System.Data.SqlClient.
- In environments with SQL Server Always On AG listeners, CMS may require the parameter MultiSubnetFailover=True in its connection string to properly reconnect after failovers or IP changes.
- In some cases, the SolarWinds Configuration Wizard does not automatically add MultiSubnetFailover=True to the connection string (e.g., when re-running CW on an existing configuration, or depending on AG subnet detection).
As a result, CMS may fail to reconnect to SQL after the IIS Application Pool is recycled.
Resolution
Use Configuration Wizard to enable multi-subnet failover (SolarWinds Platform 2026.1 and later)
In environments that use SQL Server Always On Availability Groups (AG) or a SQL listener spanning multiple subnets, the CertificateManagementService (CMS) may require MultiSubnetFailover=True in its connection string to successfully reconnect to SQL after an IIS Application Pool recycle or failover. Previously, this parameter had to be added manually to the SWNetPerfMon.DB connection string. In some scenarios, the Configuration Wizard (CW) either did not run the Always On detection step or failed to detect that MultiSubnetFailover=True was required, and later CW runs could remove a manually added parameter from the connection string.
Starting in SolarWinds Platform 2026.1, the Configuration Wizard includes a Force-enable multi-subnet failover checkbox that explicitly controls whether CW attempts to add MultiSubnetFailover=True to the connection string.
Use this option if:
-
Your Orion / Hybrid Cloud Observability database is in a SQL Server Always On AG or is accessed via a multi-subnet listener.
-
CMS (running on .NET 8 with
Microsoft.Data.SqlClient) experiences intermittent or repeated connection errors after Application Pool recycles or maintenance, and logs timeouts when connecting to SQL.
To enable multi-subnet failover support through Configuration Wizard:
-
Run the Configuration Wizard on the SolarWinds server.
-
On the Database Settings step, select Force-enable multi-subnet failover.
-
Complete the wizard.
When this checkbox is selected, or when CW successfully detects SQL Always On, CW attempts to add MultiSubnetFailover=True to the connection string and keeps it there if the connection test succeeds; otherwise, the connection string remains unchanged.
Your selection is stored in the registry and is reused the next time you run the Configuration Wizard, so you generally do not have to re-enable the checkbox on subsequent CW runs:
-
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\SolarWinds.Net\SWNetPerfMon\Wizard\Force-Enable Multi-Subnet Failover
This checkbox is intended to prevent scenarios where CMS loses database connectivity after maintenance or failover because MultiSubnetFailover=True is missing from the connection string, and where prior manual edits were reverted by later CW runs.
-----------
To manually update the connection string used by SolarWinds to include the MultiSubnetFailover parameter:
- On the SolarWinds server, confirm the AG listener DNS resolves correctly:
Example:nslookup <AG_Listener_FQDN>nslookup aglistener01.domain.local - Remove any manual HOSTS file overrides pointing to the AG listener.
- Location: C:\Windows\System32\drivers\etc\hosts
- Edit the SWNetPerfMon.DB file (default path: C:\Program Files\SolarWinds\Orion\SWNetPerfMon.DB).
- Locate the line starting with ConnectionString=provider:
- Add the following property at the end of the connection string:
;MultiSubnetFailover=True - Save the file.
- Restart the CertificateManagementService (CMS).