The State View vs State Widget
SCOM Widgets are in almost all situations equivalent to or superior to the corresponding Views. State Widget falls in the category that justifies the almost exception.
Here it is why I continue to use State Views:
– Superior group filtering (more details on this below)
– Contextual Maintenance Mode
– Ability to perform Copy & Paste data from the view
In favor of the State Widget I can only mark the fact that it is faster.
Whenever I need to show/report inventory of a specific class, my preferred method is to use a State View. Of course such task can be performed in OM PowerShell, but creating a State View it’s easy and graphical. The experience is similar to SQL Query Designer. And the best part of it is that allows you to apply an umbrella group filter (group members hosting or containing the class of interest).
Here is a use case example that will show why State View continues to be one of my favorites: show me all the instances of SQL Server 2008 Reporting Services installed on Windows Server 2012 R2 servers; and I’d like to know the following properties: Version, Service Pack Version and Install Path.
Here is what needs to be configured:
Please note the highlighted: Show data related to: _ Show data contained in a specific group: _ (that is precisely what I am looking for).
And screen below for selecting only the class properties of interest.
The results are Copy & Paste exportable (Ctrl+A, Ctrl+C, Ctrl+V).
And I did not care to use in this example further, graphical filtering on properties matching some criteria, definitely useful.
The corresponding State Widget configuration looks somewhat similar:
Please note the highlighted: Select a class to scope the members of the specified groups – far from what I need and questionably useful.
Indeed, with such configuration the widget does not provide any results. And no matter what else you would try to configure for the widget (I tried not only the UI, but also using Component Overrides in MP XML), you cannot get the results the State View is providing.
It might be because of the way Microsoft.SystemCenter.Visualization.GetManagedEntitiesDataSource is implemented, the fact that RecursionTypeNames is set to System.Library!System.Group (I am still researching this).
I will therefore conclude that, to my taste at least, the View implemented in the Microsoft.Mom.Ui.Components assembly is better than the State Widget.