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.
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.
Even though this seems like a simple concept, I get these questions on a regular basis. I hope this clarifies the SCOM Reporting Instance and where these components are installed. Next I’ll be talking about where the report server databases can be created, and describing a caveat if these databases are located on a Data Warehouse in a clustered configuration.
