Best practices for creating and using groups
Groups are mainly used for scoping (views, alert notifications, and reports). Therefore, groups are often created based on Windows Computer objects because this class hosts most of the relevant monitors for a Windows application.
If groups are created with extended authoring tools (or directly in XML ), they can and should be based on Windows Computer objects hosting special applications,
for instance, a Windows Computer group that contains only Windows computers based on a discovered custom special application class.
For notifications, the corresponding Health Service Watcher objects could be added to the group. This is necessary because Health Service Watcher objects needed for Operations Manager self-monitoring alerts like Heartbeat Failures or Computer Not Reachable to be included too.
In addition, groups are useful for creating overrides. Group-based overrides can be much easier to manage than putting overrides on specific instances.
It’s recommended that save groups in the same dedicated, custom, unsealed override pack ,used for application because you can’t reference objects or classes in a different unsealed management pack.
Sealing the group management pack is also possible, but this has disadvantages based on comfort and editing, and sometimes it breaks compatibility. Having all parts of an application together lets you easily maintain the application parts in one management pack without having an influence on other management packs.
set useful naming convention rules for the groups and the management packs.
Example> For instance, a naming convention like GRP_xxx for the group name makes finding groups in the console easy. Custom management packs can have the same name as the base management pack with “– Override” added to the name, so that search for “override” to find override management packs.
For custom own management packs, add a short version of your company name to the beginning of the name of the management pack, for instance, CONTOSO_xxx.