Is anyone sharing data warehouse between management groups?

Dashboard Server
, ,
1

I have the great firtune of supporting a multi-tenant, multi data center, environment that currently consists of three management groups. In the past we had multihomed agents between management groups but that really just swelled up our ops manager database, as well as the data warehouse. So we’ve since removed that configuration and now every agent reports to it’s in management group. Oh, the console sprawl.

We’ve been entertaining the idea of sharing data warehouses between management groups for a long time, to make reporting a lot more simpler. We’re considering sharing DWs between two of our larger data centers and leaving the smaller one stand alone, for the time being (it may be headed for OMS).

Would love to hear examples of how anyone else is overcoming this.

One of our constraints at this point is network segregation due to ridiculous paranoia and unicorns. The combination of those has also lead us to make, what I think was a mistake, of using different SDK and data access accounts between these management groups; same domain though!

Horror stories and tales of truimph also welcome.

1 Like
2

Is this even supported? AFAIK you can’t have the same DW for multiple management groups. This is likely a question for a PFE or MVP :frowning:

3

I’m pretty sure we had/have the same DW DB for 2 management groups. Different OpsDB’s though.

4

@Darren Joyce - exactly the scenario we’re trying to map out.

Currently, separate MG’s with their own OPSDB (SQL AG) and DW
Each MG is in its own separate datacenter
Same domain

Currently the challenge would be:

Unifying my SCOM SQL svc accounts (SDK/CFG) as they are datacenter specific, but in the same domain, I’ve been assured by my SQL DB’s that the perms are handled by a group membership in the domain.

We’ve decided on one of the datacenters to be the mother of all DW’s, so would this just be a matter of pointing the Reporting Instance(?) to the MOADW’s?

We have no plan to execute until 2018. We’re also weighing this vs implementing a new SCOM 2016 environment. As I typed that out, it just made more sense to plan a new 2016 MG and address the challenges without interrupting my disjointed prod environment.

5

Hi Blake. Sometimes easier to start from scratch :slight_smile: When I took over our SCOM set up, there was a lot of issues. I pushed through it, but in hindsight maybe I should have started again :slight_smile: