SCOM Management Group

Here we’re going to talk about something very important and basically the root of everything. Without this your SCOM does not exist. Essentially, this is what your whole SCOM setup is called – The Management Group. Yet, this is not something you’d work with daily. In fact, in most environments it’s just an install-and-forget kinda thing. You may sometimes run into wizards that’d ask you to specify the name of your MG, like manual agent install wizards, but that’s mostly all. However, there are some cases where you’d want to give some special attention to your MG, let’s discuss those here.

So the technical definition of an MG according to Technet goes like this:

Installing Operations Manager creates a management group. The management group is the basic unit of functionality. At a minimum, a management group consists of a management server, the operational database, and the reporting data warehouse database.

…and that’s really all about it. You have to specify the name of your MG when you install SCOM. Once everything is up and running, all your components (MS, GW, DBs, Agents, etc) would eventually be connected to this MG.

Where can I see the name of my MG?

You can view the name of your MG at the very top of your Ops Console. Like here:

The highlighted text is the name of your MG.

(random screenshot from Internet)

You can also retrieve the name of the MG using Powershell:

Get-SCOMManagementGroup | select Name

The name of the Management Group can not be changed later, so plan ahead.

Speaking of planning, you must go through this document here to decide on a high level how the structure of your MG (or MGs) should be like, and a great insight into the components that make up an MG:

Planning a Management Group Design

There really isn’t a applies-to-all criteria of how big your MG should be, but there are certainly some constraints on how much data or load the underlying components may take. There’s an excellent tool that would make it easier for you to plan your deployment, its called the Operations Manager Sizing Helper Tool.

The Operations Manager 2012 Sizing Helper is an interactive document designed to assist you with planning & sizing deployments of Operations Manager 2012. It helps you plan the correct amount of infrastructure needed for a new OpsMgr 2012 deployment, removing the uncertainties in making IT hardware purchases and optimizes cost. A typical recommendation will include the recommended hardware specification for each server role, topology diagram and storage requirement.

You can download it HERE

The general recommendations from Microsoft go like this:

Monitored item	Recommended limit
Simultaneous Operations consoles	50
Agent-monitored computers reporting to a management server	3,000
Agent-monitored computers reporting to a gateway server	2,000
Agentless Exception Monitored (AEM)-computers per dedicated management server	25,000
Agentless Exception Monitored (AEM)-computers per management group	100,000
Collective client monitored computers per management server	2,500
Management servers per agent for multihoming	4
Agentless-managed computers per management server	10
Agentless-managed computers per management group	60
Agent-managed and UNIX or Linux computers per management group	6,000 (with 50 open consoles); 15,000 (with 25 open consoles)
UNIX or Linux computers per dedicated management server	500
UNIX or Linux computers monitored per dedicated gateway server	100
Network devices managed by a resource pool with three or more management servers	1,000
Network devices managed by two resource pools	2,000
Agents for Application Performance Monitoring (APM)	700
Applications for Application Performance Monitoring (APM)	400
URLs monitored per dedicated management server	3000
URLs monitored per dedicated management group	12,000
URLs monitored per agent	50

As you can see, it really depends on the size of your infrastructure and also on your Hardware. I’d really still keep a little margin in these numbers as well, just in case. So, a thorough and careful planning in the beginning will make your (and many others’) life easier later 🙂

Now, what if your environment is really huge and spread across the globe that just one MG isn’t enough?

No worries, you can connect multiple MG’s AND manage them centrally too 🙂

Connected Management Groups

Consider this – Your company Contoso has data centers all over the world, and the total number of devices (servers, network devices, etc) to be monitored is around 50k, distributed all across the world. Let us say you have offices in the US, Europe, India, Australia, etc. and you have dedicated teams that are supposed to handle the servers belonging to the Data centers in their region. These environments are basically different and they need to be monitored differently, independent of other regions. You do not want admins from one region to interfere between the operations of other regions, but – you also want to have a universal console at your HQ (let’s say in the US) from where you can keep an eye on all your different regions’ monitoring operations.

This is the best example of when you’d want to handover different and dedicated MG’s to each of your regions, and then you consolidate them all in a central MG you have at your HQ.

The MG’s that you consolidate are called the Connected Management Groups and the MG that you consolidate them under is called the Local Management Group. All the connected MG’s are peers and they do not have any visibility into other MG’s. Functionally, all these MG’s (connected and local) can work completely independent of each other – with different MP’s, different infra, different admins, different monitoring standards, different everything. In fact, the peer MG’s are pretty much unaware of the other MG’s. Once you connect multiple MG’s to a single master MG, you can view all the alerts coming from all the different connected MG’s in a single console.

To apply this to the scenario we described earlier, it’d be something like this:

The Ind_MG, the Eur_MG and the Aus_MG would be peers and would be the “Connected MG’s”, while

The Us_MG would be the “Local MG” where you can view alerts from all other MG’s- additional to its own.

There are some excellent walk-throughs on how to do this, like,

Connecting Management Groups in Operations Manager

SCOM Connected Management Groups–2016 and 2012

so let’s not go through the same thing again 😉

Just a note, if you’re thinking, “I wonder if I can connect my SCOM 07 MG to my SCOM 12 or 16 MG…” – Nope, can’t do that. All the MG’s involved must be the same SCOM build versions 🙂

Ok, that’s all for today!

Happy SCOM-ing 🙂

Cheers!