I need to send help desk alerts for class object inside a a number of different management packs, 

Is it better to pick each class (about 60 class objects, "raised by any instance of a specific class") inside the subscription setup or create a group that holds the class objects from each Management pack and use "raised by any instance in a specific group&

Suppose you have a SQL server and you want just SQL alerts (job failure, etc) to go the DBAs and "Windows" related issues (logical disk space) to go to the Windows team. You'd use the "any instance of a specific class" (like SQL 2008 DB Engine). If you wanted ALL alerts (whether they're from SQL, Windows, Exchange, AD) from a specific group of servers, you'd use "raised by any instance in a specific group"

Yes, you could slice and dice this pretty finely: for example, you could have  a group of SQL servers in San Diego and another group of them in Las Vegas and send SQL-SD alerts to one group and SQL-LV alerts to another.

So i should use a group to put the class in? Class X from A Management Pack, Class Y from B Management Pack, And so on?

what i am asking is is it OK to have a large list of "raised by any instance of a specific class" part of a subscription or would it be better to have the classes defined in a group and setup the subscription with "raised by any instance in a specific group"?

 

My answer is:

it be better to have group contains objects create by specific class rather than  group that holds the class objects  and setup the subscription with "raised by any instance in a specific group"

Reason

It is easy to maintain the subscription criteria list. Every time, when you want to add or remove class from the subscription, you does not need to modify the subscription criteria. You just need to modify the group membership.

Moreover, the group membership support dynamic membership which provide further flexibility for user to dynamic update the group object. At last, it create a performance issue when you update a subscription which has a long list of class objects, with criteria  "raised by any instance of a specific class".

Roger

 

 

My answer is:

it be better to have group contains objects create by specific class rather than  group that holds the class objects  and setup the subscription with "raised by any instance in a specific group"

Reason

It is easy to maintain the subscription criteria list. Every time, when you want to add or remove class from the subscription, you does not need to modify the subscription criteria. You just need to modify the group membership.

Moreover, the group membership support dynamic membership which provide further flexibility for user to dynamic update the group object. At last, it create a performance issue when you update a subscription which has a long list of class objects, with criteria  "raised by any instance of a specific class".

Roger

 

• Marked as answer by James-MS 14 hours 6 minutes ago

 

My answer is:

it be better to have group contains objects create by specific class rather than  group that holds the class objects  and setup the subscription with "raised by any instance in a specific group"

Reason

It is easy to maintain the subscription criteria list. Every time, when you want to add or remove class from the subscription, you does not need to modify the subscription criteria. You just need to modify the group membership.

Moreover, the group membership support dynamic membership which provide further flexibility for user to dynamic update the group object. At last, it create a performance issue when you update a subscription which has a long list of class objects, with criteria  "raised by any instance of a specific class".

Roger

 

• Marked as answer by James-MS Tuesday, June 23, 2015 5:03 PM

It's OK to have a large list of targets/classes. Some of our subscriptions are pretty ugly (the ~20 for Exchange 2013, all of the ~60 SQL classes)

Thanks all for the replies, I went with a dynamic membership group.