Hello,

We are using SCOM 2019 to monitor our SSRS and Power BI Report Server deployments using the SQL 2017+ Reporting Services management pack (v7.0.15.0).

This management pack is able to successfully monitor SSRS 2017 and Power BI Report Server deployments up to May 2019, however when upgrading or deploying to Power BI Report Server September 2019, the "Report manager accessible - PBIRS" monitor in SCOM becomes critical and the following error appears in the RSPortal log file under C:\Program Files\Microsoft Power BI Report Server\PBIRS\LogFiles:

2019-12-05 10:41:19.4770|ERROR|37|DOMAIN\SCOMRunAsAccount ::1: HEAD - 0:00:00.0004824
Exception: System.Net.ProtocolViolationException: Bytes to be written to the stream exceed the Content-Length bytes size specified.
at System.Net.HttpResponseStream.Write(Byte[] buffer, Int32 offset, Int32 size)
at Microsoft.Owin.Host.HttpListener.RequestProcessing.ExceptionFilterStream.Write(Byte[] buffer, Int32 offset, Int32 count)
at Microsoft.ReportingServices.Portal.WebHost.Owin.CustomIndexMiddleware.Invoke(IOwinContext context)
at Microsoft.ReportingServices.Portal.WebHost.Owin.OAuthClientScriptMiddleware.Invoke(IOwinContext context)
at Microsoft.BIServer.Owin.Common.Middleware.ResponseCompressionMiddleware.<Invoke>d4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.ReportingServices.Portal.WebHost.Owin.LocalRequestMiddleware.<Invoke>d1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.BIServer.Owin.Common.Middleware.RequestLoggingMiddleWare.<Invoke>d_2.MoveNext()| RequestID = sbfc29cee-d734-4064-b23e-8f0b891af12f

Since updating SSRS 2017 instances to build 14.0.600.1451 (2019/11/13), we are now facing the same problem with those.

In the SQL 2017+ Management Pack is a Monitor to monitor the free DB log space in percent. We would like to monitor the free DB log space additionally in MB. We need this because we have very much DBs, and they are from very small to very big. Its to much effort to set for every DB another percent treshold. And if we set a threshold 10%, this is good for small DBs, but if we have a big DB, there is no problem when free space is for example 10% but still 100GB. So we wanna set a threshold in percent to generate a warning. And we wanna set a critical treshold in MB, so we can generate an alarm, if there is really a low DB log space.

The version agnostic management pack (v7.0.15.0) appears to have issues discovering clustered SQL Server instances. I deployed it alongside a fresh SCOM 2019 build without any of the old SQL Server management packs imported, and only some instances/databases are being discovered – it’s a very strange mix of results. We have a SQL 2014 instance that gets discovered fully (including databases), a SQL 2016 instance which is discovered with its databases but are not monitored, and SQL 2016/2017 instances that aren’t discovered at all.

I then imported the SQL 2016 management pack (v7.0.15.0) and it discovered all the clustered instances/databases with no issues whatsoever. I haven’t tested other versions yet but I’d expect it would likely be the same result.

I see this error appearing in the Operations Manager log on the management servers (ID 10801):

Discovery data couldn't be inserted to the database. This could have happened because of one of the following reasons:

- Discovery data is stale. The discovery data is generated by an MP recently deleted.

- Database connectivity problems or database running out of space.

- Discovery data received is not valid.

The following details should help to further diagnose:

DiscoveryId: 435a766d-decb-3d54-7d0d-08ca1142e6eb
HealthServiceId: 7d3b39e4-7a79-a5c6-a28b-4494382a3a4e
Microsoft.EnterpriseManagement.Common.DiscoveryDataInvalidRelationshipSourceException,The relationship source specified in the discovery data item is not valid.
Relationship source ID: d8b34c91-47ae-0f94-c5a4-b6325bd65b05
Rule ID: 435a766d-decb-3d54-7d0d-08ca1142e6eb
Instance:
<?xml version="1.0" encoding="utf-16"?><RelationshipInstance TypeId="{2f71c644-e092-b80a-040b-5c81ba1ec353}" SourceTypeId="{ab4c891f-3359-3fb6-0704-075fbfe36710}" TargetTypeId="{01c7eaa4-aaa0-28a2-55ec-af08fb1b7f9d}"><Settings /><SourceRole><Settings><Setting><Name>5c324096-d928-76db-e9e7-e629dcc261b1</Name><Value>HOSTNAME.domain.com</Value></Setting></Settings></SourceRole><TargetRole><Settings><Setting><Name>8e36e48d-79a9-25f6-03f4-a83dbabfb7c5</Name><Value>SQLVNETNAME.site.domain.com</Value></Setting><Setting><Name>0ad613ed-b2ba-4bd3-05d2-102dc4d8e756</Name><Value>INSTANCENAME</Value></Setting></Settings></TargetRole></RelationshipInstance>.

What’s interesting is that the 1st value contains only a partial domain name which doesn’t include the site, whereas the 2nd value contains the FQDN.

I’ve ruled out cluster/SQL instance permissions, proxy agent settings, RunAs profiles, NIC settings, DNS, NetBIOS/default domain on the cluster nodes.

Standalone SQL instances are discovered fine!

Server OS is Windows Server 2019. I have not tested Windows Server 2016 and below as we do not run Failover Clustering on these OS versions.

The 2014 and 2016 SQL Integration packs have "Discover SQL Server 2014 DB Installation Source (seed)" discoveries that are targeted toward the "Windows Server" class. In environments where SSIS may be installed on SQL Clusters (and SCOM has the clustering MPs imported), this can lead to duplicate instances of the Integration services being discovered. Clustered resource "servers" are also populated into the "Windows Server" class. I creates groups populated with "Windows Server" objects with the "Is Virtual Node" property set to "True", and override the discoveries using these groups. Pan Optional MP could be included that would be imported if you are using Windows cluster in your environment, that would great the groups automatically and override the discoveries to prevent clustered "Servers" from discovering as integration services.

The 2014 and 2016 SQL Integration packs have "Discover SQL Server 2014 DB Installation Source (seed)" discoveries that are targeted toward the "Windows Server" class. In environments where SSIS may be installed on SQL Clusters (and SCOM has the clustering MPs imported), this can lead to duplicate instances of the Integration services being discovered. Because clustered resource "servers" are also populated into the "Windows Server" class, they too discover SSIS instances. In one example here, one cluster that only has two base nodes had five different SSIS instances discovered, when only the base nodes should be discovered. I had to create groups populated with "Windows Server" objects with the "Is Virtual Node" property set to "True", and override the discoveries using these groups. I realize that the MP can't be written assuming the cluster MPs are present in the environment, but perhaps an Optional MP could be included that would be imported if you are using Windows cluster in your environment, that would great the groups automatically and override the discoveries to prevent clustered "Servers" from discovering as integration services.

Current SQL Management Packs provide reactive insight/notification into issues with mirroring, but there are no automated recoveries/ability for automated proactive maintenance when an issue is discovered. Mirroring outages require custom code, or manual intervention to resolve. This translates into added cost for customers in terms of in-house development, or if a recovery is manual it means longer outage durations.

Request is for a monitor that looks at the current state of mirrors + a automated recovery which executes a RESUME for any mirrors that are DISCONNECTED, SUSPENDED or UNSYCHRONIZED. It then should wait to give the mirrors a chance to CONNECT and then recalculate the health state of the mirrors again. Alert will remain open if the mirrors current status is anything other than SYNCHRONIZED or SYNCHRONIZING.