This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(44.800000000000004, 73%, 14%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EAS%3C/text%3E%3C/svg%3E)
We have latest SQL Management Pack , and SCOM version is 2012 R2 UR14, which we are migrating SCOM 2019. The blocking session alerts show the query in property value but it does not show this is alert context. Please refer the screen shots. Looks like a bug or known issue, any help will be highly appreciated or helpful
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(150.4, 92%, 24%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EXM%3C/text%3E%3C/svg%3E)
Hi,
For this issue, we can't reproduce this scenario. I recommend you try to contact Microsoft CSS support to confirm that this is a bug or a known issue.
Hi
I can't test on SCOM 2012 but I've quickly created a test database and configured a blocking scenario. Using SCOM 2022 and the SQL version agnostic management pack - Microsoft SQL Server on Windows (Monitoring) version 7.0.38.0 - I can see the full alert context. The SQL Server is SQL 2019. 
The version of SCOM shouldn't make a difference and if you are using the SQL version agnostic management packs then that is also unlikely that a different version of SQL is the cause so does this happen on all of your SQL Server instances? Or just specific ones? I don't know if it is a bug in a particular MP \ whether you have ended up with a character in the CDATA tags that has caused an issue with the formating.
Regards
Graham
I may just have figured it out .... once the alert is closed; the alert context is updated ... and as there is no blocking, all the details are overwritten in the console with the latest information. In your orginal screenshot; if you look at the healthy state in health explorer then the details there are likely what are being displayed in the alert context for the alert (you'll notice it states blocked spid count = 0.
The best option is to ensure that the team look at the Health Explorer unhealthy status to see what the problem is. The original details are also overwritten in the Alert table in the OperationsManager database but they can be found in the AlertHistory table or it might be worth seeing if you can set up a notification to email out the details so that if the alert has cleared before someone looks at it then at least they knew what the issue actually was (without resorting to health explorer).
