Event 31569: Exception 'WebException': The underlying connection was closed: An unexpected error occurred on a receive.

The Event ID 31569 error indicates a problem with the connection to the SQL Reporting Services server. Here are a few steps to troubleshoot and resolve the issue:

1. Check Network Connectivity: Ensure there are no network issues between the SCOM server and the SQL Reporting Services server.
2. Verify SQL Reporting Services Configuration: Confirm that SQL Reporting Services is properly configured and running.
3. Review Permissions: Ensure that the SCOM service accounts have the necessary permissions on the SQL Reporting Services server and databases. Specifically, check if the accounts have the VIEW SERVER STATE permission on the SQL server.
4. Firewall Settings: Since the SQL Reporting Services server is on the same device as the SCOM server, firewall settings should not be an issue. However, double-check to ensure no firewall rules are blocking the necessary ports.
5. Check Logs: Look for additional details in the SCOM and SQL Reporting Services logs to identify any specific errors or issues.

For the Event ID 100 warnings, it appears the SCOM action account lacks the VIEW SERVER STATE permission on the SQL server. Granting this permission to the action account should resolve these warnings.

If the issue persists after these steps, consider

Hi Joshua,

you’re actually looking at two separate issues here:

1) Event ID 31569 – "underlying connection was closed"

This event is raised by the Data Warehouse Synchronization Service when it tries to talk to SQL Server Reporting Services (SSRS) and fails:

Report deployment process failed to request management pack list from SQL RS Server. Exception 'WebException': The underlying connection was closed: An unexpected error occurred on a receive.

Because your Reporting role and SCOM 2025 management server are on the same box, this is almost never a "firewall on the path" problem – it’s typically:

• SSRS URL / SSL configuration, or
• TLS/SSL protocol mismatch, or
• Reporting / RunAs account mis-configuration.

I’d walk through these checks:

a) Verify you can reach SSRS from the SCOM server

On the SCOM 2025 management/reporting server:

1. Log on as the account you use for the Data Warehouse Report Deployment / DW Reader (the "DW Read" account).
2. Browse to:
   • http://<server>/Reports
     • http://<server>/ReportServer
     1. Make sure both open without errors.

If you’ve configured HTTPS in SSRS, test with the HTTPS URL instead and ensure the certificate is valid (no warnings).

If you can’t open these URLs cleanly in a browser, SCOM’s DW Sync service won’t be able to either – fix this first.

b) Check SSRS SecureConnectionLevel / HTTP vs HTTPS

The error "underlying connection was closed" is very often seen when SSRS is configured to require SSL but the client (SCOM in this case) is still trying to use HTTP, or when there’s a TLS negotiation problem. In SSRS this is controlled by the SecureConnectionLevel and URL settings in RSReportServer.config.

Typical gotchas:

• SSRS is configured with SecureConnectionLevel = 2 (require TLS/HTTPS), but SCOM was installed against HTTP and still uses the HTTP URL.
• Or the HTTPS binding exists, but the certificate is wrong / untrusted, so the connection is reset.

What to check:

1. Open Reporting Services Configuration Manager on the reporting server.
2. Under Web Service URL and Web Portal URL, confirm:
   • Whether you’re using HTTP or HTTPS, and
     • The exact URL and host name that SSRS is listening on.
     1. Make sure that matches how SCOM is accessing the report server (same protocol and host).

If you’ve recently switched SSRS from HTTP to HTTPS after installing SCOM Reporting, you may see 31569 until things are aligned again. In that case either:

• Reconfigure SSRS back to HTTP (for testing) and see if the 31569 events stop, or
• Keep HTTPS and make sure the SCOM server can successfully reach the HTTPS URL (valid cert, proper bindings, etc.).

(There are older SSRS examples where switching SecureConnectionLevel from 2 to 0 resolved the exact same "underlying connection was closed" error; in modern builds you should usually fix the SSL binding/certificate rather than permanently relaxing the setting, but it’s a useful data point when troubleshooting.

c) TLS / protocol configuration on SCOM 2025 & Server 2025

SCOM 2025 supports TLS 1.2 and (with UR1+) TLS 1.3, and it uses whatever protocols are enabled at the OS level.

On a brand-new Server 2025 build it’s common to have security baselines or tools (e.g. IIS Crypto / GPO) disabling some protocols. If, for example:

• SSRS is only allowing TLS 1.2, but someone disabled TLS 1.2 on the server and left only TLS 1.3; or
• The reverse – SSRS is constrained to older protocols that the SCOM components don’t use,

you can end up with exactly this "underlying connection was closed" behaviour.

So it’s worth verifying on the reporting/SCOM server:

• TLS 1.2 is enabled (and preferably 1.3 as well).
• No security baseline has disabled all protocols that SSRS and SCOM have in common.

d) Double-check the Data Warehouse RunAs profiles

Even though your exception is a WebException (not a SqlException), it’s still good to confirm the DW RunAs profiles are correct, because broken profiles can also generate 31569 with different error text.

In the SCOM console:

1. Go to Administration → Run As Configuration → Profiles.
2. Open:
   • Data Warehouse Account
     • Data Warehouse Report Deployment Account
     1. Make sure:
        • Each profile has a Run As account associated,
          • The associated Run As accounts are distributed to all management servers, and
            • Those accounts have the documented rights on the DW DB and SSRS.

There are known cases where these profiles "lost" their associations and started causing 31557/31563/31569 DW errors.

2) Event ID 100 – GetOpsMgrDBPercentFreeSpace.ps1 and VIEW SERVER STATE

This one is not about mount points or drive permissions on the SCOM/SQL servers. The key part is:

GetOpsMgrDBPercentFreeSpace.ps1 : Exception calling "Fill" with "1" argument(s): "VIEW SERVER STATE permission was denied on object 'server', database 'master'…"

This comes from the newer DB free-space script (GetOpsMgrDBPercentFreeSpace.ps1) that was introduced in recent SCOM update rollups. That script now requires additional SQL instance-level permissions for the account that runs it. This behaviour is documented for SCOM 2019/2022 URs and carries forward into 2025.

By default, this workflow runs under the Management Server Action Account (unless you’ve customized the RunAs profile).

What you should do

On the SQL instance hosting the OperationsManager database, grant the Management Server Action Account (or whichever login is used) these instance-level permissions:

• VIEW SERVER STATE
• VIEW ANY DEFINITION

Example T-SQL (adjust the login name for your environment):

USE [master];
GRANT VIEW SERVER STATE   TO [DOMAIN\SCOM_MSAA];
GRANT VIEW ANY DEFINITION TO [DOMAIN\SCOM_MSAA];

If your OpsDB is in an AlwaysOn AG, repeat this on all replicas hosting the OperationsManager DB.

Once these permissions are in place, the Event ID 100 warnings for GetOpsMgrDBPercentFreeSpace.ps1 should stop. No special "view rights to mount point drives" are required beyond your normal OS permissions.

I hope I was able to help

Best Regards

Stoyan Chalakov

"If my response was useful, please consider marking it as the answer. It keeps the forum clean, structured, and more helpful for everyone. Thank you for supporting the community."

Hi Joshua,

you’re actually looking at two separate issues here:

1. Event ID 31569 – "underlying connection was closed"

This event is raised by the Data Warehouse Synchronization Service when it tries to talk to SQL Server Reporting Services (SSRS) and fails:

Report deployment process failed to request management pack list from SQL RS Server.
Exception 'WebException': The underlying connection was closed: An unexpected error occurred on a receive.

Because your Reporting role and SCOM 2025 management server are on the same box, this is almost never a "firewall on the path" problem – it’s typically:

• SSRS URL / SSL configuration, or
• TLS/SSL protocol mismatch, or
• Reporting / RunAs account mis-configuration.

I’d walk through these checks:

a) Verify you can reach SSRS from the SCOM server

On the SCOM 2025 management/reporting server:

1. Log on as the account you use for the Data Warehouse Report Deployment / DW Reader (the "DW Read" account).
2. Browse to:
   • http://<server>/Reports
     • http://<server>/ReportServer
     1. Make sure both open without errors.

If you’ve configured HTTPS in SSRS, test with the HTTPS URL instead and ensure the certificate is valid (no warnings).

If you can’t open these URLs cleanly in a browser, SCOM’s DW Sync service won’t be able to either – fix this first.

b) Check SSRS SecureConnectionLevel / HTTP vs HTTPS

The error "underlying connection was closed" is very often seen when SSRS is configured to require SSL but the client (SCOM in this case) is still trying to use HTTP, or when there’s a TLS negotiation problem. In SSRS this is controlled by the SecureConnectionLevel and URL settings in RSReportServer.config.

Typical gotchas:

• SSRS is configured with SecureConnectionLevel = 2 (require TLS/HTTPS),
  but SCOM was installed against HTTP and still uses the HTTP URL.
• Or the HTTPS binding exists, but the certificate is wrong / untrusted, so the connection is reset.

What to check:

1. Open Reporting Services Configuration Manager on the reporting server.
2. Under Web Service URL and Web Portal URL, confirm:
   • Whether you’re using HTTP or HTTPS, and
     • The exact URL and host name that SSRS is listening on.
     1. Make sure that matches how SCOM is accessing the report server (same protocol and host).

If you’ve recently switched SSRS from HTTP to HTTPS after installing SCOM Reporting, you may see 31569 until things are aligned again. In that case either:

• Reconfigure SSRS back to HTTP (for testing) and see if the 31569 events stop, or
• Keep HTTPS and make sure the SCOM server can successfully reach the HTTPS URL (valid cert, proper bindings, etc.).

(There are older SSRS examples where switching SecureConnectionLevel from 2 to 0 resolved the exact same "underlying connection was closed" error; in modern builds you should usually fix the SSL binding/certificate rather than permanently relaxing the setting, but it’s a useful data point when troubleshooting.

c) TLS / protocol configuration on SCOM 2025 & Server 2025

SCOM 2025 supports TLS 1.2 and (with UR1+) TLS 1.3, and it uses whatever protocols are enabled at the OS level.

On a brand-new Server 2025 build it’s common to have security baselines or tools (e.g. IIS Crypto / GPO) disabling some protocols. If, for example:

• SSRS is only allowing TLS 1.2, but someone disabled TLS 1.2 on the server and left only TLS 1.3; or
• The reverse – SSRS is constrained to older protocols that the SCOM components don’t use,

you can end up with exactly this "underlying connection was closed" behaviour.

So it’s worth verifying on the reporting/SCOM server:

• TLS 1.2 is enabled (and preferably 1.3 as well).
• No security baseline has disabled all protocols that SSRS and SCOM have in common.

d) Double-check the Data Warehouse RunAs profiles

Even though your exception is a WebException (not a SqlException), it’s still good to confirm the DW RunAs profiles are correct, because broken profiles can also generate 31569 with different error text.

In the SCOM console:

1. Go to Administration → Run As Configuration → Profiles.
2. Open:
   • Data Warehouse Account
     • Data Warehouse Report Deployment Account
     1. Make sure:
        • Each profile has a Run As account associated,
          • The associated Run As accounts are distributed to all management servers, and
            • Those accounts have the documented rights on the DW DB and SSRS.

There are known cases where these profiles "lost" their associations and started causing 31557/31563/31569 DW errors.

2. Event ID 100 – GetOpsMgrDBPercentFreeSpace.ps1 and VIEW SERVER STATE

This one is not about mount points or drive permissions on the SCOM/SQL servers. The key part is:

GetOpsMgrDBPercentFreeSpace.ps1 : Exception calling "Fill" with "1" argument(s): "VIEW SERVER STATE permission was denied on object 'server', database 'master'…"

This comes from the newer DB free-space script (GetOpsMgrDBPercentFreeSpace.ps1) that was introduced in recent SCOM update rollups. That script now requires additional SQL instance-level permissions for the account that runs it. This behaviour is documented for SCOM 2019/2022 URs and carries forward into 2025.

By default, this workflow runs under the Management Server Action Account (unless you’ve customized the RunAs profile).

What you should do

On the SQL instance hosting the OperationsManager database, grant the Management Server Action Account (or whichever login is used) these instance-level permissions:

• VIEW SERVER STATE
• VIEW ANY DEFINITION

Example T-SQL (adjust the login name for your environment):

USE [master];

GRANT VIEW SERVER STATE   TO [DOMAIN\SCOM_MSAA];

GRANT VIEW ANY DEFINITION TO [DOMAIN\SCOM_MSAA];

If your OpsDB is in an AlwaysOn AG, repeat this on all replicas hosting the OperationsManager DB.

Once these permissions are in place, the Event ID 100 warnings for GetOpsMgrDBPercentFreeSpace.ps1 should stop. No special "view rights to mount point drives" are required beyond your normal OS permissions.

I hope I was able to help

Best Regards
Stoyan Chalakov

"If my response was useful, please consider marking it as the answer. It keeps the forum clean, structured, and more helpful for everyone. Thank you for supporting the community."