How to Separate Management Servers for Ease of Administration?

Question

Hello,
I am fairly new to SCOM, though have been charged with creating a monitoring solution for a particular group of customers and integrating it as far as possible into our existing corporate SCOM implementation, so any help, tips and so on would be greatly
appreciated. 
The customer monitoring requirements will be very different to those of our fairly standard corporate environment - we will need to monitor very different technologies, with some systems sat in different domains or a DMZ. Our central servicedesk will still
need to monitor and action alerts and events for both environments as seamlessly as possible. 
At the same time, I would like to separate the environments as the configuration of the management servers for the customer environment will be quite different from our corporate one, and I want to avoid having to make changes to all our corporate servers
every time I need to change something on the customer environment - so things like management pack installs, certificate admin, static DNS config and so on. 
How would I go about this please? Would it be better to create a separate management group, with servers dedicated to the customer environment, then connect this to the corporate management group so that the servicedesk can still monitor it, or is there
another way of doing it? Perhaps using resource pools? Time will be a factor here, though ultimately the goal is ease of administration going forward. 
Thanks

Answer 1

Using resource pools will not allow you to separate configuration such as MP installs, security, etc. as they are all part of the same management group.  From Technet, "A resource pool is a collection of management servers used to distribute
work amongst themselves and take over work from a failed member."  If configuration needs to be completely separate from the base configuration perspective, you could use separate connected management groups. 
Another option is to separate the configuration within the management group.  For example, if you need to monitor SQL computers in your corp environment but not the customer environment, simply create a group containing customer computers and override
the SQL discovery.  This applies to other technologies as well.  You can even group computers by environment (corp/customer) by using reg key attributes like Kevin Holman describes here: (While my account is being verified
I can't post links but you can search "Creating custom dynamic computer groups based on registry keys on agents").  If you are familiar with MP authoring, you could create a new MP with a new Windows Computer based class instead of extending
the Windows Computer class.  From a capabilities perspective, you can certainly monitor corporate, customer, DMZ, and other domains in the same management group.  If the domain is untrusted or in the case of the DMZ, workgroups computers, you can
utilize gateway servers with certificate authentication which will be configured for each domain/dmz gateway.
Ease of administration is a tricky concept here...if you utilize separate management groups, administration will have to be handled completely separate in 2 separate consoles.  If there are separate SCOM admins per management group, this is
of no issue, but if 1 team/person is managing both, this can be difficult.  Alternatively, there will be some up front work to using groups to separate the environments using groups, discoveries, etc.