STARLIMS Advanced Analytics (AA) dashboards fail to load and the connection test fails, although the network is reachable and nothing was deployed. A common cause is that the STARLIMS application pool runs under a custom domain or service account instead of NetworkService.
Symptoms
- AA dashboards fail to load.
- Administration > Advanced Analytics Settings > Test Connection fails.
- Port-level checks between the servers show no blocked traffic.
- No deployment or application change was made around the time the issue began.
- In an environment with more than one application server: the same web.config is used everywhere, and AA keeps working on the servers whose application pool still runs as NetworkService.
Cause
The application pool identity (IIS Manager > Application Pools > Advanced Settings > Process Model > Identity) was changed from NetworkService to a custom domain or service account.
AA relies on resources that depend on the user profile of the account running the pool: cryptographic key stores, temp paths and environment variables. With a custom account these are only available when the account has a Windows user profile on the server and Load User Profile is True for the pool. Otherwise the AA connection fails without an obvious error, even if the account has sufficient permissions for network and file access. NetworkService works without this additional configuration.
Resolution
Option A: Run the application pool as NetworkService
Quickest option. Choose it if no custom service account is required.
- Open IIS Manager on the application server.
- Go to Application Pools, select the STARLIMS application pool and open Advanced Settings.
- Under Process Model > Identity, set the value to NetworkService.
- Recycle the application pool.
- In STARLIMS go to Administration > Advanced Analytics Settings and select Test Connection to verify.
Option B: Keep the custom account and enable Load User Profile
Use this option if the custom account is required, for example for Kerberos delegation or access to specific network resources.
- Open IIS Manager on the application server.
- Go to Application Pools, select the STARLIMS application pool and open Advanced Settings.
- Under Process Model > Identity, confirm the custom account is set.
- In the same Process Model section, set Load User Profile to True.
- Recycle the application pool.
- In STARLIMS go to Administration > Advanced Analytics Settings and select Test Connection to verify.
Important: The custom account must have a Windows user profile on the server. If the account has never logged on interactively, log in once as that account before recycling the pool.
In an environment with more than one application server, apply the change on every server that runs the pool under the custom account.
Why port tests alone are not sufficient
A successful telnet or Test-NetConnection result only confirms TCP reachability. It does not exercise the TLS handshake, certificate validation or authentication.
To test the .NET TLS stack, run the following PowerShell command on the application server. It runs under your own account, so it checks the TLS handshake and certificate trust on that server, not the application pool identity.
Invoke-WebRequest https://<AA-server>:<port>/ -UseBasicParsing
Interpreting the error message:
| Error message | Category |
| Could not create SSL/TLS secure channel | TLS protocol or cipher mismatch |
| Trust relationship... certificate | Certificate chain issue on this server |
| Timeout | Traffic blocked (EDR, proxy or firewall deep inspection) |
| 401 / 403 | Authentication failure (identity, Kerberos or time skew) |
Diagnostic checklist
If AA still fails after the steps above, check the following on the application server:
- Application pool identity: is it NetworkService or the intended custom account?
- Load User Profile under IIS Manager > Application Pools > Advanced Settings > Process Model.
- Windows Event Viewer > Application and System logs for SChannel errors (Event IDs 36871, 36887) during a failed Test Connection.
- Recent OS-level changes: Windows Update, Group Policy / TLS hardening, or AV/EDR agent updates.
- AA server logs (Spotfire / IIS), filtered by the application server IP: did the requests reach the AA server at all?
- With more than one application server: compare all of the above with a server where AA works.
Requirements for a custom service account
NetworkService is the recommended default identity. If a custom account is used, it must meet all of the following:
- Load User Profile set to True under IIS Manager > Application Pools > Advanced Settings > Process Model.
- A local Windows user profile on the server.
- Read and write access to the STARLIMS application directories.
- Access to the Windows certificate store, if AA uses HTTPS with certificate-based authentication.
- Appropriate network privileges if the AA server is on a different subnet or domain.
A Group Managed Service Account (gMSA) is a supported alternative that avoids password rotation issues while still providing the correct user profile context.
Comments
0 comments
Article is closed for comments.