Archive | May, 2014

[FIX] Fixing the Top n by Performance Widget

27 May

Update!: Fixed the run issue on SCOM 2012 R2 installations in MP version V1.0.0.6 . Thanks community for pointing out to this R2 issue.

Challenge:

First, I really LOVE the dashboard widgets included in SCOM. When making MPs I always deliver dashboards that gives the operator a one shot overview of the monitored targets. The most used and valuable widget for this is the “Objects by performance Widget”

This works perfect EXECPT when you have more instances of a performance value. Let’s say the table space free of table spaces, or disk C: D: ect from windows servers.

The problem is that most of the time you will get the situation below “Empty Widgets”

 

The problem is the Stored Procedure “Microsoft_SystemCenter_Visualization_Library_TopNEntitiesByPerfGet“. I don’t go into details because this issue is a known fact and already reported several times on the community. For example by Cameron Fuller http://blogs.catapultsystems.com/cfuller/archive/2013/06/05/issue-with-the-objects-by-performance-widget-with-and-all-performance-instances-scom-sysctr.aspx

But a fix for this in a SCOM CU was till now never released…. Till now….

 

Analyze

As I mentioned before it’s in the Stored Procedure “Microsoft_SystemCenter_Visualization_Library_TopNEntitiesByPerfGet“. We have a code part that does an exact match on the instance name. If we want to show all instances it will not return any matches. See the yellow parts below.

  •    INSERT
    INTO
    #ResolvedSeriesTable(ManagedEntityRowId, PerformanceRuleInstanceRowId)

                  SELECT
    CET.ContainedEntityRowId, PRI.PerformanceRuleInstanceRowId

                  FROM
    PerformanceRule
    PR

                  JOIN
    PerformanceRuleInstance
    PRI
    ON (PR.RuleRowId = PRI.RuleRowId)

                  JOIN
    #ContainedEntitiesTable
    CET
    ON (1=1)

            WHERE (
    (PR.ObjectName
    =
    @ObjectNamePattern)
    AND

                    (PR.CounterName
    =
    @CounterNamePattern)
    AND

                    (PRI.InstanceName
    =
    @InstanceNamePattern))

Suggestion to fix, is to use a like match. See yellow part.

       INSERT
INTO
#ResolvedSeriesTable(ManagedEntityRowId, PerformanceRuleInstanceRowId)

              SELECT
CET.ContainedEntityRowId, PRI.PerformanceRuleInstanceRowId

              FROM
PerformanceRule
PR

              JOIN
PerformanceRuleInstance
PRI
ON (PR.RuleRowId = PRI.RuleRowId)

              JOIN
#ContainedEntitiesTable
CET
ON (1=1)

        WHERE (
(PR.ObjectName
like
@ObjectNamePattern)
AND

                (PR.CounterName
like
@CounterNamePattern)
AND

                (PRI.InstanceName
like
@InstanceNamePattern))

 

To change this you will need SQL Developer knowledge. And I realize that most of the operators know a lot of backend/frontend products but aren’t developers. So it could be a bit of a challenge to change this stored procedure yourself.

 

Solution

To solve this issue I have created a Management Pack that changes this stored procedure for you. It doesn’t do this automatically, because I want you to choose to do it. So I implemented it as a SCOM task. When you import the MP and go the ManagementServer target that has the property “Is Root Health Service Emulator = True” (you can find it in the view Operations Manager -> Management Server -> Management Servers State) you will see a Task “Task Fix TopNQuery Widget“. Now you execute the task and you will see a Task output below:


And you go to the Widget dashboard you created and what do you see ????

 


Yes a working TopN Widget page.

 

NOTICE!!!

Using this task is totally unsupported. But in my opinion the negative impact is very low compared to the positive impact because this stored procedure is only used for reading data and not changing it so it wouldn’t impact the DB with incorrect data (except for some SQL performance penalty for the use of the like statement).

NOTICE!!!

When you reload the MP Microsoft.SystemCenter.Visualization.Library the stored procedure will be overwritten to the original version. This could happen if you implement an upcoming CU release. If the issue isn’t fixed in this release you must rerun the TASK again.

 

You can download this MP on my personal download site:

https://onedrive.live.com/redir?resid=A6ECD6E173E79D82!6314&authkey=!AE0rJkhRPXOcblI&ithint=file%2c.zip

Happy Scomming

Michel Kamp

[BUG] VSAE with a PowerShell $Data parameter

27 May

Hi,

This time for a short post on a ‘possible’ bug i detected in VSAE

Problem:

You create a PowerShell script and want to include this script using the $includeFileContent/<script_name>$ tag.

For example

<ProbeAction
ID=Probe
TypeID=Windows!Microsoft.Windows.PowerShellProbe
RunAs=SystemCenter!Microsoft.SystemCenter.DatabaseWriteActionAccount>

<ScriptName>FixTopNQuery.ps1</ScriptName>

<ScriptBody>$IncludeFileContent/FixTopNQuery.ps1$</ScriptBody>

<TimeoutSeconds>300</TimeoutSeconds>

<StrictErrorHandling>true</StrictErrorHandling>

</ProbeAction>

(Added a screenshot below)

The FixTopNQuery.ps1 is a PS script added to the project as “Embedded Resource”.

Now you compile the project and you get a compile error:

Error    1176    The configuration specified for Module Probe is not valid.

: Incorrect expression specified: $DataSet=New-Object System.Data.DataSet

. Unable to resolve this expression. Check the expression for errors. (Hints: Check for correct character casing (upper case/lower case), mismatched “$” signs, double quotes(“), square brackets “[” or “]”). Here is a sample expression: $Data/EventNumber$

(Path = OpsLogix.IMP.Oracle.Dashboards.Task.FixTopNQuery/Probe)    C:\Program Files (x86)\MSBuild\Microsoft\VSAC\Microsoft.SystemCenter.OperationsManager.targets    255    6    Dashboards

(Added a screenshot below)


Hmmm.. Why ?

 

Analyze

After a lot of error and retry I found out that the problem is in the included powershell script. And exactly in this line below:

$DataSet=New-Object System.Data.DataSet

Hmm I hear you thinking, what’s wrong with this statement? That exactly what I was thinking…. But when I change the parameter name the compile was successful…

 

Solution

Do not start a parameter name with $Data in the powershell script. It looks like it’s a reserved word in VSAE.

 

I will share this issue also with the VSAA product team.

Happy Scomming

Michel Kamp