If you wanted to monitor 3 completely separate environments and networks but only wanted to have one console for support team to monitor, is this possible with SCOM 2007 R2 ? I am guessing most users of SCOM generally only have requirement to monitor their own environment, we have a requirement to monitor multiple environments which are unconnected to each other. We have a VPN connection to each of the 3 networks but want to house a central SCOM server on our network which recieves the alerts from the SCOM agents or servers on the remote networks. Is SCOM limited in this respect ? Appreciate all feedback.

I think that the best way to do that is simply to install a gateway server in each environments. As you will have different domain and etc, you will have to use certificate with you gateway, so you need to put in place a Certificate infrastructure in your central location. Christopher Keyaert - My OpsMgr/SCOM blog : http://www.vnext.be

Hi, Regarding this question, I would like to share the following with you for your reference: 10 Reasons to use a Gateway Server http://blogs.technet.com/b/momteam/archive/2008/02/19/10-reasons-to-use-a-gateway-server.aspx Deploying Gateway Server in the Multiple Server, Single Management Group Scenario http://technet.microsoft.com/en-us/library/bb432149.aspx Hope this helps. Thanks. Nicholas Li - MSFT

Thank-you both for your replies. Is this defintiely the way you would build a SCOM solution if you had to monitor mutliple different customer environments ? are there any alternatives in order to view all environments using just the one console ? One concern I have is how do management packs function in this type of scenario ? if we take the Active Directory management for example, currently we run this from a SCOM installation in the same forest as the domain controllers we are montioring, how would this work using gateway servers ? I assume the gateway servers are using the same rules and monitors configured in the management packs of the central RMS ? would SCOM allow you to configure different RunAs accounts for different domains which the RMS server could not validate against during the configuration ?

Thank-you both for your replies. Is this defintiely the way you would build a SCOM solution if you had to monitor mutliple different customer environments ? -> Yes, one gateway per customer environment Are there any alternatives in order to view all environments using just the one console ? -> Using gateway has no impact on the console view. You will have all the servers of your different environment in the same console. One concern I have is how do management packs function in this type of scenario ? -> Same way that one environment with no gateway. Gateway are only used for doing the authentication between the different environement. if we take the Active Directory management for example, currently we run this from a SCOM installation in the same forest as the domain controllers we are montioring, how would this work using gateway servers ? -> It will detect the others domains/forests without any issue. I assume the gateway servers are using the same rules and monitors configured in the management packs of the central RMS ? -> Yes, but you could create groups for each environement and apply different overrides on theses groups if needed. would SCOM allow you to configure different RunAs accounts for different domains which the RMS server could not validate against during the configuration ? -> Yes, you've got the run as profile for that.Christopher Keyaert - My OpsMgr/SCOM blog : http://www.vnext.be

Thanks for reply. What are people's thoughts to a connected management group solution rather than using gateways in each customer enviornment ? i.e. you have a top tier management group which has access to Alerts and Discovery information from connected mangement groups, enabling a view of all alerts and other monitoring data from multiple management groups in a single console. Would the above work ? can anyone see disadvantages of this approach rather than the gateway approach and/or advantages ?

The Operations manager product does not work in a connected management group scenario today.Microsoft Corporation

Hi Dan, Can you confirm ? are you saying with SCOM 2007 R2 it is not possible to have a consolidated view of alerts from other management groups ? there are a few posts on the internet that seem to suggest otherwise. Our support team are finding it increasingly difficult having to monitor multiple consoles for each customer we manage, currently each customer has their own SCOM installation and we monitor a console for each....ideal solution would be one console with a view of each customer environement we are monitoring. A number of people have suggested using gateway servers but wanted clarification there are no other options ? Using a connected management group type of deployment might be most straight forward to implement as separate SCOM management groups are already deployed in these environments. With the gateway solution we would need to do quite a bit additional work on management pack configuration. Thanks

Hi TechJet - You are asking about what is known as Service Provider Mode. In this model, each customer has one or more SCOM Gateway servers or an Essentials 2007 server in Service Provider Mode. Each gateway or Essentials server is issued a certificate from a trusted, private CA. The service provider runs gateways on the Internet with certificates from the same CA trusted by the customer gateways and Essentials servers. Using the gateway approval tool in the service provider's central SCOM instance, sites are created for each customer. Service Provider Mode is not practical with any sort of connected cusotmer management group nor is is practical to try and use Kerberos authentication against a service provider AD forest. OpsMgr 2007 R2 in Service Provider Mode can support many thousands of managed computers downstream of several hundred customer gateways in a single service provider management group. And yes with the management packs, when you go 'multi-tenant' in the service provider's SCOM instance, there are issues but nothing blocking the scenario. Good luck, John Joyner, MVP-OpsMgr

Thanks John, Just to clarify we are considering which option to use (gateway OR cosolidated management groups) my understanding originally was that there are two different options available to achieve what we are trying to achieve (one console to view alerts and health of multiple customer enviornments). So with this in mind I had been looking to either remove all of the separate SCOM installations at customer sites and replace these with a gateway server which fed up to our centrally managed SCOM managemeent group or we use the existing already configured SCOM management groups at customer sites and obtain a consolidated view using a top tier management group. If I understand Dan correctly he is saying that a consolidated view using multiple management groups is not currently possible ?

The connected management group scenario described at http://technet.microsoft.com/en-us/library/cc540367.aspx ("Managing Connected Management Groups in Operations Manager 2007") would not meet the objective of one console showing the health of multiple customer environments. Connected management groups only see alerts, they don't see state or performance data. There are also security considerations, such as that the connected management groups connect to the SDK service of the RMS of the central console. The service provider can use connected management groups in a very large service provider scale-out scenario. There can still be one central alerting view for Tier 1 NOC (includes Tasks), but to view state or other information, you must retarget your SCOM console or run multiple SCOM consoles. (Scheduled reporting and web console access to customers in connected management groups can be seamless.) That can be a higher operator and administrator cost but that is offset by the new revenues that justify the scale-out. I do see Dan's comment but am not aware that the connected management group scenario described at the Technet article does not work at all, for example, that alerts cannot be viewed in a central console. John

Thanks John. It sounds like the gateway solution is looking a preferred choice rather than connected management groups. We want to see health and distributed application views as well as it being easy to maintain. The fact that we can build a central high availability SCOM instance and then place gateway servers when new customers come on board apears to be the most straight forward and gives us what we want from the console view. This also removes the need to be managing multiple SCOM groups and databases. Obviously some additional work will need to be done around the management pack configuration to tweak for each environment. We currently produce availability reports for each customer which is straight forward when you are dealing with separate SCOM instances so with the gateway solution I will now need to work out how to pull off separate reports from a database which contains data from multiple customers.

You will find that when you create customer sites with the gateway approval tool that SCOM groups are created for each site (customer). You target your customer-specific reports and views/scopes to the site(s) for that customer. Works great. Good luck, John Joyner, MVP-OpsMgr

you don't even have to use gateways in order to do this. We dont have a single gateway but we do manage around 70 "untrusted forest" (customers) with a single management group. However there are some caveats to be aware off. Not everything works "out of the box" (management pack related, scom itself works fine) and not everything is going to work (e.g. health rollup for domains/site/forest will never work as these discoveries run from the rms. However the monitoring for domain controllers will work fine). Also a lot of "topology" views won't work when you start scoping, especially when it's scoped on computer based groups. Try to use "system" as runas account whenever possible. It makes things a lot less complicated... My blog (together with a colleague) descripes some of the problems and solutions that we've run into. E.g. my colleague wrote a nice piece about creating customer classes so when you create a customer specific rule it doesn't get distributed (disabled, but distributed) to all other customers as well as it might contain valuable information (you don't want customer A to know something about customer B). Rob Korving http://jama00.wordpress.com/

Thanks Rob, this is interesting to know. Can you tell me why you chose not to use gateways for each customer, was there a technical reason or was it just to avoid managing and purchasing the gateway servers ? my understanding is that one advantage of gateway servers is that the data between gateway and central RMS is compressed 50%. I'd also be interested for the link to the blogs you mention ? Thanks again.

A bit late, The data compression is actually based on "larger data" parts which compress better. i believe we calculated it only starts to be noticable when you have more than 200 agents behind a server. But we have tuned quite a lot, so probably less data than a normal implementation (hardly any collection rules left, only the ones really necessary for capacity management). Another benefit of gateways is being able to push an agent. But we created a scripted install of the agent, so we only do "manual" installs (actually, altiris or sccm/sms does the install). e.g. with our custom install we write a "customer string" to the registry. So even if we pushed from gateways, we still have to do some additional settings manually. We have small customers and large ones. A small customer might have 5-10 servers, which doesn't really make the "gateway scenario" profitable and we wanted 1 scenario to fit all. Cost is definitely something we thought about. over 50 customers times 2 gateways (redundancy) = a lot $ we save... The drawback would be of course overhead in certificates (unless you have forest trusts), but we've scripted this part as well. So you can still have an "automated" installation. Anyway there are benefits and drawback to using gateways. I don't believe there's one scenario which is the best and you need to balance between the drawbacks and benefits of gateways. For us it turned out not to use gateways... Rob Korving http://jama00.wordpress.com/

Thanks Rob, no problem for delay as useful feedback.

I too have a question about connecting multiple SCOM Management Groups to one console on my desktop. We are currently deploying SCOM in a very large enviroment of 4,000 servers. We have a SCOM Management Group in a Crash-n-Burn Lab, a Certification Lab and in Production. Our company polices do not allow us to combine these enviroments where an alert from one of the lab enviroments can filter into production The SCOM Console allows you to add mutliple SCOM Groups but only works with the first group added. I can connect multiple email accounts to my Outllok at home and select which one to open whenever I open Outlook. Looks to me the SCOM Console 'should at least' be that intellegent. But I have not found a way to do it as yet. So the curent method is I open the console and delete the connected SCOM Management Group and then add the SCOM Management Group I want to connect with next. Then close the SCOM Console and re-open it. Just seems like the Console is not developed as yet as it should be to me. Does anyone know why you can add multiple SCOM Management Groups to the SCOM Console but only effectively use one Management Group? Unless I am missing something on how to select the second, third or fourth SCOM Management Group when I open the Console?

you can add a command switch to the startup and have it connect to a specific rms (/server: rms.fqdn). It would require 1 link per management group though. See the help for more options, maybe there's an option to always show the select screen for rms selection.Rob Korving http://jama00.wordpress.com/

Hi Keith - Great story that you are managing that many servers with SCOM, and that you have several dev/test SCOM environments. Sorry to tell you but you are asking for a feature that SCOM does not nor could likely ever will support. The SCOM console can only be connected to one management group at a time, this is a fundamental feature of SCOM architecture. Have you considered the Connected Management Group scenario? (http://technet.microsoft.com/en-us/library/bb418761.aspx). That model would give you a 'top level' SCOM console that contained the alerts from all the subordinate connected management groups. If the top level console was only watched by you and not your operations staff, the operations staff would not see test/dev alerts in their prouduction consoles. Good luck, John Joyner MVP-OpsMgr