Multiple Management Groups, Single Data Warehouse (part 1)

In this series, I’m going to talk about multiple Management Groups sharing a single Data Warehouse.  I’ll try to clarify two common questions that come out of this scenario.

Part 1 – Operations Manager Reporting Instance
Where do these components get installed?

Part 2 – ReportServer and ReportServerTempDB
Where do these databases reside?

Before I get started, I want to make one thing clear about clustered configurations.  The SCOM Report Server role is not cluster-aware, so the Report Server role cannot be installed in a clustered configuration.  The SSRS Instance cannot participate in a scaled-out deployment.  Nor is the reporting databases hosted in a clustered configuration officially supported.  This article by the MOM Team has served as the official statement on these configurations.

Note: Sharing an existing data warehouse is as simple as installing the Report Server role in the next management group and pointing it to the existing data warehouse.  All the required pointers will be setup automatically by the installation process, and the data warehouse will be shared automatically without additional configuration.

Here we go with part 1…

Throughout this post, I’ll talk about the SCOM Reporting Instance.  When I mention the SCOM Reporting Instance, I am referring to three components that make up SCOM Reporting.

Components of a SCOM Reporting Instance

· SCOM Report Server role

· SQL Server Report Server (SSRS) instance

· Computer

You might be wondering why I include “computer” as a component.  No kidding, we need a computer?  I added this as a component to help the reader visualize the concept, which you’ll understand in just a moment.

There is a dependency between each of these components. We must think of the composition of the SCOM Reporting Instance as a single package that cannot be split. Also, a SCOM Reporting Instance cannot coexist with another SCOM Reporting Instance serving another Management Group.

During the installation of the SCOM Report Server role, SSRS security is reconfigured to make use of SCOM security features (User Roles) which are implemented in the SDK. Because of this, only one installation of the SCOM Report Server role can exist on a computer.

Since the SCOM Report Server role installation has a dependency on a local installation of a SSRS instance, we can deduce that there is a 1:1:1 relationship between the SCOM Report Server role, the SSRS instance and the computer in which these components are installed.

We can also determine from these rules that the 1:1:1 relationship is strict, and that these components can neither be split, nor can these components be mixed and matched with other SCOM Reporting Instance components serving other Management Groups.

Of course, we need not be concerned about these rules in single Management Group scenarios that are not sharing a Data Warehouse.  But if you are sharing a Data Warehouse amongst two or more Management Groups, these rules apply.

Customers often get hung up on the “unique computer” for each SCOM Reporting Instance rule. Often I hear customers asking if they can combine SCOM Reporting Instances in a multiple Management Group scenario. This isn’t possible, as a SCOM Reporting Instance cannot coexist with another SCOM Reporting Instance serving another Management Group.

Another point of confusion for customers is they have installed a SCOM Reporting Instance for the first Management Group on the server hosting the Data Warehouse. Later, they have deployed additional Management Groups and want to share the Data Warehouse. This is fine. But, again, the rules state that we cannot install another SCOM Reporting Instance on the server hosting the Data Warehouse. We must find another server to install the SCOM Reporting Instance. Additionally, each subsequent Management Group deployed that will share the Data Warehouse will require yet another unique server to install the SCOM Reporting Instance.

In case there are any lingering questions, I provided a simple table that should solidify these rules.


I hope this clarifies the SCOM Reporting Instance and where these components are installed.

Comments (18)

  1. Hi Marnix,

    This is a good question, and I don’t recall reading about the shared Data Warehouse upgrade procedures in the R2 Upgrade Guide.  I haven’t personally tested this scenario, and this is obviously quite a repro setup.  I have the question in with the Product Group and will update this comment when I have some answers.



  2. @KAP

    That is correct.  Unfortunately this all comes down to the fact that the Report Server role is not cluster aware, and needs to be on the same server as the SSRS instance.


  3. By the way – the concept of shared DW does not change from OpsMgr 2007 to OpsMgr 2012. Same rules apply.

  4. That is correct.  A separate RS installation for each MG.  When you do the RS installation process on the second MG, input the Data Warehouse information you currently have up and running.  The DW will automatically become shared at that point.  You will not overwrite or cause any interference with the MG that is already writing to the DW.

  5. @KAP

    The Report Server role is not cluster aware, so it’s not advisable to install in a cluster configuration.  Also, the SSRS instance needs to reside on the same machine as the Report Server role, as it’s outlined above.  It’s not possible to select a remote SSRS instance while installing the Report Server role.


  6. ArturRLR says:

    Hi Jonathan,

    Let’s say that I will have 2 RS for SCOM, is there any way to change in the SCOM console the references for the reporting services server?



  7. Chris – on the supported configurations page, it states 769Kbps connectivity to DW (…/jj656654.aspx). I understand links between datacenters are getting VERY fast these days, but I'm still a little apprehensive about sharing a DW across a datacenter link. However, I think the worst that would happen is, your management servers may get backlogged – just ignore backlogs in this case. I believe standard SQL ports are required, and this is pointed out on the page referenced above. Hope that helps!

  8. @Chris P – are you talking about connected MG's for the 2 "base" MG's and a "rollup" MG? Sure this will work, but it only applies to monitoring data – alerts and what not. There is no consideration of historical data when contemplating connected MG's. Also, there is no rollup of historical data to a "central" MG. A DW is either shared, or it's not. In the case of shared DW, then you just need a single DW, and you'll need to install a report server role in each MG regardless.

  9. @Marnix

    Although this *may* work (SQL 2005 SSRS w/ SQL 2008 DW), I haven’t personally tested this configuration and there are no plans to include this as a supported upgrade path at this time.  Currently, customer needs to upgrade both SQL roles to the same version.


  10. Arturlr,

    I have done this in a lab, and it worked fine.  But this configuration is not documented anywhere, so I don’t think it’s officially supported.


  11. Marnix Wolf says:

    Good article Jonathan. Thanks. A year ago I bumped into a situation with multiple MGs (five in total) and one DW. Got it working but took me a while to figure it out. This article could have spared me a lot of time then.

  12. Marnix Wolf says:

    Hi Jonathan.

    How to go about it when upgrading the SQL Server of OpsMgr R2 to SQL 2008? Suppose the OpsMgrDW database server is 2008, does the SRS instances, based on SQL 2005 still work than?

  13. KAP says:

    I found this article very interesting. Not sure if you can help but….is it possible to install the reporting server component on a SQL cluster (separate instance for SCOM OpsDB, DWDB and RepDB) and during the reporting server wizard can I point the install of the reporting server components on to another server (seperate from cluster)?

  14. KAP says:

    Thanks Jonathan for the information.

    So just to confirm, I can install OpsDB and DWDB on the SQL cluster using a tool called DBcreatewizard.exe and I have to install the report server and sql on a standalone server (extra SQL licence). Otherwise installing the reporting role on the cluster would mean SCOM files are installed on the cluster.

  15. Bryan Heath says:

    So if understand this article I need a separate RS for each management group MG1, MG2 etc. I can then in turn share my common DW throughout each management group with DW1 for MG1 and MG2. During instillation how do I share the DW? That seems to be the part I am struggling with. Also will this over write the original DW counters? I am sort of new to this so bear with me. I know you are spot on with the 1:1:1 because when I setup a separate instance on the same server and re-ran the install it made a new DW for that instance and failed to install reporting into MG2. My original reporting environment seems un-affected.  Please advise.

  16. Bryan Heath says:

    I ran with the install and it is crystal clear why you are saying this is a 1:1 . During a fresh intall you choose which RMS you are installing reporting to as well as "connect" to the existing DW. When you install to a different instance on the same RS it is missing that step which should say "what additional RMS do you want to install to".. So effectively you get an incomplete install and never actually inject reports into the second RMS. It is actually more like a pseudo repair. This article seemed above my head at first but became clear as I fooled around with the product. Thanks a bunch!

  17. Chris P says:

    Hi, in SCOM 2012 we are looking to deploy 3 MGs. 2 are the base MGs where all the agents will report to and 3rd one is a central MG that everything will roll up to. My question is regarding the DW deployment and the data sync. I guess each MG will need to have a DW database but will the connection actually push data from 2 base MGs into the central MG? Also regarding reporting – im planning on installing reporting only in central MG – would that work?

  18. Chris P says:

    Hi Jonathan, Sorry for late reply and thanks for your feedback. I am getting back to implementing this into production soon and just wanted to find out few more things. What is the acceptable network latency between 2 management groups to even consider sharing a DW? What firewall ports would need to be opened for 1 MG to share data with another MG behind a firewall? Thanks again!

Skip to main content