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 create lots of 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 are Windows Computer objects. The most common way to dynamically assign computers to the groups is by using a property of the Windows Computer class. I give examples of that here:
Then – to assist with some complex dynamic assignments, Cameron and I show how to use some RegEx to simplify things:
For some advanced examples of grouping other types of objects, using the AND/OR clauses, and how to group objects by their Host I give some examples:
A very popular concept is creating registry entries on monitored servers, to give us new criteria for grouping these servers which otherwise did not exist:
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:
Sometimes you might want to populate groups from an external source, like a CMDB or AD (this can be a lot more complicated)
Steve followed up with how to do the same thing from a Text file source:
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:
Another twist – what if you want to create a group of logical disks, but ONLY if they are disks on a SQL or Exchange server?
Here is a similar scenario – what if you want to create a group of all your Windows Computers, that are NOT a specific member of another special group?
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.