First published on MSDN on Mar 04, 2009
My previous post covered configuring a connected management group - but how does it really work? When I first starting pulling this apart I had some preconceived expectations about how it would work - probably because of my familiarity with the way it worked in MOM 2005. Really, how this works in OpsMgr is very very simple - but there are some limitations.
The diagram below shows two separate management groups with the RMS of each communicating with the Operations Manager database and managing a few agents. In this diagram, nothing is connected.
If we follow the instructions in my previous blog post we will end up having these management groups connected. Lets assume management group B is connected to management group A. When an approved user in the Operations Console in management group B clicks 'show connected alerts' they will see all of the alerts (or at least the ones they are allowed to see) from management group A. Cool - but how does it work? Connecting a management group causes the connected management group to talk to the SDK service on the destination management group - in this case the RMS for management group B will establish a link with the SDK service in management group A. Once the connection is established the connected console will be pulling data from the SDK service in both management groups. The revised diagram below shows how this works.
The end result - you can see all of the alerts for both management groups in one view. As mentioned above, though, there are limitations. The connected function only works for viewing alerts and running tasks you can't do notifications or make use of classes from the connected management group. One benefit of this design? There no longer seems to be a requirement to keep management packs in sync between management groups like there was in MOM 2005.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.