Command Shell Examples
Useful SQL Queries
Multiple Management Groups, Single Data Warehouse (part 1) - Jonathan Almquist on Operations Manager - Site Home - TechNet Blogs

Multiple Management Groups, Single Data Warehouse (part 1)

Multiple Management Groups, Single Data Warehouse (part 1)

  • Comments 18
  • Likes

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.

image

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

I do not moderate this blog anymore. If you have a question regarding this post, send me a message.

Comments
  • 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.

  • 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?

  • 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.

    Thanks,

    Jonathan

  • 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?

    Thanks,

    Artur.

  • 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.

    -Jonathan

  • @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.

    -Jonathan

  • 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)?

  • @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.

    -Jonathan

  • 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.

  • @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.

    -Jonathan

  • 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.

  • 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.

  • 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!

  • 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?

  • @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.