Hello, What is the best approach when attempting to create a server-centric view displaying the overall health of 5 newly created service monitors? In other words, I would like to see the state of these 5 services rolled up to a higher, “server-level” object that I would scope a state view on. As it stands, I have created 5 service monitors, each of which has created a new class. The problem is that I can only scope a state view on a single class. Thanks, Larry

Hi Larry, I can imagine a two ways to achieve that: - use a group for scoping - Do not use GUI for a class (service monitors) creation. Use the AuthConsole\XML editor and create your own 'server-level' class and relationshipshttp://OpsMgr.ru/

Hi. You can also create a distributed application made up of the 5 service classes, and then use a diagram view to see them all at once.Layne, 2011 Microsoft Community Contributor Recipient

Alexey, Group Scoping I honestly don't see how I could achieve the desired result using group scoping. If I create a group (ex.: AppServices) containing the 5 service-related classes, and then a view that is scoped on this group, then the view is empty. These observations support my understanding that if you scope a view on a group, then the group must contain objects of the same class that the view is also scoped on, otherwise nothing will appear. Using The Authoring Console Though I originally attempted to go down this route, I am unable to get the health of the service classes to roll up to the newly created AppRole class. I created a new App.Role class (concrete, hosted), configured with the following parameters: · Base Class: Microsoft.Windows.LocalApplication This class was chosen in order to get the health of the new role to roll up to the Windows.Computer object. · No new properties (simply DisplayName) · Data Source: Microsoft.Windows.FilteredRegistryDiscoveryProvider · Discovery (registry-based) targets: Microsoft.Windows.Computer Each service class (concrete, hosted), configured with the following parameters: · Base Class: Microsoft.SystemCenter.OwnProcessNTService · The following new properties (in addition to DisplayName): o ServiceName o ServiceProcessName o DisplayName o Description · Data Source: Microsoft.Windows.Win32ServiceInformationProviderWithClassSnapshotDataMapper · Discovery targets: App.Role Now, despite having created a containment relationship between App.Role (source) & App.Service1 (target), health does not rollup to the App.Role. Looking forward to hearing from you, Larry