I have written many individual blog posts on creating and using groups. I wanted to take this post to put them all in one place – the most common examples of “how-to” create groups for all kinds of common scenarios. Some of these are super simple. Some are overly complex, and provide us a challenge to make using the UI and Authoring console much simpler for these common monitoring tasks.
You will undoubtedly createlotsof Groups in OpsMgr. The most common reasons you need groups in OpsMgr are:
To scope overrides to a specific subset of computers
To scope alert notifications or product connector subscriptions for a specific set of computers
To scope user consoles, so they only see the servers they are responsible for.
To scope a set of Computers that need to go into a scheduled maintenance mode.
To scope application views only to computers that host a given application.
To create a rollup Health State view of an otherwise disconnected subset of computers.
To create a set of computers for a report
The most common object you will place in your groups areWindows Computerobjects. The most common way to dynamically assign computers to the groups is by using apropertyof the Windows Computer class. I give examples of that here:
However – sometimes – NONE of these above give you exactly what you need in your groups…. for anything beyond this, you REALLY need to get into the XML and authoring console. So to make that a little simpler, I started a primer on the XML components of a group, so you can better understand what makes up a group anyway:
Once you have that fundamental understanding – you can start using the Authoring console and XML to create more advanced groups.
Probably the most common advanced group request I see – is how to add the Healthservice Watcher object to a group, for every Windows Computer that exists in the group already. This is MANDATORY for scoping notification and including the “Heartbeat Failure” and “Server down” alerts. Tim McFadden has done the best job on that topic:
As you start authoring your own custom application management packs, you will often find you need to be able to create a group of Windows Computer objects, for all Computers that host that application you are discovering. Jonathan Almquist does an outstanding job of documenting this:
As you get more advanced in authoring custom management packs, you might find that you want to create groups for specific applications, application roles, and application components. For this – an instance group is a better choice:
What about something that should be REALLY easy – but isn’t? Supposed you want to create a group of Windows Computers… but not ALL of them has host an application, maybe on a subset of them based on criteria of some OTHER class? This is more common than you might realized and SHOULD be very simple to do in the UI console… but isn’t. Again – we will refer to Jonathan’s blog on this topic for an excellent walk through:
I am sure there are lots of other good posts on groups out there as well. These are just the most common scenarios I have run into. If you know of a concept of using or creating groups that isn’t covered here, I’d love to hear about it and get it added to this post.
Lastly – a warning. Don’t go crazy with too many groups. A group is a singleton class hosted by the RMS, and the RMS must perform Group Calculation for each group on a regular basis. You can destroy OpsMgr performance by having way too many groups, or by having complex criteria formatted in such a way that it places a load to perform the calculation. There are a few articles on this topic…. but my advice:
Only create groups for what you absolutely need groups for. Don’t create groups “to get organized” if you aren’t absolutely using those groups.
Try and keep the number of groups under 1000. There is only a certain number of custom groups that are performance tested. Beyond that – you might see performance issues that are unknown.
Keep your dynamic membership criteria SIMPLE.
Don’t create too many groups with massive memberships.