System Center 2012 R2 – Operations Manager provides distributed applications as a key feature to represent your service map for monitoring and end-to-end management across the entire System Center suite. By looking at Operations Manager the purpose of the distributed application feature is to provide an overall health for a your services that are comprised of different objects. Distributed applications do not provide any additional monitoring for the objects in an application. Instead, they include objects that are already being discovered and monitored. The value of the distributed application is to provide a relationship between the health of configuration items that are contained within your service. To provide that logical representation and "single pane of glas" a distributed application implements a service model that is based upon your formal service design.
You can create and manage distributed applications using the Distributed Applications Designer in the Operations console as a graphical environment. First, this article provides some fundamentals for distributed applicaitions and the service model anatomy. The second part of this article that serves a custom solution to resolve a common challenge that may appear once you manage change against a distributed application service model during the lifecycle of your entire IT-Service. As enterprises will have to adapt to the new market challenges very frequently, change very often results in adaptations to the IT infrastructure and IT-service landscape. Accordingly, service transition planning and support process must incorporate the service design and operational requirements also.
Anatomy of Distributed Applications
(As provided by: http://technet.microsoft.com/en-us/library/hh457612.aspx )
A distributed application must include one or more objects in order to be useful. Any object discovered by different management packs installed in the management group can be used in a distributed application. This might come from a management pack installed from the catalog or one that you have created on your own. These can be objects created by different monitoring wizards as discussed in Management Pack Templates.
A component group can contain any number of objects, and any object added to the distributed application must be contained in a component group. When you create the component group, you specify one or more classes that the group can contain. Only objects that are instances of these classes may be added to the particular group. If you specify All Objects then any objects in the management group can be included in the component group.
If you want to limit the objects that can be included in the component group, then you should select the Object(s) if the following type(s) and then select one or more classes from the class tree. The tree will contain all of the classes in the management group which are provided by all the management packs currently installed.
Once you are managing your IT-Service as a distributed application you may need to adapt the IT-service model component group membership definition during service operations or service transitions. A component group is declared as the root for all components that will be contained by the toplevel System.Service class. At some points your service model may declare component groups that aggregate even further logical sub-groups as illustrated in the example above. The problem that may arise is that these sub-groups may be disappeared within the Operations Manager Console group view. This does not cause Monitoring failure but handicaps changes against these nested groups. The problem with that is that these nested groups are not be managed as a top-level entity as per GetRootMonitoringObjectGroups() anymore. To resolve from that issue we will need to add these groups back to a top-Level entity group to re-establish visibility within the OpsMgr Console group view. The following custom Management Pack solution provides a group discovery that aggregates each contained group within a component service group back to an auxiliary top-level entity group.
Please note: The sample scripts are not supported under any Microsoft standard support program or service and may also cause side-effects on (Default) ressource pool performance within large-scale environments. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.
Below please find the discovery definition that will calculate DistributedAppGroupPopulator.InstanceGroup object that will contain all System.Group entities that are contained within a ServiceComponentGroup. The mpx-Fragment is also attached to this post.
<ClassType ID="DistributedAppGroupPopulator.InstanceGroup" Accessibility="Public" Abstract="false" Base="MSIL!Microsoft.SystemCenter.InstanceGroup" Hosted="false" Singleton="true" Extension="false"/>
<DataSource ID="DistributedAppGroupPopulator.InstanceGroup.DataSource" TypeID="SC!Microsoft.SystemCenter.GroupPopulator">
Once this group has been discovered successfully your group will be back visible / mangageable in the Operations Manager Console.
Update #1 – 2014/08/22
In order to tweak discovery performance you may want to add the maxDepth parameter within the contained expression type. Thanks to Brian MC Dermott for this pointer!