We are doing "user perspective" monitoring with AD Client monitoring, Web and OLE templates and Info Worker MP (which has an Outlook to Exchange check).

What I also wanted to add in the DAD Model  is a component group that I would  call 'Network Connectivity client perspective'. I would like this component group to contain only the Health Service Watcher of the Vista workstations that are actually doing the client perspective monitoring.

While I understand checking network devices themselves, I am not allowed to mess with those. So, if I can show when HSW says agent is 'down and not pingable', that is as close I will get.

 I've gone over this OpsMgr DAD model situation you've described, and filtering first based on group and then on class is something I think could only be done programmatically.

I think the solution would be programmatic update of the DAD model (not sure how you'd code this), and then update / reimport the MP containing the model. Sounds like a potential consulting gig for Tenchuu and his CodeSmith C# magic to me.

Pete

The problem is that only HS are member of the computer group. The HSW are not. Hence you need to start with the HSW, evaluate the HS reference and then look back to check the HS for a computer group membership. I've changed the example a bit and added some comments in the XML (see attachment).

The nested formula example on my post even goes a bit further as it has two group rules. The first populated the element with computers - and the second adds the HSWs to go along. That's been documented by others to group HSW's and computer objects together. Very handy for subscriptions or alert views when HSW alerts need to be included with computer alerts.

UPDATE:

Replaced the sample with a complete MP. Comments are in the XML file.

• DistApp Service: Your.DAD.Servie
• DistApp Component Group: Your.DAD.ComponentGroup
• Computergroup: Your.Windows.Computergroup

The MP populates a computergroup. The DistApp service's component group is then populated with Health Service Watcher objects that watch the computers in the computer group.

maxDepth declares how deep into a nested structure a Contains/NotContains clause looks. You could leave it out which would mean it would look down as far as relationships exist. For performance reason (the RMS has to do all the work) I recommend setting to as low a value as possible.

maxDepth="1" --> direct membership (e.g. a computer is a driect member of a computer group)

maxDepth="2" --> direct or "grand child" (e.g. the HS is a "grand child" of a computer group)

When using Contained/NotContained then it works all the same but looking outward.

Guys

If you describe as detailed as possible what exactly you want to achieve (you've lost me by now), I'll see if I can make a fully working example MP for you. What I normally do is creating a 'simple' dynamic group using the wizards and then edit them in XML to get the more advanced stuff done. And these grouping techniques can be used on DistApp elements just as well as on groups.

Raphael

 Raphael, can you  demonstrate a concrete example, such as 

A component group containing only Health Service Watcher instances for which the associated Computer object is a member of Microsoft.Windows.Server.2003.ComputerGroup?

Voilà:

The MP first populates a computergroup with Windows Server 2003 objects of a named domain. You must change that discovery's matching expression to a domain which exists in your environment or that computergroup will remain empty.

The Component Group is then filled with Health Service Watcher objects that watch computers in above group.

This MP is complete with the DistApp Service, the Component Group, a Computer Group and Health Roll Up.

Note that if you change anything in the GUI tools you'll loose the embedded comments in the XML code. Especially do not attempt to open this DistAp in the designer! And I should mention that it has taken me well over an hour to write this and test it. Unfortunately such dynamic groupings aren't a 10 seconds and 2 click job (yet).

Next challenge?